Smart Database Technology

Rapidly growing New Zealand software company launches real-time database replication product to immediate success
Demand for product sees Dbvisit make first sale prior to launch

Date: 18 August 2011
For immediate release

Dbvisit Software Ltd, developers of affordable disaster recovery solutions for Oracle® Database Standard Edition sites worldwide, announce the release of  Dbvisit Replicate to immediate success. A leading Software-as-a-Service (SaaS) health informatics company in the US has chosen the product to enhance their service offering; accessing its real-time Oracle to MySQL database replication functionality to provide affordable real-time business reporting for their customers.

“Dbvisit Replicate has immediate appeal for businesses looking for an affordable, real-time Oracle database replication solution,” says Arjen Visser, CTO & Founder of Dbvisit. “We listened to what our customers and partners were telling us and are pleased to have made our first sale prior to launch.”

Dbvisit Replicate’s ability to share, migrate, synchronise and consolidate data in real-time effects benefits at all levels of a business. By providing improved database resiliency, offloading processing workloads and facilitating the integration of diverse platforms, operating systems and databases, Dbvisit Replicate presents businesses with a real opportunity. They now have the ability to minimize administrative system downtime, realize operational cost efficiencies in infrastructure, facilitate real-time business reporting and improve their users’ overall systems experience.

http://www.dbvisit.com/replicate_download.php

For further information please contact:

Libby Russell, Marketing Manager
Arjen Visser, CTO & Founder
Tel: +64  (0)9 950 3301
www.dbvisit.com

About Dbvisit Software Limited
Businesses in over 60 countries worldwide with Oracle® Database Standard Edition software trust Dbvisit to protect and share their data enterprise-wide. By eliminating the need to upgrade to Oracle® Enterprise Edition to access Data Guard or to purchase Oracle ® Golden Gate, our customers can save significantly on their disaster recovery and data replication solutions.

Our products are designed to be ‘set and forget’. They are simple to install and manage, functionally rich and come with comprehensive documentation and support. We provide peace of mind for our users, freeing up their valuable time to focus on other business activities.

Dbvisit Software Ltd is a wholly owned subsidiary of Avisit Solutions Limited, founded in 2000. We are headquartered in Auckland New Zealand with sales offices in the USA and France. www.dbvisit.com

6.0.08 (9 August 2011)

New features:

1. Extend Dbvisit functionality to cope with closed threads in RAC
   environment.

2. AMM module is now called regardless of the fact some archive logs reside
   in ASM on the source, to process multiple archive destinations. ASM
   archive locations are skipped.

3. If log archive destination is not set up for the database, use default
   values of ORACLE_HOME/dbs/arch or ORACLE_HOME\rdbms, for versions 10.2+.

4. Separate checkpoint and log switch; Dbvisit now does not perform
   checkpoint during normal processing, only a log switch (if required).

Fixes:

1. Global FLASH_DIR_NUM default value changed from 40 to 7.
2. When parsing a value for log_archive_dest*, check if extra attributes
   like MANDATORY etc are separated not only by a space but by a comma.

Download from http://www.dbvisit.com/download.php

6.0.06 (16 July 2011)
New features:

1. CSD (create standby database) now compares Dbvisit Standby installation between primary and standby and copies executables from primary if different.
2. Improved algorithm of searching for ASM archive logs in multiple locations, and under FRA-style date directories, to be shipped to the standby.
3. Allow one-way communication of Dbvisit Standby from primary to standby for ultra secure configurations which only allow one-way traffic. Set BLIND=Y to enforce this, but there is reduced Dbvisit Standby functionality (no checkums, no log gap reporting, no Resync and no creation of standby database options available).

Fixes:

1. Dbvisit Standby could not cope with Oracle reserved words used for tablespace names in SQL statements (like INDEX) – fixed.
2. Dbvisit Standby restarted a database in restricted mode during shutdown that potentially lead to generating extra archive logs and issues during graceful switchover – fixed.
3. Global variable LOGDIR set to value of LOGDIR_DR on the standby server.
4. Queries of dictionary tables called by ora_list_dictionary function altered to format the display of checkpoint_change#.
5. Dbvserver scheduler was leaving behind zombie processes – fixed

