1. What is dual-system cold backup of Oracle database?
Dual-machine cold backup, different from Oracle RAC, refers to multiple physical machines or virtual machines that can mount the same storage, and install the same database software and Oracle instance on each database server. After the server is turned off, switch to the standby server to continue to provide services.
2. What are the characteristics of dual-machine cold backup?
The dual-machine cold backup cannot work synchronously like Oracle RAC, and the efficiency is superimposed. Instead, one is working, and the standby server is in a shutdown or idling state. But this does not mean that there is no advantage in dual-machine cold standby.
First of all, in many scenarios, Oracle RAC cannot be used, such as a remote disaster recovery computer room. The disaster recovery computer room does not provide services under normal circumstances. The storage devices are synchronized with the host room through optical fiber cables, so the storage is synchronized. The database service itself needs to build a set of environments in both the main engine room and the disaster recovery room. A physical host can serve as a backup server for multiple business databases, and the actual overhead is not very large. When the server in the main computer room is destroyed, the synchronized storage mounted in the remote computer room can continue to provide services immediately.
Second, Oracle RAC is not suitable for all business types. Some businesses do not require too strong performance and ultra-high availability, and can tolerate service interruptions for about 30 minutes to an hour, so that operation and maintenance personnel have sufficient time to manually , Manual switching service. Such as some office systems, management systems and so on. The single-machine-based operation and maintenance mode of cold standby is simple to operate and has lower requirements for operation and maintenance personnel. As long as the mount is stored, and then the startup can be done, it is very convenient to manage. However, Oracle Rac often restarts the server itself due to network problems, and often restarts both of them as soon as it restarts. In addition to troubleshooting network failures, it is also necessary to troubleshoot RS232 serial ports, optical fibers and other failures, which often makes operation and maintenance personnel overwhelmed. . Therefore, for these cases, the dual-system cold backup method is easier to maintain, and the downtime switching speed is faster.
3. What are the requirements for dual-machine cold backup?
First, there must be two servers with similar configurations, preferably identical server hardware, which is very easy to implement on a virtualization platform. In a physical server, the cost is not particularly high, because the database of many services can share a standby machine.
Second, there must be a sharable storage medium. On ordinary virtual machines and PCs, a separate hard disk should be used for database files and backup files, so that after one server goes down, the hard disk can be unplugged, inserted into another server, and then the database can be started to continue running. If there are two servers using SAN storage, it is necessary to divide the ZONE of the fiber switch so that both servers can discover and mount the same piece of storage. If you are using an iSCSI device based on TCP/IP, like a SAN, two servers should be able to mount block devices on the same storage server. If it is a remote disaster recovery computer room, you can synchronize the storage in the local computer room with the storage in the remote location in real time through special settings on the storage gateway. From the application level, the speed of SAN mounting in this way is much faster than the back and forth speed of hard disks.
Third, a transferable IP can be understood as a virtual IP like in the LVS cluster. The client connects to the database through the virtual IP, and the database using this virtual IP is the active database, and the other one stands by.
4. How to allow multiple servers to mount the same VG?
In network storage solutions such as SAN and iSCSI, as long as both the active and standby servers can discover the shared storage device through fdisk, there is generally no problem. Whether it can be found depends on the planning of your storage link, which is related to the optical switch.
When a block device can be discovered by multiple servers, you can use one of them to create PV, VG, and LV, which can be discovered by pvscan, vgscan, lvscan, etc. on other machines. And can be mounted. However, if the non-cluster file format such as ext2, 3, and 4 is used for formatting, then the modification of one party will not be visible to others, but conflicts will occur. So at the same time we have to manually control only one server to mount this block device.
After the VG and LV are divided on the main server, you can mount them freely on the current server, but other servers need to activate the VG first, and then mount the corresponding LV. Before the LV in the VG created by other hosts is not activated, the result obtained by using the lvscan command is that the relevant lv is in the inactive state, as follows
[root@localhost ~]# lvscan inactive '/dev/rhel/swap' [16.00 GiB] inherit inactive '/dev/rhel/tmp' [10.00 GiB] inherit inactive '/dev/rhel/home' [10.00 GiB] inherit inactive '/dev/rhel/root' [50.00 GiB] inherit inactive '/dev/rhel/rpms' [74.50 GiB] inherit ACTIVE '/dev/rootvg/LogVol01' [151.80 GiB] inherit ACTIVE '/dev/rootvg/LogVol00' [8.00 GiB] inherit [root@localhost ~]#
use
vgchange -ay first half of lv path
Check again, you will find that the lv in the VG has become the ACTIVE state, and you can mount it at this time. Note that multiple hosts that can connect to the same storage can all be set to the ACTIVE state, but do not mount at the same time.
[root@localhost ~]# lvscan ACTIVE '/dev/rhel/swap' [16.00 GiB] inherit ACTIVE '/dev/rhel/tmp' [10.00 GiB] inherit ACTIVE '/dev/rhel/home' [10.00 GiB] inherit ACTIVE '/dev/rhel/root' [50.00 GiB] inherit ACTIVE '/dev/rhel/rpms' [74.50 GiB] inherit ACTIVE '/dev/rootvg/LogVol01' [151.80 GiB] inherit ACTIVE '/dev/rootvg/LogVol00' [8.00 GiB] inherit [root@localhost ~]#
Note that when inactive, the file /dev/rhel/swap does not exist and does not need to exist. When using vgchange, you only need to fill in the previous part, that is, /dev/rhel/ to activate.
5. Which files need to be placed on shared storage
Generally, when we install Oracle 12c/11g, we first install the oracle software, and then deploy the oralce instance. In the establishment of dual-machine cold backup, first install the oracle database on all machines, pay attention to the installation directory, parameters, etc. must be exactly the same, to be installed on the machine's own hard disk, so as to play a backup role. Then only install the oralce instance on the host, at which point it is necessary to specify which files should be placed on the shared storage.
In theory, when creating an instance, it is best to put everything related to the instance on the shared storage. To sum up, there are about the following points
Mainly: system table space, user-defined table space, .ctl control file, fast recovery area
These paths can be specified after installation. The default is /home/database username, so be careful when installing, otherwise it will be inconvenient to migrate under /home. There are mainly a few pictures
The following is the location of the database file, very important, do not use the default.
The following is the location of the fast recovery area, which is used to place the directory for the full backup and backup of the database generated by RMAN.
Below is the location of the archived logs
The following is the location of the system tablespace. Note that when you use the create tablespace command to create user tablespaces in the future, you should also pay attention to placing them on the shared storage, otherwise you will not be able to migrate smoothly.
6. How to synchronize the established instance of the primary server to the standby server
We set up a database instance on the primary server, do we need to set it up again on each standby server? In fact, no need, just place the generated spfile in the location specified by the standby server, and then change the listener.
After the database instance is established, oracle will generate a spfile to record the relevant configuration parameters of the database instance, including the fields of our database tablespace, control file, and location of the quick recovery area above. This spfile is generally placed in $ORACLE_HOME/dbs / Below, as shown in the figure below, will tell you after the database instance is established
Generally speaking, we can copy all the files (except init.ora) under the dbs directory to the same directory of the standby server.
Then we also need to set the environment variable of Sid on the standby server, edit ~/.bashprofile, set
export ORACLE_SID=xxxx
The specific value is the same as that on the main server.
Then you can use sqlplus / as sysdba to connect to the database on the backup server.
Suppose we mount the storage to the backup server at this time, execute startup, and find that it still cannot be started, and an error is reported
[oracle@newoadb2 ~]$ sqlplus / as sysdba SQL*Plus: Release 12.2.0.1.0 Production on Fri Apr 13 16:41:31 2018 Copyright (c) 1982, 2016, Oracle. All rights reserved. Connected to an idle instance. SQL> startup ORA-09925: Unable to create audit trail file Linux-x86_64 Error: 2: No such file or directory Additional information: 9925
This is because in addition to tablespaces, control files, and quick recovery areas that need to be shared, there is also a database audit log that needs a corresponding path, but database auditing does not require synchronization of each server, and there are not many people who use it, so it can be established directly. On each server's own storage.
When creating an instance, although there is no place to set it, the storage path of the relevant audit log will still be posted. We only need to ensure that each database server has this directory. The files in it do not need to be synchronized to make the database run normally. .
Therefore, we only need to ensure that the directory {ORACLE_BASE}/admin/{database name}/adump exists.
7. How to make the listener of the standby server connect to the database instance on the standby server
After establishing the relevant directory, we found that the database can be started normally, but an error will still be reported when using the JAVA client to connect, and it is fine to connect to the main server, because we have not configured a listener on the standby server, and the main server is in The listener was already set up for you when you created the instance, so the main server is fine
The error is as follows:
An error occurred while establishing the connection: Long Message: Listener refused the connection with the following error: ORA-12514, TNS:listener does not currently know of service requested in connect descriptor Details: Type: java.sql.SQLRecoverableException Error Code: 12514 SQL State: 08006
You need to add this SID listener item to the listener by modifying the file $ORACLE_HOME/network/admin/listener.ora
changed to
# listener.ora Network Configuration File: /u01/product/12.2.0/dbhome_1/network/admin/listener.ora
# Generated by Oracle configuration tools.
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(SID_NAME = database SID)
(ORACLE_HOME = /u01/oracle)
(GLOBAL_DBNAME = database name)
)
)
LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = localhost)(PORT = 1521))
)
)
Then use lsnrctl restart to restart the listener, and you can use the client to connect to the database normally.