...
It is creating a standby database, from a standby database. The concept is not difficult, and to configure it using Dbvisit Standby Version 9 10 is really easy. There are a number of use cases for this type of configuration. A second standby database may be needed to be used for reporting and only update it once or twice a day, where the original standby database is kept up to date with the primary in case of disaster strikes. Instead of sending logs from the primary to a second standby database, just send it from the first standby database. Using it this way you can also reduce the load on your primary and not double up on shipping archived redo multiple times to standby sites – but just ship it once, and then from the first standby ship the logs to the second or third standby.
...
1.) You cannot perform a Graceful Switchover (GS) between the primary and the secondary (cascading) standby databases. You will only be able to perform a GS between the primary and the first (primary) standby database.
2.) The second standby database can still be used for activation, reporting (if opened read-only), backups or even DR testing.
3.) To configure the cascading standby database option in Dbvisit Standby Version 910, you must create a second DDC file. To create the DDC file you must select the primary (first) standby as your source or “Primary” database. Dbvisit Standby Version 9 10 will set a new parameter CASCADE=Y in this DDC file which indicates that the source – or primary as seen in this case, is actually a standby database.
4.) Once the DDC file is created, the Create Standby Database (CSD) process for the secondary standby is exactly the same as what you would be familiar with when creating the first standby database.
5.) The location used for the ARCHDEST and ARCSOURCE is crucial when using cascading standby databases. The ARCHDEST
location used for your first standby database MUST be the same location used for the ARCSOURCE for the cascading standby configuration. This is important as Dbvisit Standby will detect and pick up the archive logs that are located in the Dbvisit ARCHDEST location to be shipped to the second standby database.
6.) COMPRESS and UNCOMPRESS should be set to ’N’ (none) in the primary DDC file. The archive logs that are stored on the standby server must be in an uncompressed format. Note that by default compression is enabled in Dbvnet during network transfer and using COMPRESS option in Dbvisit Standby Version 8 10 is not recommended. The option is still provided – but the default option for a new configuration compression in the DDC file will be disabled and default Dbvnet compression will be used.
...
- kiwi701 – Primary Database Server
- kiwi702 – Standby Database Server (first standby)
- kiwi703 – Cascading Standby Database Server (second standby)
- kiwi704 – Dbvisit Standby Version 9 10 Central Console
- Oracle Database 12.2 installed and configured on kiwi701, kiwi702, kiwi703
- Oracle 12c Database DEV running on kiwi701
- Standby Database DEV running on kiwi702 (with kiwi701 as primary)
- Dbvisit Standby DDC file for Primary (kiwi701) to Standby (kiwi702) called DEV
- Dbvisit Standby Version 9 10 installed on all systems into /usr/dbvisit. This includes Dbvnet, Dbvagent and Standby Core on kiwi701, kiwi702 and kiwi703. The Central Console (dbvserver) is installed on kiwi704.
- In this example, the secondary standby server kiwi703 is using the exact same directory structure as the first standby – which is also the same directory structure that is used on the primary. This is the recommended approach – a primary and standby database environment should match.
...
In the screen below we can see the main Dbvisit Standby Version 9 10 Central Console.
From the main screen, we navigate to Manage Hosts to see the Primary Host – kiwi701, as well as kiwi702, configured.
...
From the above we can see the following:
1. We are now on the Configurations page where you can create, edit or remove the Dbvisit Standby Configuration (DDC)
2. In this example, we have a DDC called DEV
3. The primary or “Source” host in this example is kiwi701
4. The standby or “Destination” host in this example is kiwi702
5. The Version in this example shows that we are using version 9.0.0v10
In this example, we have already created the first standby database called DEV which is running on the kiwi702 server.
...
The next step is to add the second standby host. Now it is important that the Dbvisit Standby Version 9 10 software core components (Dbvnet, Dbvagent and Standby Core) are already installed on this host and that Dbvnet and Dbvagent are running.
We navigate from the main screen to “MANAGE HOSTS”. From here the following screen will be displayed.
...