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.
Related
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.
I'm using SpecFlow with Selenium for doing UI testing on my ASP.NET MVC websites. I want to be able to restore the database (SQL Server 2012) to its pre-test condition after I have finished my suite of tests, and I want to do it as quickly as possible. I can do a full backup and restore with replace (or with STOPAT), but that takes well over a minute, when the differential backup itself took only a few seconds. I want to basically set a restore point and then revert to it as quickly as possible, dropping any changes made since the backup. It seems to me that this should be able to be done very quickly, without needing to overwrite the whole database. Is this possible, and if so, how?
Not with a differential backup. What a differential backup is is an image of all of the data pages that have changed since the last full backup. In order to restore a differential backup, you must first restore it's base (i.e. full) backup and then the differential.
What you're asking for is some process that keeps track of the changes since the backup. That's where a database snapshot will shine. It's a copy-on-write technology which is to say that when you make a data modification, it writes the pre-change state of the data page to the snapshot file before writing the change itself. So reverting is quick as it need only pull back those changed pages from the snapshot. Check out the "creating a database snapshot" example in the CREATE DATABASE documentation.
Keep in mind that this isn't really a good guard against failure (which is one of the reasons to take a backup). But for your described use case, it sounds like a good fit.
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
I have an SQL Server 2005 instance whose full backup (.BAK) failed due to low disk space. However half hourly transaction log backups continue (.TRN). Assuming I have an older full backup, could these continuing transaction logs be used to restore the database?
i.e. do the transaction log backups only run from the last successful backup and ingore any intermediate failed full backups?
I would have thought the failed backup would be rolled back, so the ongoing transaction log backups plus a full database restore prior to these, should be sufficient to restore a database.
Having said that, I would fix this issue as soon as possible, it's not a good position to be in.
You will need ALL the logs taken since the last full Backup.
You cannot roll forward a log if you have lost a previous log.
Have a look here to determine the LSNs and status of your failed backup.