Hi,
I have been working as Database Administrator for a few years now and everyday I come across questions for which I don't have any answers. So I rely on the Internet to provide me the answers. Google has to be the best colleague of mine, without whom I would not have survived in this profession for this long. So today I thought it was time that I give it back to the community and help my fellow Database Administrators with problems that we all face everyday. Starting today, I will start blogging one new technique, one new details, one new trick within SQL Server. Hopefully this will help others too.
Platform : SQL Server 2005 and 2008
I had set up log shipping between two servers and most days the size of the log file of the primary database remains within acceptable limits. But today there was some bulk load and that resulted in a huge log file. Consequently the log file size of the secondary database (Database to which the logs were being shipped and restored) also got big. So big that the disk drive where the log file was located was almost full.
So I had to figure out a way to shrink the log file of the secondary database but unfortunately it was in READ ONLY mode so there was no way I can shrink that database. Until today I had not reached this situation where I have to shrink the log file of secondary database. Just to try I ran the DBCC SHRINKFILE command against the primary database and that did the trick. This shrank the log file of the secondary server too. But before this happened, I had to run the LSBackp, LSCopy and the LSRestore job to make sure that the transaction was copied over to the secondary database.
Conclusion: In a Log Shipping set up in SQL Server 2005/2008, DBCC SHRINKFILE on primary database does get propagated to the secondary database.