Dbvisit Standby can be downloaded from http://www.dbvisit.com/dbvisit_download.php

For more information please on Dbvisit Standby please see http://www.dbvisit.com/dbvisit_new_features.php

We definitely promote using RMAN for backups of your Oracle database. With RMAN you are able to recover up to the last moment before failure (if you have archive log mode enabled). This is as opposed to a facility like export dumps where you are only able to recover to the point when the export was made (or at some point in time before).
With RMAN you can also restore individual files and tablespaces. With export dumps you can restore individual tables but the transactional integrity is not guaranteed if you restore individual objects.

Recovery catalogue
RMAN can be used with or without a recovery catalogue. A recovery catalogue is a repository in a separate database. Usually this recovery catalogue holds the RMAN catalogue of several databases. If you use RMAN without a recovery catalogue, then the recovery information is held in the control files of the database. Even with the recovery catalogue, backup information is held in the control files of the database (incase the recovery catalogue is not available).

RMAN and standby database
If you are not replicating the RMAN catalogue database, then you can use RMAN without a recovery catalogue for initial backups when you failover to the standby database. When a standby database is failed over and becomes the primary database, a resetlog operation occurs and this invalidates all previous backups. After the initial RMAN backups on the new primary server have taken place and things have settled down, you can recreate a RMAN catalogue database to continue RMAN backups with a catalogue.

This may be better explained with the following steps:
ServerA -> primary server
ServerB -> standby server
1) Normal RMAN backups of primary database on ServerA using catalogue.
2) Failover occurs to standby database on ServerB. This now becomes primary database.
3) RMAN initial backups of new primary database on ServerB, using no catalogue.
4) Create new RMAN catalogue database.
5) RMAN backups of primary database on ServerB using catalogue.

The other alternative is to use RMAN without a catalogue for normal backups. This will simplify the fail over process as the re-creation of the catalogue is not needed.

There are no precautions for using RMAN in conjunction with Dbvisit Standby on the primary server. However, there are the following to points consider:

1) If you are using Dbvisit Standby to manage the archive log files on the primary server, you have to let RMAN know that Dbvisit Standby has deleted archive log files. For more information please see:http://www.dbvisit.com/forums/showthread.php?t=13

2) If you set LEAVE_COMPRESS_SOURCE=No (in the Dbvisit DDC file) then Dbvisit Standby will leave the archive files in an uncompressed state and RMAN will be able to find them and backup them up.

3) If you use RMAN with nocatalog, then the RMAN backup information is stored in the primary database controlfile. If you use graceful switchover (or role reversal), then the backup history information in the control file will be lost as a new control file is built during the role reversal process. The only way around that is to use a catalog.

One of our customers attempted to activate the standby database in a test scenario and received the following message:

SQL> alter database activate standby database
ERROR at line 1:
ORA-01195: online backup of file 2 needs more recovery to be consistent
ORA-01110: data file 2: '/u01/oradata/blldb/undotbs01.dbf'


The error ORA-01195: online backup of file 2 needs more recovery to be consistent indicates that a tablespace is still in hot-backup mode on the primary database while trying to activate the standby database.

This is in fact the same situation as with a normal hot backup itself – you need all archivelogs till end of the backup to have a useful backup.
When using a standby database, it effectively means that the standby database may not be consistent during the hotback period of the primary database.

Short term solutions:

1. Take the primary database out of backup mode and run Dbvisit Standby once more on primary and standby OR:
2. Try initiating a cancel-based recovery on the standby, and immediately canceling it – this usually works to open resetlogs the database (this updates the file headers with correct SCNs):
   SQL> recover standby database until cancel
cancel
exit

Long term solution:
Look at using RMAN in your backup. RMAN does not put the tablespace into hotbackup mode.

