March 30, 2011 at 1:44 am
Hi,
SQL Server shutdown - how to restart server.
I am working as new- sql dba, i am wondering in this case what i have to do first.
1) If Production SQL Server 2005/2008/RC is crash or down for some reason Human error etc ? , what i have to do first step do
so sql server bring online ? I have only remote connect.
I have full backup like, mdf, ldf only.
2) If SQL Database is gone/offline, what are the first step to do bring ONLINE.
3) How to know in SQL Server who/when is login, what operation did, change's, delete ?
If something goes wrong, i want to save my bread & butter, collect all those information and show manager it was not done of me.
I have to those job from REMOTE DESKTOP CONNECTION.
Thanks
Trying to survive as SQL DBA
March 30, 2011 at 2:44 am
M.Kahn (3/30/2011)
1) If Production SQL Server 2005/2008/RC is crash or down for some reason Human error etc ? , what i have to do first step doso sql server bring online ? I have only remote connect.
Call the server admin and make sure he gets the server (physical machine) running. After that check that SQL restarted correctly. If not, look at the errors and debug appropriately
I have full backup like, mdf, ldf only.
copy of mdf and ldf are NOT a backup. Start taking database backups.
2) If SQL Database is gone/offline, what are the first step to do bring ONLINE.
Find out why it's unavailable, check errors. Resolution is completely dependant on the cause.
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
March 30, 2011 at 4:40 am
As already said, the first thing to do to "save your bread & butter" is to start backing up correctly. Get a plan together and implement it 🙂
March 30, 2011 at 6:46 am
Thanks you for reply.
In my case is, backup is taking care of 3rd section, which i dont have any idea of how they taking back stuff. And where back is, neither i have access for that.
In this sisuation, what i have to do first step ?
thnx
Kahn
March 30, 2011 at 6:56 am
M.Kahn (3/30/2011)
In my case is, backup is taking care of 3rd section, which i dont have any idea of how they taking back stuff. And where back is, neither i have access for that.
So what happens if you need to restore ever?
What happens if the DB crashes, you ask for a backup and they can't get you one that works?
First and primary responsibility of a DBA is to ensure that the data is safe and backups are restorable.
In this sisuation, what i have to do first step ?
Verify that you have restorable backups (it's your job, it'll be your problem if the backups can't be restored). Everything I said in the first post is still valid.
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
March 30, 2011 at 3:42 pm
Server admins vary. Some of them understand database backups. Others think taking a copy of the .mdf and .ldf files constitutes a backup. Unless Section 3 includes DBAs, you cannot assume they are making valid SQL Server backups.
Actually, backing up the .mdf and .ldf files does provide a sufficient backup. The problem is that you have to shut down SQL Server to be able to copy these files, and shutting SQL Server down regularly is usually unacceptable. Transactional databases should usually be run under Full Recovery mode. Log backups run periodically provide more timely protection. The size of your databases is also a factor and will determine whether/how often to run differential backups.
SQL Server offers "maintenance plans" which provide wizard-driven methods for developing a backup job. We create one job for the simple recovery databases and another for the full recovery backups. We have very small databases (less than 10 GB) so this crude method works well for us. Watch this YouTube video to get started:
http://www.youtube.com/watch?v=SP68dyw-GFI&playnext=1&list=PLB2330D58DD55CD0C
March 31, 2011 at 12:08 am
Nicole Garris (3/30/2011)
Actually, backing up the .mdf and .ldf files does provide a sufficient backup. The problem is that you have to shut down SQL Server to be able to copy these files, and shutting SQL Server down regularly is usually unacceptable. Transactional databases should usually be run under Full Recovery mode. Log backups run periodically provide more timely protection. The size of your databases is also a factor and will determine whether/how often to run differential backups.
While file level backups are OK for recovery from a disaster, they aren't sufficient if you are running in FULL recovery mode as the transaction log will just continue grow larger and larger. (Well if a full backup was ever run on the DB.)
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply