Oracle Database Backup skills

Use the techniques listed below to ensure that you do not forget the key steps during the weekly database backup process. Back up the primary database once a week. If you create, modify, or stop a database, add a new SQLServer message, add or stop a connection to the server, or add a record device, perform manual backup. Back up msdb data once a day

Use the techniques listed below to ensure that you do not forget the key steps during the weekly database backup process. Back up the primary database once a week. If you create, modify, or stop a database, add a new SQL Server Message, add or stop a connection to the Server, or add a record device, perform manual backup. Back up msdb data once a day

Use the techniques listed below to ensure that you do not forget the key steps during the weekly database backup process.

Back up the primary database once a week. If you create, modify, or stop a database, add a new SQL Server Message, add or stop a connection to the Server, or add a record device, perform manual backup.

Back up the msdb database once a day. It is generally very small, but important, because it contains all SQL Server jobs, operations, and scheduled tasks.

It is necessary to back up the model database only when you modify it.

Use the SQL Server Agent to schedule your backup work.

If there are ready-made resources in your production environment, back up the production database to a local disk or network server (with the same switch ). Then, copy the backup file/device to the tape. In the case of many hardware faults (especially in RAID systems), the disk is often intact (inact ). If the backup file is on the disk, the recovery speed will be much higher.

Backup development and testing databases must at least use the SIMPLE recovery model.

In addition to scheduled and scheduled backups, you must back up your database after unrecorded (nonlogged) Batch operations (such as batch copy), index creation, or model change.

If you are using a SIMPLE recovery model, remember to back up your database after truncate transaction records.

Use documents to record your recovery steps. At least record these steps and pay attention to the location of all important files.

Before the truncation record, that is, before all committed transactions are cleared from the record, all the information is stored in the transaction record. In the SIMPLE recovery model, if the record is truncated during a CHECKPOINT period (when the SQL Server memory buffer writes a disk), it occurs automatically, but can also be executed manually. This is why the SIMPLE recovery model does not support point-in-time recovery. In the FULL and BULK_LOGGED recovery models, when transaction records are backed up, transaction records are truncated unless you explicitly state that they are not truncated.

To back up transaction records, use the backup log command. Its basic syntax is very similar to the BACKUP command:

Backup log {database}

The following example shows how to back up transaction records to a logical device named LogBackupDevice:

Backup transaction Northwind TO LogBackupDevice

If you do not want to truncate the transaction record, use the NO_TRUNCATE option as follows:

Backup transaction Northwind TO LogBackupDevice WITH NO_TRUNCATE

Just basic knowledge

Although I have only outlined the basic knowledge of database restoration in this article, you can still find the correct direction through these skills. To avoid unnecessary (data loss) panic, you need to back up the primary database every week and back up msdb every day.