my tool is deleting data from a table and it takes a lot of time 1/2 days,
meanwhile there are scheduled backups,
can sql server handle this situation or is better to stop the tool?
I can't try the tool because i don't have enough time
SQL Server backups are online, so there is no need to stop your processes during a backup.
However the backup must contain the log records for transactions that occur during the backup, so that the database can be recovered to a consistent state when restoring the backup.
So if your delete process runs in one big transaction, the backup can't complete until it has captured all the log records up to the point when you commit or rollback the long running transaction. So to avoid large backup files and long-running backups, you may want to not take backups while it's running.
But if it commits a series of smaller transactions, it should be fine to take backups while it's running.
Related
I have Windows scheduler calling a program that does a full database backup every day at 3:00am.
I would also like to do a transaction log backup every ten minutes.
What is the best way to sync these?
I understand that transaction logs are independent of full back-ups, but is it a problem if the two different tasks both do a backup at 3:00am? i.e. the database is asked to produce a full back-up and a transaction log back-up at exactly the same time.
Perhaps I should have one task and query SQL Server to see if the last full backup was more than 24 hours ago. If not, then do a transaction log backup.
As long as you're running SQL 2005 or higher, you can run log backups at the same time as a full backup without issue. Glossing over a bit of detail, log backups are based on the last completed full backup at the time that the log backup started. The only time it really matters is when you'd need to do a recovery and even then, it's only ever "contentious" (i.e. "which full backup should I restore given that I want to restore to this point in time?") for log backups that are taken while a full backup is in progress.
If ever you need to do a point-in-time restore for such a time, you'd work backwards. That is, first find the log backup that contains said point in time. Then, to find the full backup that it's based on, look at the database backup lsn for that log backup in either msdb.dbo.backupset or by running restore headeronly on the log backup. From there, find the full backup that has that value as the checkpoint lsn. Now, you just need to restore that full backup (using the norecovery option) and every log backup based on it up to and including the log backup you identified in the first step (again, all using norecovery). Then run restore database [yourDB] with recovery to run crash recovery and you're back in business.
Hypothetical question:
If a maintenance plan is scheduled to run a full backup of several databases while they're online, and during this time other jobs are scheduled to run (stored procedures, SSIS packages etc), what happens to these jobs during the backup?
I'm guessing either:
The job is paused until the backup is completed, then they're run in the same order they were scheduled to.
Or
SQL Server works out what tables will be affected by each scheduled job and backs them up after the job completes?!
Or
SQL Server creates a "snapshot" of all the tables before the back up starts, any changes to them (including changes made by the jobs run during the backup) are added to the transaction log, which should be backed up separately.
...are any of my ideas correct?!
Idea #3 is the closest to what happens. The key is that when the backup operation completes, the backup file will be in a state that allows for the restore of the database to a consistent state.
From the documentation:
Performing a backup operation has minimal effect on transactions that
are running; therefore, backup operations can be run during regular
operations. During a backup operation, SQL Server copies the data
directly from the database files to the backup devices. The data is
not changed, and transactions that are running during the backup are
never delayed. Therefore, you can perform a SQL Server backup with
minimal effect on production workloads.
...
SQL Server uses an online backup process to allow for a database
backup while the database is still being used. During a backup, most
operations are possible; for example, INSERT, UPDATE, or DELETE
statements are allowed during a backup operation.
I am a programmer, with a side job as an involuntary DBA.
I have a maintenance plan that does a full backup and a 'check database integrity' every night. I backup transaction logs every 10 minutes. The transaction log backup size spikes after the database backup - exponentially bigger. I used to rebuild indexes and statistics every night - I thought that is what was causing the transaction log spike - but removing those steps didn't change anything.
Mirroring our backups on slow connections would be helped considerably if there wasn't this massive spike - so I am hoping it is something I am doing wrong. Can anyone suggest anything?
If you are only running the log backup from 6am to midnight, then the very first log backup at 6am is backing up all the database activity that has occurred in the 6 hours since the last log backup.
This is entirely normal, and probably has nothing to do with the fact that your database backup takes place at 4am.
Since you are on SQL2008, the warning in my other answer doesn't apply, and you should be fine with running the log backups 24 hours.
Is this SQL 2000?
In SQL 2000, you're not supposed to run the log backup while the full backup is executing, or "bad things can happen", like blocking, or hugely bloated log files.
See this ServerFault post for "The Word" from "The Man", Paul Randal, who used to be in charge of the SQL engine at Microsoft.
See this follow-up post for some ideas for skipping the log backup while the full backup is executing.
In SQL 2005 or later, this restriction no longer exists, and you shouldn't have trouble running log backups and full backups at the same time.
While your full backup is running, transaction backups will not run. So how long does your full backup take? The transaction log will not be truncated during this time by transaction log backups.
I am developer so need your advice on how to plan for it
I am having sql server 2008.
I am going to through what they have in maintance wizard
And found that they have full, differential and transaction log.
So if i take one full back once a week then differential backup every day. Not sure how transaction log fit into this.
I assume sql server is saving transaction log some where so in case of failure I can restore from last differential backup coupled with full backup.
What i need to use transaction log on top of it? Where is transaction log saved?
I need this for application data loss issue, if in case some action made it delete some data so i need ability to go back point in time.
You must backup your log too, explicitly. Schedule a job to backup the log at short intervals (15 minutes to an hour usually). When you do a recovery, you apply the full backup, then the newest differential and then all the log backup after the differential.
Only with log backup can you restore the database at a specific moment, using the 'WITH STOP AT'. See: How to: Restore to a Point in Time.
Also to recover from a crash, you backup the log tail then apply the recovery (full->differential->logs->tail) and hopefully occur no data loss at all.
A Zero loss strategy require the involvement of replication in some form. Then you'll also need a failover server to account for replication time before the "slave" server is fully up to date.
Even with transaction log backups your still at risk for losing X data, where X is your transaction log backup interval.
Maybe edit your question?
Let's say I have a very large database. Its backup starts at midnight and finishes at 02:00 am.
When I recover that backup am I gonna have the state of the database at midnight or 02:00 (or something else)?
Going one step further, let's say that I have multiple databases which contain references to each other's elements. If I backup all databases in parallel starting at the same time, when I recover all of them am I going to have the state of all databases at the same point in time?
The backup process in SQL Server backs up the data files and portions of the transaction log, so it'll be the state of the database at 2am.
You can only guarantee consistency of committed transactions across databases if the backup stops at exactly the same time. This is probably not something you want to rely on, so I'd recommend using frequent transaction log backups in addition to whatever nightly full strategy you're using.