...

• Reporting Replicas

• Test/Dev Snapshots

Option 1:  Reporting Replicas

Reporting Replicas can be described as follow:

...

• When using this option keep in mind the time difference between the primary and the standby database. 

...

Option 2:  Test/Dev Snapshots

Test/Dev Snapshots can be described as follow:

• The second option is to allow for read-only as well as read-write snapshots to be created of the database. This is to cater for a number of use-cases including the following:

  1. Allowing reporting or data extraction from a snapshot (read-only) of the database at a particular point in time - the snapshot can be recreated on a regular basis if required as the process only takes a minute or two to complete.  

  2. Application Testing - when you need to test the upgrade of an application or new changes, you can create a read-write snapshot of the standby database, which is a copy of the primary and the ideal place to test an upgrade. Once done you can remove the snapshot, run the test again or when ready continue to doing the actual upgrade - remember to follow the recommended approach of testing and following change control.

  3. Development or Test environments - many sites do not really use their Standby Database environment.  Now you already have licensed this environment for Oracle (Remember a standby database site must be fully licensed similar to your primary - if not sure please discuss with your Oracle Partner or Account Manager).  Now what you can do is get more value of your standby database environment investment by not having the environment idle, but using it for Development and Testing.  You can create a full blown test or development environments on this system, but why not make use of Snapshots. Test and Development environments tend to be short term, meaning they are refreshed on a regular basis - a process that can take a lot of time.  Using snapshots of the standby database is another way to get more value of this.  As Copy-on-write technology is used (see LVM snapshot documentation for more in-depth knowledge on this) you will not require large amounts of disk space - now this depends on how long-lived the snapshots will be if they are short term, you might not need much storage, but if you use the longer term and your snapshots are used heavily, you might need more disk space.  

  4. Quick and easy DR testing.  When testing your DR site, many will activate the standby database, run the application test and then recreate or restore the standby database.  This can be a complex long process, why not make use of a snapshot - remember this is a snapshot of your standby database at a given point in time, meaning you can activate the snapshot, run your tests and then remove it.  In effect, you did test the standby database validity as a DR site. Thi sis a much faster approach and can save time.

Licensing

Dbvisit Standby Reporting Replicas and Test/DEV Snapshots do not require additional licenses from Version 10.0 onwards. This option is available only on Linux platforms and can be used with the regular licenses provided as part of support agreements.

Pre-Requisites

Before starting with this new option, it is important to understand what the requirements are.  

...

1. You must have sufficient IO capability in the Volume Group underlying storage (Physical Disks - Using SSD based storage is always recommended for Database Storage)

   • Databases will perform IO and if you create snapshots there will also be IO requirements for these.  Make sure you test your configuration and have sufficient IO capacity - especially if you are looking at using snapshots for Development or Testing environments.

2. Make sure your Volume Group (VG) in which the Logical Volume (LV) is located has sufficient disk space
   

   • When creating a Logical Volume (LV) it is created in the Volume Group which you can kind of see as a storage pool, made up of a number of disks - now please note this is just a simplification of it.  

   • Make sure that the Volume Group have sufficient free space, this is important.  Snapshots will initially not take much space, but if left long term and if you have a busy origin (source of the snapshot) then more disk space will be required.  

   • When you create snapshots based on the specific Logical Volume, a small portion of storage will be used for the snapshot.  Now the beauty of snapshots is that it does not require a lot of disk space, it is however depending on how much the database from which the snapshot was created is changing as well as if you are using a read/write snapshot - which means the snapshot will use more storage for new changes. 

   • When you create the snapshot you have to specify a size for the snapshot, this should be set to an appropriate value to allow the snapshot to keep enough data to stay valid (consistent).  Example, if you do not expect more than 30% changes to your database during the life time of the snapshot, then setting the snapshot size to 30% of the standby database (source/origin) size is a good start.  

   • IMPORTANT:  The ideal is to use snapshots for short term - and not days or weeks. Again the longer they are used - more storage might be required.

3. Memory 

   • You may ask, why is the memory required, the answer is easy - for every new snapshot, you are going to mount and start an Oracle Database instance, and this will require memory.  When Dbvisit Standby creates the snapshot, you will be asked to supply the memory to be used for the SGA.  Now in most cases, you might want to keep this small, but depending on what you are planning to do with the snapshot, whether it is for reporting or development or testing, you might want to allocate a lot more memory to it.  So make sure you have sufficient memory on the system you are planning to use the snapshot option.  You do not want to run out of memory and start using SWAP space as this is really bad for database environments and will slow the whole system down.  You should aim to always have a little bit of free memory on the system, never over allocate.

4. The Dbvisit Standby executable - dbvsnap - must be able to execute the LVM commands as the root user.  

   • There are a number of ways you can do this.  Normally the Dbvisit Standby software is run as the "oracle" software owner (usually the "oracle" UNIX user).  And many sites will have provided this user with the permission to run commands as the super user via "sudo" rights.  Now to allow the Dbvisit Standby Snapshot option, you will be required to allow this "oracle" UNIX account running Dbvisit Standby to execute the following commands as the root user:  lvcreate, lvremove, lvs and vgs

   • For more detail on how to do this, please review the "sudo" option provided by Linux where you can add the "oracle" user to the "sudoers" file with the required permission to execute these commands.

5. Sufficient disk space under the DBVISIT_BASE folder

   1. When creating the snapshots there will be metadata written to the DBVISIT_BASE/standby/meta folder for each snapshot.

Recommendations

There are a number of ways you can go about using this new Dbvisit Standby Snapshot option. The first is that you can run it on your current standby database environment - if you meet the above requirements, most important having the standby database fully located on a Logical Volume (LV).  

The second option is that you can also create a new configuration, using the Dbvisit Standby Cascading option on a second Standby Database Server where you have created a specific area for the database using a Logical Volume.

Important Warnings & Best Practice

Following these rules & suggestions will ensure you have a trouble-free experience using the Dbvisit Standby Snapshot Utility:

...

Note that the snapshots will be created, then mounted, and when not required anymore will be unmounted then removed, which is why the above options are required.

Configuration

It is important to mention early on that when you are looking at using this new Dbvisit Standby Snapshot option, you should use the Central Console (GUI).

...

Reporting Replicas

From the multiplatform control center, choose the configuration and you can see the options for Reporting Replicas ( 1 ) and Snapshots( 2 )

...

The server in which snapshots are running has the following

...

Test/Dev Snapshots

The test/dev snapshots are single snapshots that can be used for reporting/testing purposes. These snapshots can also be used for DR testing purposes. The single snapshots can be retained based on the space available in the logical volume as the space occupied by the snapshots can increase based on the test/development happening on the database and also compensate for the changes happening in the DR database due to archivelogs being applied on the standby.

...