Log File Issue In SQL server 2005 standard Edition

Question

We have database of size 375GB .The data file has 80 GB free space within .When trying to rebuild the index we had 450 GB free space on the disk where Log file is residing.The rebuild index activity failed due to space issue.added more space and got the
job done successfully
The Log file has grow up to 611GB to complete the rebuild index.
version :SQL server 2005 Standard Edition .Is ther a way to estimate the space required for rebuild index in this version.
I am aware we notmaly allocate 1.5 times of data file.But in this case It was totaly wrong.
Any suggestion with examples would be appreciated.
Raghu

Answer 1

OK, there's a few things here.
Can you outline for everybody the recovery model you are using, the frequency with which you take full, differential and transaction log backups.
Are you selectively rebuilding your indexes or are you rebuilding everything?
How often are you doing this? Do you need to?
There are some great resources on automated index maintenance, check out
this post by Kendra Little.
Depending on your recovery point objectives I would expect a production database to be in the full recovery mode and as part of this you need to be taking regular log backups otherwise your log file will just continue to grow. By taking a log backup it will
clear out information from inactive VLF's and therefore allow SQL Server to write back to those VLF's rather than having to grow the log file. This is a simplified version of events, there are caveats.
A VLF will be marked as active if it still has an open transaction in it or there is a HA option that still requires that data to be available as that data has not been copied to another node yet.
Most customers that I see take transaction log backups every 15 - 30 minutes, but this really does depend upon how much data your company can afford to lose. That's another discussion for another day.
Make sure that you take a transaction log backup prior to your job that does your index rebuilds (hopefully a smart job not a sledge hammer job).
As mentioned previously swapping to bulk logged can help to reduce the size of the amount of information logged during index rebuilds. If you do this make sure to swap back into the full recovery model straight after and perform a full backup. There are
problems with the ability to do point in time restores whilst in the bulk logged recovery model, so you need to reduce the amount of time you use it.
Really you also need to look at how your indexes are created does the design of them lead to them being fragmented on a regular basis? Are they being used? Are there better indexes out there that can help performance?
Hopefully that should put you on the right track.
If you find this helpful, please mark the post as helpful,
If you think this solves the problem, please propose or mark it an an answer.
Please provide details on your SQL Server environment such as version and edition, also DDL statements for tables when posting T-SQL issues
Richard Douglas
My Blog: Http://SQL.RichardDouglas.co.uk
Twitter: @SQLRich