December 11, 2007 at 1:30 am
I need to take back up of very large DB. Please help me with the Query.
December 11, 2007 at 2:41 am
BACKUP DATABASE [name] TO DISK=N'[path+filename]' WITH NOINIT
and make sure the extension of the back-up file is .BAK
December 11, 2007 at 8:01 am
Additionally, I would suggest that you take a little time to read BOL about backups and restores.
I appreciate this is a simple query and process for me, but if you are in a position to be responsible for backups and restores, you should try to understand the technology behind the queries and time permitting, play about...test backups and restores so you feel comfortable with the process. Trust me, when the day comes when you need a restore, you'll be happy you know the process!!!
December 11, 2007 at 8:16 am
After taking up the backup, I verify my backups using :
RESTORE VERIFYONLY FROM DISK ='C:\YourBackupfile.bak'
December 11, 2007 at 9:31 am
Adding to the previous replies if you really backing up a very large database, you might want to backup to more than one file. Depending on your disk subsystem this can shorten your backup (and restore) time considerably.
[font="Verdana"]Markus Bohse[/font]
December 12, 2007 at 2:59 am
Thanks for the reply. I tried the query that you suggested. It worked fine when I executed it on the server machine. I tried to fire the same query from VC++ application that uses DSN configured to the Server IP and the application is on client machine, but the query failed.The data base is huge.
December 12, 2007 at 8:03 am
ODBC connections time out after 30000 ms. You have to alter your DSN connection driver to accomodate the long running query.
This link has more information:
December 12, 2007 at 8:07 am
Alternatively, create a scheduled job with the T-SQL code to backup and execute the scheduled job instead. This way you won't need to play around with timeouts. You just fire off the job within SQL Server and you can disconnect.
December 12, 2007 at 8:08 am
Sorry, for clarity, use sp_start_job from your application to start the scheduled job off.
December 12, 2007 at 8:31 am
Great point Clive :cool:.
The only potential problem I see is the application cannot inform the user that the backup has completed or failed. This can cause a problem if the user believes that the backup is taking place, while in fact it has failed.
December 12, 2007 at 8:37 am
I did think of that too. You could always have some kind of e-mail process at the end to give a notification of completion/failure.
Either that or just poll SQL Server for a status update on the backup.
December 12, 2007 at 8:52 am
I like your method more than altering timeout values. Altering timeout values can lead to some serious problems, especially if you do not set it back to the default. You could have another piece of the application stuck because it will not timeout properly.
I would personally go with the email notification as it adds less overhead to the app and gets the message accross.
December 12, 2007 at 9:04 am
I agree. Also, when you are setting timeout values for a backup to complete, you'll be chasing your tail. You could come across network or disk issues which could slow the process down and you'd get the same timeout. Not to mention a backup will grow in size and time of backup over time!
December 12, 2007 at 9:31 am
Adam Haines (12/12/2007)
Great point Clive :cool:.The only potential problem I see is the application cannot inform the user that the backup has completed or failed. This can cause a problem if the user believes that the backup is taking place, while in fact it has failed.
Perhaps not - but that's what the job operator notification is for. Define the job to send completion info via e-mail to the user (defined as the operator or one of the operators).
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
December 13, 2007 at 9:46 am
And I might add - even though you said the database is huge, I would make a strong effort to restore it to a test box just to be sure.
Viewing 15 posts - 1 through 15 (of 20 total)
You must be logged in to reply to this topic. Login to reply