Date: Thu, 28 Mar 2024 23:26:12 +0000 (UTC) Message-ID: <430558476.7.1711668372971@0e43523b2cd0> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_6_1597221443.1711668372971" ------=_Part_6_1597221443.1711668372971 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
What is a cascading= standby database?
It is creating a standby database, from a= standby database. The concept is not difficult, and to configure it using = Dbvisit Standby Version 8 is really easy. There are a number of use cases f= or this type of configuration. A second standby database may be needed to b= e used for reporting and only update it once or twice a day, where the orig= inal standby database is kept up to date with the primary in case of disast= er strikes. Instead of sending logs from the primary to a second standby da= tabase, 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 arc= hived redo multiple times to standby sites =E2=80=93 but just ship it once,= and then from the first standby ship the logs to the second or third stand= by.
Before getting into how easy it is to do = this, there are a few things to highlight first:
1.)&=
nbsp;You cannot perform a Graceful Switchover (GS) between the primary and =
the secondary (cascading) standby databases. You will only be able to perfo=
rm a GS between the primary and the first (primary) standby database.2.) The second standby database can still be used for a=
ctivation, reporting (if opened read-only), backups or even DR testing.
=
3.) To configure the cascading standby database optio=
n in Dbvisit Standby Version 8, you must create a second DDC file. To creat=
e the DDC file you must select the primary (first) standby as your source o=
r =E2=80=9CPrimary=E2=80=9D database. Dbvisit Standby Version 8 will set a =
new parameter CASCADE=3DY in this DDC file which indicates that the source =
=E2=80=93 or primary as seen in this case, is actually a standby database.<=
br>4.) Once the DDC file is created, the Create Stand=
by 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 ARCSOURC=
E 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 configuratio=
n. 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 th=
e second standby database.
6.) COMPRESS and UNCOMP=
RESS should be set to =E2=80=99N=E2=80=99 (none) in the primary DDC file. T=
he archive logs that are stored on the standby server must be in an uncompr=
essed format. Note that by default compression is enabled in Dbvnet during =
network transfer and using COMPRESS option in Dbvisit Standby Version 8 is =
not recommended. The option is still provided =E2=80=93 but the default opt=
ion for a new configuration compression in the DDC file will be disabled an=
d default Dbvnet compression will be used.
The environment in this example looks as = follow:
4 servers running Oracle Linux 6:
The first few images below will provide a= summary of the existing configuration, followed by the steps to create the= secondary (cascading) standby database.
Main Menu:
In the screen below we can see the main D= bvisit Standby Version 8 Central Console.
From the main screen, we navigate to = ;Manage Hosts to see the Primary Host =E2=80=93 DBV1,= as well as DBV2, configured.
They are both accessible and we can see t= hat communication with the agents (dbvagent) running on these hosts are suc= cessful.
If we move =E2=80=9CBACK TO MENU<= /strong>=E2=80=9D and select =E2=80=9CMANAGE CONFIGURATIONS=E2=80=9D from the main console, we can see the Dbvisit Standby Configurat= ion (DDC) being listed =E2=80=93 DEVCDB in this example.
From the above we can=
see the following:
1. We are now on the Configurations page where you can create, edit o=
r remove the Dbvisit Standby Configuration (DDC)
2. In this example, we have a DDC called DEVCDB
3. The primary or =E2=80=9CSource=E2=80=9D host in this example is db=
v1
4. The standby or =E2=80=9CDestination=E2=80=9D host in this example =
is dbv2
5. The Version in this example shows that we are using update 8.0.12 =
with minor version 18922
In this example, we have already created = the first standby database called DEVCDB which is running on the dbv2 serve= r.
The =E2=80=9CActive Task List=E2=80=9D sh= ows this completed task and if we click on it, we can see the details as sh= own below:
In the above figure, we see that if we cl= ick on the Active Task (1) we will get the details of the task that was exe= cuted (2) =E2=80=93 which is the Create Standby Database (CSD) process.
Adding the new secondary standby = host.
The next step is to add the second standb=
y host. Now it is important that the Dbvisit Standby Version 8 software cor=
e components (Dbvnet, Dbvagent and Standby Core) are already installed on t=
his host and that Dbvnet and Dbvagent are running.
We navigate from the main screen to =E2=80=9CMANAGE HOSTS=E2=80=9D. From he=
re the following screen will be displayed.
<= /p>
From this screen, we select =E2=80=9CNEW= =E2=80=9D (2) as shown above to add a new host.
The following screen will be displayed:= p>
<= /p>
Creating the =
new host (See above):
1. Add the new hostname (Make sure that the system running the Centra=
l Console =E2=80=93 Dbvserver, are able to see the new host and that the ho=
stname used here does resolve)
2. Specify the port number the agent is listening on (7891 is the def=
ault and recommended port)
3. Specify the passphrase provided during the installation of the age=
nt
4. If a connection to the server can be established, meaning the Cent=
ral Console can communicate with the agent, the Operating System dropdown l=
ist will automatically be populated.
5. Click on =E2=80=9CCreate New Host=E2=80=9D to add the new host
We now have three hosts known to the Cent= ral Console =E2=80=93 dbv1, dbv2 and dbv3
<= /p>
Creating the Cascading Standby DD= C.
From the main Central Console screen navi= gate to =E2=80=9CMANAGE CONFIGURATIONS=E2=80=9D. The following screen= will be displayed:
Click on =E2=80=9CNEW=E2=80=9D to start t= he process of creating a new DDC file.
The =E2=80=9CCreate New Configuration=E2= =80=9D screen will be loaded which will guide you through the creation proc= ess.
In summary, the values below are supplied= :
1. We select =
=E2=80=9Cdbv2=E2=80=9D =E2=80=93 which is the first standby database server=
, as our =E2=80=9CSource Host=E2=80=9D. Remember we want to create a =
standby from a standby, so we specifically pick the source host that runs o=
ur first standby here.
2. Review and accept the license
3. The databases known on this system will be listed. In this example=
, we pick the standby database DEVCDB that is running on dbv2 as our =E2=80=
=9Csource database instance=E2=80=9D
4. This option is crucial. You must specify the ARCHSOURCE location a=
nd it must be the same as the DEVCDB ARCHDEST location
5. By default, we use DBVNET and leave port at 7891
6. Specify the standby host =E2=80=93 =E2=80=9Cdbv3=E2=80=9D which is=
going to run our secondary standby database.
7. Specify the Oracle SID that will be used for the secondary standby=
database =E2=80=93 you can adjust this if required, but using default prov=
ided value (which is the same as the primary Oracle SID) is recommended.
8. In the example used here, we are not using ASM, and the slider is =
left at =E2=80=9CNo=E2=80=9D to indicate the standby server will not be usi=
ng ASM.
9. The ARCHDEST location is the location used by Dbvisit Standby for =
copying archive logs onto the standby server. This location is not the same=
as the Oracle Archive Log destinations and should never be the same or loc=
ated in the database recovery area.
10. The Dbvisit Base install location is specified which is the defau=
lt /usr/dbvisit
11. The Oracle Home path is confirmed.
12. The Database Unique Name is specified. You can adjust this and if=
you are creating two standby databases on the same standby server for the =
same primary database, the Unique Name must be different. Otherwise, =
the default value is recommended, which is the same as the primary database=
Unique Name.
13. Here we need to specify the Dbvisit Standby Configuration (DDC) f=
ile name. This should be adjusted so that it does not match the DDC name we=
already used for our first Primary/Standby configuration. In this example =
I used DEVCDBDR
Once all the values h= ave been entered and confirmed, click on =E2=80=9CSUBMIT=E2=80=9D to start = the creation process which should only take a few seconds.
Once done a DDC file will be created and = the new DDC will be listed under the configurations page as seen below:
We can see that the DDC name DEVCDBDR (1)= was created and that the source host is dbv2 (2) and the destination host = is dbv3 (3).
If you click on the pencil (edit option) = you can see the detail of the DDC as shown below.
The key value I would like to highlight h= ere is the new DDC parameter called CASCADE which is now s= et to a default value of =E2=80=9CY=E2=80=9D. This is the key parameter tha= t is set to indicate that we are dealing with Cascading Standby Databases h= ere. Also, note the ARCHDEST and ARCHSOURCE values. As mentioned earlier, i= t is important that the ARCSOURCE value of this configuration match the ARC= HDEST location of the 1st standby database configuration.
The next important step is to apply the l= icense key for this configuration. The license configuration is easy. You n= eed to use the license key provided to you on the purchase of your license = =E2=80=93 in this example a trial license key is used. You need to navigate= to the License main menu option and then select= the DDC DEVCDBDR (shown in the image below as pointed out by number 1). Th= en once you filled in the license key and submitted it, you can review and = will see the license key is valid and in this case have an expiry date =E2= =80=93 due to the trial license key used.
Creating the Cascading Standby Da=
tabase (the second standby from the 1st standby)
We now navigate to the Create Standby Database (CSD) main menu option. The =
screen below is displayed.
From here we select our DDC (2) and then =
select the option to create a =E2=80=9CNEW DATABASE=E2=80=9D (3). The defau=
lt settings for the new standby database is displayed.
Note that in this case, the secondary standby database server has the exact=
same layout as the original standby server (dbv2) and the primary server (=
dbv1).
This page is split over two images to show all parameters.
In the example as seen above, we do not s=
elect the use of transportable media (1). This is a useful option if you ha=
ve a large database with low network bandwidth and you would like to use ex=
ternal media to transfer the backup to the second standby server. In this e=
xample, we will backup local to /usr/tmp from where the backup will be copi=
ed to the standby server /usr/tmp.
We now select the option to =E2=80=9CCreate Standby Database=E2=80=9D (3) =
=E2=80=93 which will now start the process. A new task will appear on the =
=E2=80=9CActive Tasks=E2=80=9D list and if selected, the details of the sta=
ndby creation process are displayed =E2=80=93 see image below:
Once the creation is complete, we will se= e the task has a green checkmark. We can review the task as shown below whe= n we click on the task (see image below).
Updating the new secondary standb=
y database
Once the new secondary standby database is created, we can start the proces=
s of shipping logs to the standby database. But at this stage, it is import=
ant to note that the secondary standby database now running on dbv3, is rel=
iant on the archive logs that is available on the first standby database ru=
nning on dbv2. To ensure we have logs available on the first standby databa=
se, we first run the process to ship and apply logs from primary (dbv1) to =
the first standby (dbv2). Then once we have successfully sent and applied l=
ogs between these, we can now send logs from the first standby database run=
ning on dbv2 to the secondary standby on dbv3. The arrows and numbers in th=
e image below show the order of the steps to be performed.
You should now have two standby databases= , with the second standby receiving its log files from the first standby. The next step would be to either schedule a CRON to send and apply logs to = the secondary standby.
Creating and maintaining the secondary stand= by database from the first one is easy and the process is quite similar to = what you would have done for a normal configuration.