New answers tagged

0

I can suggest two things that we've used in the past to improve restore times for a similar scenario of a database being used for automated tests: Shrink the log file before taking the backup to absolutely minimize the size of the backup. In our case this made a surprisingly large difference. Ensure you are taking a compressed backup. I just did a quick ...


2

As the databases user are identical across the servers, you can simply maintain the SID same for the logins across all the SQL Servers while the purpose of the login/users is same. Following is an example to create login with same SID, this is onetime activity across the servers (while you aware of server level permissions). create login test_login_1 with ...


0

I do not remember the rman command hearth, but it should be something like: DUPLICATE DATABASE prod TO dupdb DBID 8675309 # DBID of source database SPFILE UNTIL SCN; The "only useful information" you can find in source database is DBID. When you provide DBID using command, rman can fetch all the remaining information form catalog. So just omit ...


0

In short, each backup stores a series of Log Sequence Numbers (LSNs) which represent the backup chain and guide the restore to properly apply the correct transactions. The LSNs are sequential, and therefore the restore process applies the backups in order of their LSNs. Additionally, one of the types of LSNs is called the DatabaseBackupLSN which identifies ...


0

If you created the dump with -c and don’t want to drop and recreate the database, then you will have to doctor the dump file to remove the DROP and CREATE statements (and anything else you don’t want changed). The edited file can be fed to psql using the -f option.


1

When you restore a transaction log after restoring a full and/or differential, the transaction log you restore can include the time covered by that full/differential, and that will be handled by the restore process, skipping already committed transactions from the backup. Then, you just need the log that covers the time that's not in the full/differential. ...


1

Let's have a look at your options: Full backup and applying to it subsequent log backups. This option allows you to restore the database to any point-in-time, provided you have an unbroken chain of TLOG backups. Advantage: With this option you have a physical copy of the database backup that can be restored to other servers. The backup is not linked to the ...


6

Then suppose at 8.30pm I do a manual log backup (thus truncating the log) and delete this file. Thus the subsequent log backup at 9pm will have incomplete log. The transaction log backup created at 8:30 pm contains transaction log records from 8:00 PM through 8:30 PM. The transaction log backup created at 9:00 pm contains transaction log records from 8:30 ...


7

If we just take your question and analyse the information stored in the msdb database, then the answer is: Yes, a BACKUP DATABASE ... with the COPY_ONLY parameter not set, will have an impact on the backup chain (history...). This is because the database_backup_lsn (LSN = Log Sequence Number) which is stored together with the backup information is changed ...


8

A full (or differential) backup do not affect or break the log backup sequence. This is regardless of whether you specify COPY_ONLY or not. It will influence the restore GUI and what backup it choses as a base for the restore sequence, though. But that is only a GUI thing.


0

Here is the command that would restore only the database named $DB_FROM from $BACKUP_FILE backup file, with restored database name $DB_TO (instead of $DB_FROM): (sed '/^-- Current Database: `/q' "$BACKUP_FILE"; sed -n "/^-- Current Database: \`$DB_FROM\`/,/^-- Current Database: \`/p" "$BACKUP_FILE") | sed "s/\`$DB_FROM\`/\`$...


3

A snapshot backup can break your diff backup "chain". (It will never by itself affect log backups unless it does something ...bad like what J.D. mentions.) Whether or not it affects your differential backup depends on whether it is produced in a way so that SQL Server considers it to be a copy only backup or not. A very old version of Veeam, for ...


4

Other types of backups shouldn't break the restore chain unless they are specifically configured in a way to do so. For example, I just ran into this issue with Veeam and it managing my Transaction Logs externally which was stepping on my maintenance plan I had running to backup the Transactions Logs internally. You can find more information about that in ...


2

A Snapshot is not really a type of database backup in SQL Server. Rather it is a separate feature to quickly restore the database to a point in time place as opposed to using a Full Backup. You can read about the differences and how Snapshots are used in this article. But the important thing to note is you wouldn't be able to restore Transaction Log Backups ...


Top 50 recent answers are included