Oracle Tutorial: User-managed backup

Note: Cold backup-you can back up a database in ARCHIVELOG mode or a database in NOARCHIVELOG mode. Hot Backup-only ARCHIVELOG databases can be backed up. In other words: ARCHIVELOG mode-cold backup or hot backup. NOARCHIVELOG mode-only cold backup is supported.

Cold backup steps:
1. List the latest list of all related files to be backed up.
2. Use the shutdown normal, shutdown immediate, or shutdown transactional command to close the Oracle routine.
3. Use the operating system backup utility to back up all data files and control files. You can also back up and redo log files, although this is not required. You should also back up the parameter files and password files.
4. Restart the Oracle routine.

Hot Backup steps:
As long as the following two standards are met, you can back up tablespaces or data files while using the database: • set the database to ARCHIVELOG mode. • Enable the Oracle automatic archiving (ARCn) process or manually archive and redo log files to ensure that online redo logs are archived.
How to perform online tablespace backup:
1. Run the alter tablespace... begin backup command to set the data file or TABLESPACE to the BACKUP mode. This prevents the serial number in the data file header from changing, so that logs can be applied from the backup start time. Even if the data file is in backup mode, it can still be used for normal transaction processing. SQL> alter tablespace users begin backup SQL> ALTER DATABASE BEGIN BACKUP;
2. Use the operating system backup utility to copy all data files in the tablespace to the backup storage. If you back up each tablespace in sequence, the log serial numbers in the backup file may be different. Cp/ORADATA/u03/users01.dbf/BACKUP/users01.dbf
3. After backing up the data files in the tablespace, run the following command to set them to the normal mode: SQL> alter tablespace users end backup SQL> ALTER DATABASE END BACKUP;
4. archive Unarchived redo logs to archive the redo logs required for restoring tablespace backup, as shown below: SQL> alter system archive log current
Repeat these steps for all tablespaces, including SYSTEM and restored tablespace. The interval between the alter tablespace begin backup and alter tablespace end backup commands should be minimized, because the modified block write redo log file will generate more redo information. Therefore, we recommend that you back up a tablespace online each time.

Hot Backup practice:

1. Determine the tablespace to be backed up

1. SQL>SelectFile_id, file_name, tablespace_nameFromDba_data_filesWhereTablespace_name ='Users';
3. FILE_ID FILE_NAME TABLESPACE_NAME
4. ------------------------------------------------------------------------------------------
5. 4/u01/app/oracle/oradata/orcl/users01.dbf USERS
7. SQL>Select*FromV $ backupWhereFile # = 4;
9. FILE # status change #TIME
10. ----------------------------------------------------
11. 4NOTACTIVE 0

2. Start backup

1. SQL>AlterTablespace usersBeginBackup;
3. The tablespace has been changed.
5. SQL>Select*FromV $ backupWhereFile # = 4;
7. FILE # status change #TIME
8. ----------------------------------------------------
9. 4 ACTIVE 992599 month-10 month-11

3. Copy data files

1. SQL>! Cp/u01/app/oracle/oradata/orcl/users01.dbf/u01/app/oracle/backup/users01.dbf

4. End backup

1. SQL>AlterTablespace usersEndBackup;
3. The tablespace has been changed.
5. SQL>Select*FromV $ backupWhereFile # = 4;
7. FILE # status change #TIME
8. ----------------------------------------------------
9. 4NOTACTIVE 992599 month-10 month-11

Manual backup control file:

Create a binary image:

1. SQL>Alter DatabaseBackup controlfileTo '/U01/app/oracle/backup/control01.ctl';
3. The database has been changed.

Create a text tracking file:

1. SQL>Alter DatabaseBackup controlfileToTraceAs '/U01/app/oracle/backup/control01. SQL';
3. The database has been changed.

This will generate an SQL statement script for creating the control file. This script is divided into two parts: noarchive mode and archive mode.

Full recovery and resetlogs

Many friends often misunderstand full recovery and resetlogs, and think that using resetlogs to open a database is not completely restored. This is incorrect. As long as you have the current log file, you can perform full recovery on the database. Whether you need to use resetlogs to open it depends on whether the backup control file is used. If the backup control file is used, you need to use the resetlogs method to open the database. If you have the current control file or restore it by recreating the control file, you do not need to use the resetlogs method to open the database.