In SQL Server, I get Full and Transactional Log Backup (full: once in a day, transactional: hourly during workimng hours). As far as I see, there are some advantages of transactinal log backup over differential backup. Rearding to these issues, could you clarify me about the following points?
1. When getting transactional backup hourly during employees continue their operations with the data, might there be some problems like deadlock, or corruption of the data? I use job script in SQL Server Management Studio to get backup, but have no idea how SQL Server treats the records that are currently started to be edited.
2. In general looking, what do you suggest for backup selection in addition to full backup? Transactional Log or Differential backup?
No :)
Backups using the backup command do not require locks on any user tables.
Transaction log backups are usually more frequent than hourly, would your company really be okay with loosing an hours worth of data if something bad happened to you database disks?
Your schedule needs to depend on what your requirements are for your RPO (recovery point objective) and RTO (recovery time objective). If can only sustain 5 minutes worth of lost data then a 5 minute transaction log backup is required. If you can only cope with 1 hour worth of downtime then you need to make sure that you have data backups that can be restored and recovered in that amount of time - the first part will depend on how optimized your restore is (ie how long it takes to read the backups from your backup drives and write the data files back to your data drives - https://www.mssqltips.com/sqlservertip/4935/optimize-sql-server-database-restore-performance/#:~:text=%20Optimize%20SQL%20Server%20Database%20Restore%20Performance%20,restore%20the%20database%20by%20using%20some...%20More%20 has some ideas. The second part will depend on how much transaction log data needs to be read and applied back to the database to recover it to the desired point.
You might find that you simply can't do full database backups fast enough, in those cases incremental backups could work as there's less data to write but SQL Server will then have to put it back together.
Of course, if the restore is happening manually then you also need to account for human time in there!
It's a good idea to try out your backup and recovery process (before PROD!), this way you can tell if you're going to need to optimize the process further.
Related
I need to take two backups before and after the day end process. If the EOD process starts at 10.00 p.m. The backup should contain all the data right at 10.00 p.m. before starting the EOD and the backup process should not impact the EOD process as well. Is there a way to achieve this?
Please note that I need to retrieve RMAN backups for disk and then tape.
A "snapshot" type of backup would only be necessary if you are running in NOARCHIVELOG mode, and you'd have to shutdown the entire database to do it as a "cold" backup (you can't get a logically consistent backup without transaction logs while the database is open for read/write activity). This would presumably impact your end-of-day process.
Assuming that the database is in ARCHIVELOG mode, and that you can run your backup as a "hot" backup while the database is up and running, you do not need to worry about the timing of your backup at all.
Run a backup whenever it makes sense based on system load or activity (being sure to backup the archive logs too), and if you need to recover from a backup later then recover to the exact point in time that you need - before or after your end-of-day process. See the documentation for Point in Time Recovery options: https://docs.oracle.com/en/database/oracle/oracle-database/19/bradv/rman-performing-flashback-dbpitr.html
The restore and recovery operation will restore from the backup and then re-apply all transactions to bring the database back to the desired point in time. The only thing the timing of the backup job would affect would be the number of transactions that might need to be re-applied after the data files are restored.
does a simple-recovery database records transaction logs when selected from a full-recovery database? I mean, we have a full-recovery database, and it records too much transaction logs, causing its size to grow.
my question is, does the simple recovery still has does its minimal logging even if the data are selected from a full-recovery model database? thank you!
One thing has nothing to do with the other. Where the data comes from does not affect logging of changes to the tables in the db it's going to.
However as Martin Smith pointed out this is solving a symptom, there's naff all point in having full recovery mode on if you (they??) aren't backing up the transaction logs frequently enough to make the overhead useful. Whole point of them, aside from restoring up to particular transaction in the event of some catastrophy in your applications is speed and granularity.
Please read the MSDN page for recovery models.
http://msdn.microsoft.com/en-us/library/ms189275.aspx
Here is a quick summary from MSDN.
1 - Simple model - Automatically reclaims log space to keep space requirements small,
essentially eliminating the need to manage the transaction log space
2 - Bulk Copy model -
An adjunct of the full recovery model that permits high-performance
bulk copy operations.
**The first two do not support point in time recovery!**
3 - Full model - Can recover to an arbitrary point in time
(for example, prior to application or user error).
If no tail log backup possible, recover to last log backup.
So your problem is with either log usage or log backups.
A - Are you deleting from temporary tables instead of truncating?
http://msdn.microsoft.com/en-us/library/ms177570.aspx The delete operating will log each row in the transaction log.
B - Are you inserting large amounts of data via a ETL job? Each insert will get logged in the T-Log.
If you use bulk copy and ETL that support (fast data loads), it will be minimally logged.
However, page density and fill factor come into play when determining the size of the T-LOG.
http://blogs.msdn.com/b/sqlserverfaq/archive/2011/01/07/using-bulk-logged-recovery-model-for-bulk-operations-will-reduce-the-size-of-transaction-log-backups-myths-and-truths.aspx
C - How often are you taking transaction log backups? After each backup, the T-LOG space can be reused. Resulting in overall smaller size.
D - How fragmented is the T-LOG? I suggest reducing and re-growing the log during a maintenance period. A 20% log to data ratio with hourly backups worked fine at my old company. It all depends on how many changes you are making. http://craftydba.com/?p=3374
In summary, these are the places you should be looking at. Not the old data in the system since it is probably not being modified.
Moving the old data to a read only reporting database so that ADHOC queries from novice T-SQL users might not be a bad idea. But that solves other problems, possible BLOCKING and DEADLOCKS in your OLTP database.
What are the consequences of a full DB Backup on the LSN?
Will it break the LogShipping that is already configured and running when a full DB backup is complete (if it changes the LSN).
Also what is the best way to perform a DB resilience.
Just have LogShipping configured
Have LogShipping configured (15 min interval) with weekly full backups?
Have a incremental backup every 15 mins and then a weekly full backup
Are there any great tools that would simplify the above process?
Full backups have no effect on the log chain except for the first full backup taken after database creation or after a change to the FULL recovery model. It will not break log shipping. What could break log shipping is if you took a manual log backup and did not apply that to your secondary database.
The best recovery strategy for your database depends completely upon your situation. How much data loss is acceptable? How long of an outage can you reasonably allow for a restore to occur? It's not possible for someone on an online forum to provide an answer that you should rely on for your recovery strategy. You need to research backup and recovery very carefully, understand it inside and out, then apply the strategy that is best for your particular situation. There are many tools out there for backup from companies such as Red-Gate, Idera, Dell, etc.
That being said, just having log shipping is absolutely not good enough.
Also, #Anup ... COPYONLY only prevents the differential bitmap from being reset. It does not impact log backups.
LiteSpeed works fantastic for your full backups, I would run a full backup daily and NOT weekly. Log shipping with or without Litespeed then to be done every 15 minutes is very typical. If you wait too long then Data from your primary to your secondary is too out of sync and you end up with errors based on what SQL Server has.
I always loved Red Gate products, but I have not used their log shipping / backup tools , only their data compare and their schema compare etc..
I believe Quest makes LiteSpeed and Quest I think is owned by Dell.
Currently we are stuck having to monitor the log shipping and it is not full proof. I would prefer Mirroring or Replication.
i have a production DB that i need to periodically truncate logs in.
how can i get this done in a system that can have no down time and is a stand-alone SQL server?
i seem to remember there was a SQL command i can run... so i was thinking to set it up as a step in the backup job so that after a backup is cut i will truncate the SQL logs.
You should not need to truncate logs.
If the logs are growing, then you probably have FULL recovery and no log backups. If this is OK, then you have a long running open transaction or similar but check backups first
if you have log backups, then do them more frequently. IMHO daily is pointless. We run every 15 minutes.. or are you mixing up full and log backups?
If the recovery model is SIMPLE and logs are growing, then the log needs to be that size (eg to allow for major index rebuild) or again you have a probably have a long running open transaction.
See MSDN And Paul Randal's blog
Ok so for standard, non-mirrored databases, the transaction log is kept in check either simply by having the database in simple mode or by doing regular backups. We keep ours in simple as we have SAN snapshot backups taking place and there is no need for SQL backups.
We're now going to mirroring. I obviously no longer have the choice of simple mode and must use full. this obviously leads to large log files and the need for log backups. That's fine I can deal with that; a maintenance plan that takes a log backup and discards any previous ones. I realise that this backup is essentially useless without its predecessors but the SAN snapshots are doing the backups.
My question is...
a) Is there a way to truncate the log file of all processed rows without creating a backup? (as I can't use them anyway...)
b) A maintenance plan is local to a server and is not replicated across a mirrored pair. How should it be done on a mirrored setup? such that when the database fails over, the plan starts running on the new principal, but doesn't get upset when its a mirror?
Thanks
A. If your server is important enough to mirror it, why isn't it important enough to take transaction log backups? SAN snapshots are point-in-time images of just one point in time, but they don't give you the ability to stop at different points of time along the way. When your developers truncate a table, you want to replay all of the logs right up until that statement, and stop there. That's what transaction log backups are good for.
B. Set up a maintenance plan (or even better, T-SQL scripts like Ola Hallengren's at http://ola.hallengren.com) to back up all of the databases, but check the boxes to only back up the online ones. (Off the top of my head, not sure if that's an option in 2005 - might be 2008 only.) That way, you'll always get whatever ones happen to fail over.
Of course, keep in mind that you need to be careful with things like cleanup scripts and copying those backup files. If you have half of your t-log backups on one share and half on the other, it's tougher to restore.
a) no, you cannot truncate a log that is part of a mirrored database. backing the logs up is your best option. I have several databases that are setup with mirroring simply based on teh HA needs but DR is not required for various reasons. That seems to be your situation? I would really still recommend keeping the log backups for a period of time. No reason to kill a perfectly good recovery plan that is added by your HA strategy. :)
b) My own solutions for this are to have a secondary agent job that monitors based on the status of the mirror. If the mirror is found to change, the secondary job on teh mirror instance is enabled and if possible, the old principal is disabled. if the principal was down and it comes back up, the job is still disabled. the only way the jobs themselves would be switched back is the event of again, another forced failover.