What to do about Indexes when SQL Server & its DB's are relocated on a SANS

  • SQL Platform: SQL Server 2005 - 9.00.3068.00(X64)

    Windows OS: Ent Edition Windows NT 5.2 (Build 3790)

    Environment: The Server is running on Vurtual Drives (VM Ware) and the SQL Server 2005 box's drives occupy 8 partitions (of whatever IT Admins would call the drives on VM) on the SAN.

    I'm more of a developer then T guy so excuse me if I sound a bit dumb on the hardware side of this isue. OUr IT Admin, over the weekend, moved our SQL Server 2005 Server from one section fo space on the SAN to another so as to give it more storage. i was also told that the performance should be better as well however it may or may not be noticeable depending on how effecient the app we use is. My question for the forum is this:

    When this happens, a SQL Server 2005 setup is moved from one section of a SANS to another via the process of imaging (I may be using this term incorrectly) the server and then placing that image back onto a different section of the SANS, do the indexes on the less volatile tables need to be rebuilt?

    We have already executed the job that rebuildes the big indexes and it ran in about the same amount of time it typically runs when running per the regular schedule. I however have not done anything with the rest of the indexes on the system. Our primary application has a decent number of tables with data that is used primarily in SELECTs after the initial setup. For example one of these tables stores contact info and while this does cahnge it does so far less often then the table that store payment info.

    Would it be necessary to rebuild these less volatile indexes under this type of change to the environment? Based on what the IT Admin tells me about how the move happens I get the impression that nothing needs to be rebuilt but then again I am more of a developer in SQL then a pure DBA so I'd like to solicit otehrs input.

    Thanks

    Kindest Regards,

    Just say No to Facebook!
  • Actually you would need to do the same as if you would handle files on "regular" disks.

    That goes for :

    - raid

    - allocation size

    - number of files

    ...

    Whenever we move physical files, we perform full maintenance to all objects that reside in those files (or filegroup)

    SAN isn't the holy grail !

    It just provides other means of volume facilities, redundancy, backup (san snapshoting), ease of LUN-expansion, Remote Dual copy (from one san to another redundancy)...

    Johan

    Learn to play, play to learn !

    Dont drive faster than your guardian angel can fly ...
    but keeping both feet on the ground wont get you anywhere :w00t:

    - How to post Performance Problems
    - How to post data/code to get the best help[/url]

    - How to prevent a sore throat after hours of presenting ppt

    press F1 for solution, press shift+F1 for urgent solution 😀

    Need a bit of Powershell? How about this

    Who am I ? Sometimes this is me but most of the time this is me

  • You should not need to on a detach/attach type move, but you never know. When the files are copied, it's possible they get more fragmented, and a rebuild might clean things up.

  • Thanks for the feedback guys.

    Kindest Regards,

    Just say No to Facebook!

Viewing 4 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic. Login to reply