Page 603
be long enough under most conditions. However, if your redo logs are particularly large or you archive to a slow medium (such as optical disc), you should make sure that your delay gives Oracle plenty of time to archive a redo log.
Backing Up the Archived Log Directory to a Backup DeviceJust as you did in the cold backup section, you need to back up the directory containing the archived logs to a backup device.
TIP |
Because Oracle writes a full block to the redo logs for each write operation instead of just the changed information, the redo logs will fill up much faster when tablespaces are in the backup mode. You should try to schedule your online backups when there is the least activity on your database. Pay particular attention to scheduled batch jobs. They tend to be very write intensive and can easily be overlooked because they are often run by automatic schedulers. |
DBAs supporting Oracle in a Windows NT environment will find hot backups to be much easier than their command-line counterparts. Again, you'll use Oracle's Backup Manager to perform the actual backups. When you start Backup Manager while the database is running, a dialog box similar to Figure 24.3 is displayed.
FIG. 24.3
Backup Manager
when used for performing hot
backups.
You need to decide where to place your backup of the database. You can either back up to a directory on disk or to a tape drive. Fortunately, Backup Manager indicates how much space will be needed to back up the database in the manner you have selected. This information will help you decide where to back up the database. Follow these steps to perform an online backup of your database:
Page 604
After this procedure completes, your database has been successfully backed up. Enterprise Manager has finished backing up your database and taken all tablespaces out of backup mode.
TIP |
Backup Manager does not back up the init.ora, config.ora, or archived log files used to start your database. Although these files would typically be backed up during normal OS backup procedures, you should double-check with the system administrator to ensure that these very important files are backed up regularly. |
When you created logical backups, you used the EXP utility supplied by Oracle. Because the export is in a proprietary format, there is only one (official) complementary utility, IMP. Despite the name, IMP will not import data from other systems. The appropriate utility for this is SQL*Loader.
IMP follows the same syntax as EXP, and many of the options are identical. Listing 24.2 shows the output of IMP HELP=Y.
Listing 24.2 Output of IMP HELP=YKeyword Description (Default) Keyword Description (Default) -------------------------------------------------------------------------- USERID username/password FULL import entire file (N) BUFFER size of data buffer FROMUSER list of owner usernames FILE output file (EXPDAT.DMP) TOUSER list of usernames SHOW just list file contents (N) TABLES list of table names IGNORE ignore create errors (N) RECORDLENGTH length of IO record GRANTS import grants (Y) INCTYPE incremental import type
Page 605
INDEXES import indexes (Y) COMMIT commit array insert (N) ROWS import data rows (Y) PARFILE parameter filename LOG log file of screen output DESTROY overwrite tablespace data file (N) INDEXFILE write table/index info to specified file CHARSET character set of export file (NLS_LANG)
The following keywords may be used in conjunction with the IMP program as described below.
USERID is the user ID/password that IMP uses to log in to the database to perform the import. At the minimum, you must have the CONNECT SESSION privilege enabled to use IMP. If your export file is a full export, you must have the IMP_FULL_DATABASE privilege to import it. A DBA user can do anything, of course.
TIP |
You can use IMP with remote databases using the usual USERID/PASSWORD@REMOTE_NAME convention. |
FULL specifies if you are importing the entire database or not. It defaults to N.
BUFFER is used to determine how many rows will be loaded into memory before writing to the database. The default value is OS dependent. The larger your buffer, generally the faster your import will run (and the more system memory that will be used). You can compute the number of rows that will fit into the buffer as follows:
rows=buffer_size/maximum_row_size
If the table contains a LONG column, only one row will be in the buffer at one time.
FROMUSER defines the names of the source schemas in the export file. Unless you are also using the TOUSER keyword, the objects will be imported into identically named schemas in the database. If a schema named in FROMUSER does not exist (and no TOUSER was specified), objects will be imported into the USERID schema running IMP.
FILE is the name of the export file (or of the tape device).
TOUSER is the name of an existing user schema in the database into which the database objects can be loaded. This keyword compliments the FROMUSER keyword. Generally this is used for importing objects into schemas named differently from the schemas that were exported.
SHOW set to Y just displays the contents of the export file; nothing is actually committed to the database.
TABLES is a list of one or more tables that should be imported. If this omitted, all tables are imported.
IGNORE set to Y enables the export to just continue if an object cannot be created. This is useful if you are importing rows into a table that already exists.