An overview of Oracle Rman architecture

A Server Management Recovery

Recovery Manager, Recovery Manager, Jianchen RMAN. The RMAN implementation has been server Management recovery (Managed RECOVERY:SMR). SMR is the ability of a database to perform the operations needed to ensure the success of its own backups, which can be accomplished by relying on built-in code in the Oracle RDBMS kernel. SMR's function is mainly reflected in the ability to reduce the user's operation.

Two RMAN Use Program

Rman is a concrete implementation of SMR, which is provided by Oracle, and Rman is a stand-alone application that establishes client connections to the Oracle database to access backup and recovery packets within the database. The core command of RMAN is the interpreter, which accepts the commands entered and converts them into remote calls (Remoteprocedure Call:rpc) that are executed on the database.

To emphasize, RMAN only does a small amount of work. While time coordination is important, the specific work of backing up and restoring a database is actually done by the process on the target database, which refers to the database to be backed up. Internal packets of an Oracle database can turn the pl/sql blocks in Rman into system calls that can be written to the disk system of the database server or to the disk subsystem of the database server.

The RMAN utility is part of the database utilities. The Database utilities is a set of command-line forms of use, including Import,export,sql*loader and

Dbverify. Typically, Rman is installed automatically when Oracle is installed. Rman Sub-enterprise and standard Version 2, if only the standard version of Rman, then Rman can only allocate one channel.

The RMAN utility consists of two parts, an executable file and a recover.bsq file. The recover.bsq file is essentially a library file in which the executable files extract code from the recover.bsq file to create a pl/sql call that executes on the target database. The recover.bsq file is the backbone of the entire operation. This file remains linked and logically constitutes an Rman client usage. Note that the version of the RECOVER.BSQ file and the executable file must be the same, otherwise it will not work properly.

The RMAN utility has a unique, sequential, predictable usage: Interpreting commands in Pl/sql calls that are executed remotely on the target database. The RMAN utility completes all the backup, restore, recovery, and processing backups we need to do. The executable interpreter is responsible for interpreting these program commands and gathering information based on the user's request. If an I/O operation is required (that is, a backup command or a RESTORE command), RMAN prepares another process block when the information is returned and passes the procedure block back to the target database. These procedures are responsible for performing system calls to the OS for the specified read or write operation.

RMAN and Database permissions

RMAN needs access to a variety of packets that exist in the SYS mode on the target database, as well as the right to start and close the target database. Rman is therefore usually connected to the target database as a SYSDBA user. If a user with no SYSDBA permission is connected to the target database, RMAN reports a ora-01031:insufficient privileges error.

In general, most UNIX systems have an Oracle user, which is a member of the DBA Group. This is the first user to install Oracle software, and if you are logged on as an Oracle user, what identity connection in Rman becomes unimportant, it will always be used as a sysdba to connect to the target database, and can access the SYS mode, as well as the ability to start and shut down the database. On the Windows platform, Oracle creates a ORA_DBA local group and adds users who install Oracle software to this local group.

If you are logged on as a user other than a member of the DBA group and need to use Rman, you must create and use a password file to connect to the target database. If you are using a client system to connect to Rman over the network, you also need to create and use a password file.

Three Network topology for RMAN backup

RMAN is a client application that connects to the target database through an Oracle NET connection.  If the target database is in the Oracle_home home directory and runs the Rman executable file that is also located in this home directory, the ORACLE net connection is a local connection. As long as the appropriate ORACLE_SID variable is set in an Oracle environment, you do not need to provide an Oracle NET alias for this connection. Otherwise, we must configure the Tnsnames.ora file, specify the target database in the file, and complete the operation at the location where the Rman will be run.

The general tendency to run Rman in the oracle_home of the target database is the simplest and most intuitive way to avoid compatibility problems in a mixed environment. We need to be responsible for backups spanning multiple Oracle databases and versions in this hybrid environment. You can also use OEMs to process them.

3.1 Remotely running Rman

If you are responsible for managing many databases. It is best to consolidate applications on a single client system so that the Tnsnames.ora file content can be better managed on this client system. If the recovery directory (recovery catalog) is used in the Rman configuration, this client/server-side model is not confusing because it generates more than one Oracle NET connection each time the Rman is operated. On the other hand, when you run an Rman on a different system (or a different Oracle_home home directory) than the target database, we need to create a password file so that more configuration and management is required on each target database.

Recovery directory: Used to store the history of the Rman backup, which contains metadata about the time the backup occurred, the backup content, and the size of the backup. The history also contains the critical information needed to recover the backup. The metadata is disjunction from the default location (the target database control file) and remains in the user-mode database table.

If you want to establish a remote connection between Rman and the target database, you need to create a Tnsnames.ora entry that uses a dedicated server process to connect to the target database. Because Rman cannot use a shared server (usually called a multithreaded server or MTS) to establish a database connection.

Myicd =

(DESCRIPTION =

(address = (PROTOCOL = TCP) (HOST = Daviddai) (PORT = 1521))

(Connect_data =

(SERVER = dedicated)

(service_name = MYICD)

)

)

3.2 Running local Rman in the oracle_home of the target database

Running Rman locally from each target database is actually the only way to manage large enterprises with hundreds of or thousands of database goals. Because Rman has always had compatibility issues, tying Rman.exe to the target database can save time in the long run. Although there are some drawbacks to deploying Rman backups in this way, this is also the best way.

Running Rman locally means that you only need to connect the database locally, without having to build the password file and configure the Tnsnames.ora file. But this simplicity is also a flaw. Because once the recovery directory is introduced or the database copy operation is performed, the problem before us will be rained.

Four Database control files

Control file is responsible for the physical structure of the database, control file control database to find the location of physical files, and control each file currently contains (or should contain) header information, including data file information, redo log information and archive information. The control file also contains a snapshot (snapshot) of each file header for the key files associated with the database.

Because the control file stores the database file information, Rman uses the control file to obtain the information needed for the backup, by using the control file to compile the file list, to obtain checkpoint information, and to determine recoverability. By directly accessing the control file, Rman can compile a list of files without requiring the user to create a file list, which avoids a very tedious step in backing up the script, and does not need to change the script when adding a new file. The control file stores information about the new file, so Rman can also get this information from the control file.

The control file can also be used as an Rman catalog. When Rman completes a backup of any part of the database, it adds a record of the backup in the control file, along with checkpoints that describe the start and end times of the backup.

This is also one of the main reasons for exponential growth in the size of the Oracle 7 to Oracle 8 versioning file: Rman records exist in the control file. These records in the control file are typically metadata, which is recorded in the actual backup and can be stored in the recovery directory.

4.1 Reusing records in control files

The control file divides internal data records into two categories: circular reuse and non-cyclic reuse of records. A circular reuse record contains information that can be removed from the control file.  For example, archived log history information can be deleted and will not affect the product database. Non-circular reuse records are records that cannot be deleted, and if the control file is out of space due to such records, the records are deleted for more space. Non-cyclic reuse records include a list of data files and a list of log files.