July 15, 2009 at 3:54 pm
It shows my snapshot, and at the moment the transactional dummy one from your instructions.
July 15, 2009 at 4:14 pm
:-D:-D:-D:-D:-D:-D
You are an angel, thank you so much!
See screenshots. Doing a log backup now!
July 15, 2009 at 10:26 pm
Excellent. I suspect, in this case, the immense amount of log entries that SQL had to 'unmark for replication' was the reason that the simple create-drop failed.
You should now be able to drop that second log and shrink the first down to it's usual size.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
July 17, 2009 at 8:55 am
Update:
-I reclaimed the log space back to just over 8Gb, very acceptable.
-The snapshot replication I had set up was removed. Thanks for having me script it first, I now have my config.
-When I try to script it back in, it fails at several points, which is no biggie, we were still testing it anyway. I have my articles in the script so I will rebuild it by hand in the next two weeks and start over. Again, no biggie.
-I am considering keeping the second log file for when they do something crazy again in the future. As you can probably tell, this db is for MS Dynamics Axapta, which is kind of a beast on SQL. We also have a lot of customizations, which I do not think have been coded well (with respect to db efficiency), so two log files will be a little extra cushion for me. All these files are under constant watch from Nagios, so I will know if something goes haywire. This will just give me more time to respond to an problem.
If you see any problem with my reasoning, please let me know.
Thanks again for the help.
Viewing 4 posts - 16 through 18 (of 18 total)
You must be logged in to reply to this topic. Login to reply