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.
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.
When restoring SQL Server Transaction Log files, I have noticed a number of log backups taken over night that have the same First and Last LSN.
Do these files have to be restored as part of the chain or can they be skipped?
The transaction log is a serial record of all the transactions that have been performed against the database since the transaction log was last backed up.
So, if there were no changes in the database between transaction log backups the First and the Last LSN will be the same.
In short: yes, they can be skipped.
The only-slightly-longer answer: the reason that the first and last LSNs are the same for those backups is because nothing happened in that time interval to incite change in the log. That said, they'll also take no time to restore, so you're probably better off just restoring them than trying to account for this edge case if and when you need to restore them. Remember - the best plan in a crisis situation is often the simplest.
My DB Admin advised that I should regularly take backup of .ldf files. Fine, this SQL post here explains this beautifully.
Consider that a transaction is being done in SQL Server. And at the same time, a scheduled process tries to access the .ldf file for backing it up.
What happens ? How this works ?
You must read Article Understanding SQL Server backup by Paul Randal. That is the best I can see which is available and can explain you in details various aspects.
Coming to your question a transaction log backup includes all information from previous transaction log back or full backup that started the log chain. Backup simply means reading information froma file(data or log) and writing it to destination disk. The transaction any would work independed of log backup running. A transaction follow a WAL(write ahead logging) protocol, for practical purposes all transaction information is first written in log file and then changes are later made to data file. So when transaction is running it would not be affected by transaction log backup job which is running both are doing different task and are muttually exclusive events. Current backup would try to backup all logs which are marked as committed and would truncate the logs if no transaction requires it. If any portion of log is committed after log backup has read that portion it would not come in current log backup but would come under further log backup.
Transacion log backup has important role in crash recovery it helps in determining what all operations has to be roll forwared and what has to be rolled back. Without transaction log backup or transaction log crash recovery is not possible
You must also read Logging and recovery in SQL Server to know about life cycle of a transaction.
The excat answer as to what acctual steps happens inside is beyond scope of discussion as nobody can exactly tell you what would happen but reading the article would give you a good idea.
Please let me know if you have any further questions.
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
This morning I truncated my transaction before it's hourly backup. Since I truncated the transaction log, the backup failed. The error code I got was 0xC002F210. Any ideas why this happened?
The problem is caused by not having done a full backup before switching the data into SIMPLE recovery mode, shrinking the log file and then switching back to FULL recovery mode.
Why did you truncate the log instead of just backing it up? If you were running out of space you could have backed up the log and then shrunk the file, instead of truncating. Truncating messes with the backup chain and forces you to start over (by taking a new, full backup).
This is one of the reasons BACKUP LOG WITH TRUNCATE_ONLY has been deprecated, and actually won't run in SQL Server 2008. For some background reading:
http://sqlserverpedia.com/blog/sql-server-backup-and-restore/backup-log-with-truncate_only-like-a-bear-trap/
https://sqlblog.org/2009/07/27/oh-the-horror-please-stop-telling-people-they-should-shrink-their-log-files