Other scenarios
The error "ORA-01194: file x needs more recovery to be consistent" which is closely related to ORA-01195 can occur during the following 2 scenarios:

1. Straight after standby database creation, where not all the archive logs have been applied that were created during the creation of the standby database. The solution is to apply all the archive log files.
2. If the standby controlfile was created after the backup of the primary database was made. In this case the solution is to re-create the standby database using a standby controlfile that was created before the backup of the primary database was made.

Dbvisit has been renamed to Dbvisit Standby

The elegant and feature-rich web-based GUI for Dbvisit Standby has now been released for all platforms.

New features for GUI:

1. Web-based interface using build in web-server named Dbvserver. Dbvisit Standby can be now be run through: – traditional command line interface (CLI) or – graphical user interface (GUI) through browser. Dbvserver needs to be started to enable the Dbvisit Standby interface through the browser.
   On Linux/Unix type dbvserverd to start Dbvserver.
   On Windows start the Dbvserver Windows service to start Dbvserver.

2. Dbvserver includes a full scheduler to be able to schedule Dbvisit Standby. An external scheduler such as cron are no longer required.
   Dbvisit is now installed into a new subdirectory called “standby” under the main “dbvisit” directory.

3. Full web-based access to the Dbvisit logs on the primary and standby server. Full access to the Oracle alert log throug the web browser.
4. Graphical reports showing key information about the standby database process such as lag, compression ratio, size of transfer, time taken for transfers, total redo per day, and total transfers per day.

For more information please see http://www.dbvisit.com/dbvisit_new_features.php

6.0.04 (9 June 2011)
New features:

1. Variable SEND_HEARTBEAT2_TIME24 made redundant. Multiple times to send a heartbeat message separated by colon can be specified by variable SEND_HEARTBEAT_TIME24
2. Provide user feedback that Dbvisit is running the silent archive log gap report.
3. Release for all platforms.

Fixes:

1. Dbvisit could not locate trace files while running AMM module in windows environment – fixed
2. When running -R, do not run silent inspect (RUN_INSPECT=Yes) as this meant Dbvisit is contacting the standby database twice.
3. Compatibility with IE9 resolved.

Dbvisit Standby can be downloaded from http://www.dbvisit.com/dbvisit_download.php

A DBA Dad finds himself having something of a crisis at ‘Bring your Dad to School Day’. Thanks to Dbman it all works out in the end!

Considerations for Standby Databases using Automatic Storage Management (ASM)

Every file created in ASM gets a system-generated filename, otherwise known as a fully qualified filename (FQFN). The fully qualified filename represents a complete path name in the ASM file system. An example of a fully qualified filename is:

+dgroup2/sample/controlfile/Current.256.541956473

You can use the fully qualified filename to reference (read or retrieve) an ASM file. ASM generates a fully qualified filename upon any request to create a file. A creation request cannot specify a fully qualified filename. Instead, it uses a simpler syntax to specify a file, such as an alias or just a disk group name. ASM then creates the file, placing it in the correct ASM “path” according to file type, and then assigns an appropriate fully qualified filename. If you specify an alias in the creation request, ASM also creates the alias so that it references the fully qualified filename.

FQFN are generally long and awkward, therefore, to make file-naming convention easier to remember the ASM Alias name format was introduced. ASM Aliases are essentially in hierarchical directory format, similar to the filesystem hierarchy. Alias names specify a disk group name, but instead of a file and incarnation number, a user-friendly string name is used.

Alias ASM filenames, otherwise known as aliases, can be used both for referencing existing ASM files and for creating new ASM files. Alias names start with the disk group name preceded by a plus sign, after which you specify a name string of your choosing. Alias filenames are implemented using a hierarchical directory structure, with the slash (/) or backslash (\) character separating name components. You can create an alias in any system-generated or user-created ASM directory. You cannot create an alias at the root level (+), however.

When you create an ASM file with an alias filename, the file is created with a fully qualified name, and the alias filename is additionally created. You can then access the file with either name.

