July 19, 2002 at 12:00 am
Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/columnists/awarren/disasterintherealworld2.asp>http://www.sqlservercentral.com/columnists/awarren/disasterintherealworld2.asp
December 14, 2012 at 10:28 am
The one thing I've done a lot is is created a scheduled task based off the sp_help_revlogin SP. It dumps the data to disk every 8 hours. Then the file is replicated to another server.
In a different job, I also had a script to create the restore scripts as well. That ran on a regular basis as well.
I also create my maintenance plans, etc by standardized scripts as well.
Having the logins with the right SIDs and the and the SQL backups, it allows me to not worry about recovering the system database and just do a fresh install of SQL Server. Then I worry about the user databases.
----------------
Jim P.
A little bit of this and a little byte of that can cause bloatware.
December 15, 2012 at 9:18 pm
gloing73 (12/15/2012)
very good website:===== http://www.globalmarket.name// =====
The website wholesale for many kinds of fashion shoes, like the nike, jordan, prada, also including the jeans, shirts, bags, hat and the decorations.
WE ACCEPT CREDIT CARD /WESTERN UNION PAYMENT
YOU MUST NOT MISS IT!!!
😉
This particular post in this forum reported as SPAM
December 17, 2012 at 1:39 pm
Hey Andy,
Just to be sure I read this right...
Win2k, SQL2k? In 2012?
Wow... makes me glad that management lets me upgrade to newer stuff than that!
January 4, 2013 at 6:00 am
Hi, Andy,
I'd read your initial article a couple times to ensure I understood the chain of events and the timing of the issues. I've ran into a similar situation within the last year, and wanted to compare notes after the holiday. I'm uncertain whether your event was preventable, but we've determined ours was.
Firstly though, can you confirm your environment specs? We're most likely not comparing apples to apples, as we're running Windows 2k8 and SQL 2k5, currently, with a plan to skip 2k8 for 2012. In one case far in my past, the simultaneous outage for Exchange and SQL were caused by a single system issue, as the business had been stingy on funding a separate server for each. A simple drive fill caused by a mislocated tempdb caused the system failure. In the recent past, the issue was caused by and unscheduled & uncommunicated security alteration from the separate AD group in the company. In your case, it sounds more like a specific OS registry corruption on the Exchange server, and a separate but coincidental total failure of your RAID5 drive configuration for the SQL server.
Ignoring the mail server issue for a moment, was there monitoring for drive failure within your SQL RAID configuration? In addition, does your SQL instance use the Exchange server as the SMTP destination for any server alerts thru DBMail? Perhaps it wasn't as much of a coincidence after all.
I look forward to your comments in response. Hopefully, an alteration to the current recovery standards will help minimize recovery times in case of another event.
Cheers!
Jonathan
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply