July 6, 2011 at 7:00 pm
Hiya,
We have 33 DB's on that particular server and all are included in a single maintenance job(1 to do all the full backups, 1 to do the transactions logs, 1 clean up old backups/logs, 1 to check integrity... etc) Using the standard SQL maintenance, probably created via the wizard... before my time.
Cheers
Mr J:-)
Remember
Without Change something sleeps inside of us that seldom awakens, the sleeper must awaken!!
July 7, 2011 at 8:55 am
Assuming those jobs don't overlap each other then that alone is worth 132 Mbytes of the 512. If they do overlap then it will be larger yet. What else is running before or during the backup jobs? Any smoking guns like say CLR?
July 7, 2011 at 7:03 pm
No i have staggered all the jobs so there are normally no overlaps.. sometimes congestion on the network does slow the odd job down.. but this is a rare event. Funny thing is its been almost a week, and still no repeat of the error... i've gone through the mem status and nothing seems to be bloating out. This is turning out to be a very slippy bugger indeed. I will of course introduce the -g flag to the start-up and comb through the log files until i find what extactly is causing the problem... i do fear thou only a move to 64bit will resolve this issue. If you or anyone for that matter can suggest any tools that may help in identify this issue can post it i would be very grateful.
Cheers,
Remember
Without Change something sleeps inside of us that seldom awakens, the sleeper must awaken!!
July 8, 2011 at 9:02 am
I'm not aware of any tools, After a week of trying to solve this I ended up opening a MS Support case. I would suggest you do the same since the easy solutions didn't seem to help.
You are correct by the way, 64-bit is the only solution. We officially asked the vendor to support 64-bit and they complied after about 6 months. We are putting the test systems together now to migrate them.
Viewing 4 posts - 16 through 18 (of 18 total)
You must be logged in to reply to this topic. Login to reply