I have to restore one database 'XYZ' onto another standalone SQL server.
'XYZ' database is the part of mirroring on principal server. I want to know if I take another FULL backup just prior to restore, will it affect the mirroring or mirroring will get disturbed. What should be the proper steps to do this activity.
Can I do database backups for a mirrored database?
Yes, it is allowed to do database backups in the Principal database.
However, it is not allowed on the Mirror server since which is in the
Restoring state.
with some restrictions : Restrictions on Backup and Restore During Mirroring:
While a database mirroring session is active, the following restrictions apply:
Backup and restore of the mirror database are not allowed.
Backup of the principal database is allowed, but BACKUP LOG WITH NORECOVERY is not allowed.
Restoring the principal database is not allowed.
Check this link for more information
Related
When I restore an SQL server database from backup, I usually do it from a .bak file on the disk. There is also an option to restore from Database as a source - see this picture
Is this backup restored from the database log file?
It's from existing backups from databases that have been created on the server. It's essentially a list of all databases that have at least one recorded backup in the msdb database.
Source: MSDN
Select the database to restore from the drop-down list. The list contains only databases that have been backed up according to the msdb backup history.
My database has filled the drive with the transaction log, its about 15GB and the drive is now full. The database won't start. The database is currently offline.
I can access SQL Server Management Studio, but not sure what to do next to fix up the transaction log, and get the database back on line.
You would appear to have the database set to use the Full recovery model.
The log is supposed to be truncated when the database is backed up using a backup tool that integrates with SQL Server (at that point you have a snapshot of the DB at that point in time for recovery), but if you don't have an appropriate regular backup in place, the log tends to bloat out to fill the available disk space.
If you don't require the full recovery model, then change to the Simple Recovery model (right-click on the database node in SSMS, select Properties and go to the Options page) and then shrink the DB.
during the setup of the mirroring database in sql server 2012, i accidentally made 2 backup of the original database.
after restoring the database on the mirror server, the databases were not synchronized.
to solve the issue, i changed the recovery model from 'full' to 'simple' and back to 'full' again. and then backed up the database again. when restoring it on the mirror server the mirroring procedure.
my question is why does the synchronization fail if i take more than one full backup of the original database?
It's because of the log chain, mirroring is kind of like restoring transaction log backups to the other server but automatically, for it to work, you need an unbroken log chain from a full backup to the last t-log backup, so the log chain will look like this (with nice sequential LSNs):
Full-1->LogA->LogB->LogC->Full-2->LogD->LogE->LogF etc...
So in the example above, if you restored the Full-1 backup, you can restore log backups A,B,C but not D,E,F. You can only restore those if you restore Full-2.
In mirroring, you take a Full backup of the DB and then restore it, SQL server then looks at the Log Sequence Numbers (LSNs) and transfers transactions that aren't present in the restored mirror database, if you take another full backup, you break the chain of sequential LSNs.
In your case, it's like you restored Full-1 and then tried to apply Logs D,E,F to it, there is a gap in the sequence numbers. It should have worked for you if you had just re-restored the second accidental backup that you took to the mirror server and then started mirroring. By changing the recovery model, you completely reset the log chain and have to start again.
I just started at a new company and I'm responsible for the reporting sql server. Their process to keep the reporting db in sync with the production db is to constantly keep the production db in Standby/Read-Only mode so that they can apply a transaction log that comes each night from the production db.
What I need is to grab a copy of the current reporting db so that I can put it on a test server, unfortunately I can't take a full backup of it in the standby/read-only state.
I realize that I can get it out of that mode by doing "restore database 'dbname' with recovery". However after I do that, can I get the db back into the Standby/Read-Only mode to continue applying the nightly transaction log?
No. You can't return a database to Standby/Read-Only mode after using the restore WITH RECOVERY option.
When a database is in recovery mode, there may be incomplete transactions in the database, which means the database is not in a ready state. Either, you restore the next transaction log backup, which will complete the transactions, or you do the restore 'WITH RECOVERY', which will roll-back open transactions. Once, the open transactions are rolled-back, the next transaction-log backup can't be restored, because the database is no longer in a state expected for the transaction-log restore.
EDIT:
An alternative is to restore a copy of the most recent production full backup and restore the appropriate transaction-log backups to that database.
I wanted to reduce the size of my log file in SQL SERVER 2005, which grown to 16 gigs, so I created a backup and used the dbcc shrinkfile command to shrink it. All that is set. Now what should I do with the backup file that is created - should I delete it? What impact will deletion have?
Deleting the file will mean you will not be able to do point-in-time restoration - you will only be able to restore to the last database backup you made.
If point-in-time restores are unimportant to you, you can safely delete the backup - otherwise store it somewhere safe (like a tape, or other removable storage).
If you're not using anything that requires a transaction log (e.g. database mirroring) you could also consider switching the database into "simple recovery mode" which avoids transaction log use anyway.