Alias ASM filenames are distinguished from fully qualified or numeric names because they do not end in a dotted pair of numbers. An example of ASM alias for the fully qualified filename above is:

+ dgroup2/sample/controlfile/control01.dbf

Dbvisit currently creates an ASM standby database using aliases for standby database files. If the primary database uses ASM files that do not have aliases defined for them, just FQFN, Dbvisit will prompt you to provide aliases for the standby ASM datafiles. All ASM standby database files will be created with system-generated FQFN and have aliases defined for them. Aliases for standby datafiles, tempfiles, controlfiles and redo logs will be used in the database dictionary.

To use Dbvisit to create an ASM standby database or a standby database for an ASM primary database, make sure that the operating system user that runs Dbvisit has access to Oracle executables in the ORACLE HOME for the ASM instance. Dbvisit needs execute privilege on the ASMCMD utility, and if your installation implements Oracle 11g grid infrastructure under its own home and user, you may need to add the Dbvisit user to the operating group “oinstall” to make sure it can run the ASMCMD utility.

Find out where the swap space is held:
# swapon -s
Filename Type Size Used Priority
/dev/mapper/VolGroup00-LogVol01 partition 1015800 0 -1

Look at the logical volume:

lvdisplay
— Logical volume —
LV Name /dev/VolGroup00/LogVol00
VG Name VolGroup00
LV UUID FeQLua-ORb9-9B3f-lVem-c0nQ-FYjS-1etiif
LV Write Access read/write
LV Status available
# open 1
LV Size 18.91 GB
Current LE 605
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 253:0

— Logical volume —
LV Name /dev/VolGroup00/LogVol01
VG Name VolGroup00
LV UUID diY47d-Xu5Q-I82e-39sG-skDj-zklP-Z7G2Dl
LV Write Access read/write
LV Status available
# open 1
LV Size 992.00 MB
Current LE 31
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 253:1

Just resizing will not work if there is not enough diskspace in the volume:
lvm lvresize /dev/VolGroup00/LogVol01 -L 2G
Extending logical volume LogVol01 to 2.00 GB
Insufficient free space: 33 extents needed, but only 0 available

We need to add another disk to the Volume group:
ls -al /dev/sda*
brw-r—– 1 root disk 8, 0 Oct 4 01:24 /dev/sda
brw-r—– 1 root disk 8, 1 Oct 4 01:25 /dev/sda1
brw-r—– 1 root disk 8, 2 Oct 4 01:24 /dev/sda2
[root@dbvisit51 ~]# sfdisk -s
/dev/sda: 31457280
/dev/sdb: 20971520
total: 52428800 blocks

Add a new partition on the existing disk (The physical disk has space)

fdisk /dev/sda

Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 3
First cylinder (2611-3916, default 2611):
Using default value 2611
Last cylinder or +size or +sizeM or +sizeK (2611-3916, default 3916): 2872

Command (m for help): w
The partition table has been altered!

Resize the volume:
lvm lvresize /dev/VolGroup00/LogVol01 -L2.9G
Rounding up size to full physical extent 2.91 GB
Extending logical volume LogVol01 to 2.91 GB
Logical volume LogVol01 successfully resized

Remove the swap space so that we can increase it:
swapoff -v /dev/VolGroup00/LogVol01

Rebuild the swap space:
mkswap /dev/VolGroup00/LogVol01
Setting up swapspace version 1, size = 3120558 kB

Add swap space and check size again:

swapon -va
swapon on /dev/VolGroup00/LogVol01
[root@dbvisit51 ~]# swapon -s
Filename Type Size Used Priority
/dev/mapper/VolGroup00-LogVol01 partition 3047416 0 -3

All done, swap space now 3G.

Our Dbvisit web based version (Dbvisit Standby version 6.0) was scheduled to be released in April. Unfortunately this has been delayed while we try and resolve all remaining issues to ensure a stable version when we do release.

We are hoping to have Dbvisit Standby released at the end of May 2011.

Here is a preview of the reporting capability of Dbvisit Standby version 6.0.