I think I found the answer here. Basically, grant authorization on my second schema to dbo:
ALTER AUTHORIZATION ON SCHEMA::sfdc TO dbo
So, it really has to do with ownership/authorization rather than the schema itself.
How I personally would do this:
Rename TableA into TableA_Old and create a view named TableA. That way your users can keep on working.
Create a new TableB, create your indexes on it and start copying data from TableA_Old into TableB (or first copy data and then create indexes; at least I would create the clustered index first and all other indexes after ...
I have struggled with this for sometime and like JNK I though the problem was continues free space and physical fragmentation on disk. However, what do you do about that on a SSD SAN?
I have now found out that it may be a good idea to only include index_level=0. This is how it is done in Ola Hallengren's script.
Another improvement is to do
Currently i have classID as an included column in an index idx, so i
think that the idx will be used when classID is in select statement.
No, not really. The index that is selected in the query plan depends on the query optimiser deciding which index best satisfies the query requirements. If your index key columns match, or are very similar to, your query ...