Configure Oracle Archiving and Backup¶
If you are running the Oracle instance in a production environment there are some additional steps to take notice of.
When to use this information:¶
These steps are mandatory for a production environment.
Note: Run as SYS! Start SQL*Plus and log on as user SYS.
If your installation of IFS Cloud is a production environment you must make sure that archiving of Redo Logs is activated. Otherwise Oracle cannot recover to the last completed transaction if a crash occurs.
Checklist for putting the database in Archive log mode:
- Invoke SQL*Plus and connect as a user with SYSDBA privileges.
- Shut down the database instance using the NORMAL, IMMEDIATE, or TRANSACTIONAL option:
- Take a complete offline database backup including all data files and control files. You can use operating system commands or RMAN to perform this operation.
This backup can be used in the future for recovery with archived redo log files that will be created once the database is in ARCHIVELOG mode.
- Change your init.ora file. If you have created your database using Oracle Flash Recovery Area functionality the parameter DB_RECOVERY_FILE_DEST is used to specify storage for archived log files, if not, the parameter LOG_ARCHIVE_DEST is used. IFS and Oracle recommends using the Oracle Flash Recovery functionality.
Set values for initialization parameters:
# if using Oracle Flash Recovery Area DB_RECOVERY_FILE_DEST=<your_Flash_Recovery_Area> DB_RECOVERY_FILE_DEST_SIZE = <you_Flash_Recovery_Area_Size> LOG_ARCHIVE_START = TRUE # if NOT using Oracle Flash Recovery Area LOG_ARCHIVE_DEST = <your_log_archive_dest> LOG_ARCHIVE_START = TRUE
- Start the instance and mount the database:
- Place the database in ARCHIVELOG mode:
ALTER DATABASE ARCHIVELOG;
- Open the database:
ALTER DATABASE OPEN;
- Shutdown database
- Backup the database
- Startup database
- Verify your changes and that archiving works: execute the following command in SQL*Plus:
ARCHIVE LOG LIST
and check visually that the files are created on your archive destination.
Note: Remember to set the Database in NOARCHIVELOG mode during installation and upgrade. Otherwise thee installation/upgrade will generate lots of redo log information and performance will decrease. After installation/upgrade has finished set the database in ARCHIVELOG mode. Always take a backup of the database before installing/upgrading the database.
Setup Database Backup¶
Make sure to create a functional backup strategy for your production environment.
This is what you at least need to backup from a database perspective:
- All data files (one or more data file per tablespace)
- All control files (should be mirrored on several disks)
- All archive logs since last backup
- Password file, init.ora or spfile
- Eventually backup the alert log.
There are different types of backups and you need to choose the right solution for your needs. The optimal backup solution would include a combination of offline, online and exports.
Offline backup requires you to shut down the database and the take a file copy backup of all files described above. You also need to find a time window large enough to complete the backup.
Online backups allow you to backup database files on a running database without shutting down the database. Online backup requires that the database be run in Archive log mode.
- For each tablespace you need to enter the following command:
Backup the data files
Continue these commands for each tablespace in the database.
2. After that you should backup the Archive logs
First make sure that the archive logs are written by entering (twice):
ALTER SYSTEM SWITCH LOGFILE;
ALTER SYSTEM SWITCH LOGFILE;
3. Make both a binary and text backup of your control files. Create a text copy as follows:
ALTER DATABASE BACKUP CONTROLFILE TO TRACE AS 'c:\backup\control.txt';
4. Create a binary copy as follows:
ALTER DATABASE BACKUP CONTROLFILE TO 'c:\backup\control.ctl';
5. Backup the rest of the files
The above file backups are convenient to complement a data backup. Export allows you to extract data to a binary file that can be used to restore a table removed by mistake.
Last but not least make sure that your backup strategy works. Simulate a disk crash and verify your backup by making a complete restore of your database.