In this version there is a lot more integration with RMAN when creating the standby database and with graceful switchover. By using more RMAN features when creating the standby database, it allows Dbvisit Standby to be a lot more flexible and smarter in creating the standby database. Even though we recommend keeping the standby database the same structure and format as the primary database, it is possible with Dbvisit Standby to create a completely different standby database structure when compared to the primary database. With the previous version of Dbvisit Standby each datafile had to be renamed individually, with Dbvisit Standby 6.0.16 only the different locations have to be specified so the setup has been made a lot easier.

The complete changes in Dbvisit Standby 6.0.16 are:
Changes:

1. New Create Standby Database (CSD) functionality which improves the overall ability to create different standby databases configurations.
   CSD now makes use of the following parameters:
   - db_file_name_convert
   - log_file_name_convert
2. Improved graceful switchover functionality. Existing controlfile is re-used for primary database and is no longer rebuild. Graceful switchover allows for more differences between primary and standby database.
3. Provide silent install for dbvisit_install. This installs product with all default values accepted. Type “dbvisit_install -?” for details.
4. Non existent directories on the standby server are automatically created as much as possible by Dbvisit Standby during creation of the standby database.

Fixes:

1. Issue with adding own ORACLE_SID and ORACLE_HOME in web interface – fixed.
2. Dbvisit temp p2x-* directories not cleaned up for HP-UX and AIX – fixed.
3. Improve locking mechanism in rare cases when archive log file just arrives at the standby server and is 0 size and is picked up by Dbvisit Standby on the standby server.
4. Improved tracing of Dbvserver.
5. Obtain ORACLE_HOME and ORACLE_SID from registry for Windows 2008R2.

Tim Hall has done a review of Dbvisit Standby 6.0.16 which can be found here: Oracle-base Blog

Dbvisit Standby can be downloaded from here

1. LOB support. Dbvisit Replicate now supports LOB datatypes.
2. Improved startup speed of dbvrep executable. The startup speed of the Dbvisit Replicate executable has been improved.
3. RAC support for node shutdown/startup. A RAC instance can be shutdown, and Dbvisit Replicate will continue to replicate when connected to the active instance.
4. One-to-many support. One source database can now have multiple target databases. This can be easily setup in the new setup wizard.

Dbvisit Replicate can be downloaded for a 30 day trial from here

Dbvisit Replicate offers Oracle-to-Oracle real time replication. It also supports Oracle-to-MySQL and Oracle-to-SQLServer. Dbvisit Replicate is simple to use and is a smart alternative to Golden Gate and Oracle Streams.

Dbvisit Replicate 2.1 has many great new features which include:

1. New easier to use setup wizard
2. Data type support extended to RAW, BFILE, TIMESTAMPs, INTERVALs
3. Support for AIX
4. Support for Solaris SPARC
5. Support for partitioning
6. Added Resolve conflict as ROLLBACK option
7. Support for non-ordered redo logs/multiple redo streams (11.2 default feature)
8. Improved network outage handling
9. ASM instance name auto detection for RAC to enable RAC node failover
10. Improved User documentation

We are particularly proud of our new setup wizard, which makes the installation process even easier and robust. We hope you like it and look forward to your feedback.

Please look forward to another release with even more features in early January. However now is a great time to download and try the latest version Dbvisit Replicate!

To download please go to: http://www.dbvisit.com/products/downloads/

Generally there are two options for the DBA to achieve this:

1. Change of the database host using either the
   1. connect string or
   2. DNS.
2. Use of the NET8 listener fail-over.

1 – Change of database host
To begin lets look at option 1. Our examples use the following host and service names:

host name primary server: dbprod
host name standby server: dbstandby
service name:             orcl
net service name:         orcl_ha

In the case of example 1-a, we are going to change the host name within the TNS connect string after switch-over/fail-over or change the IP from primary server’s to standby server’s.
The tnsnames.ora entry:

orcl_ha=
	(description=
		(address = (host = dbprod)(protocol = tcp)(port = 1521))
		(connect_data = (service_name = orcl))
	)

will be changed after the switch-over/fail-over into:

orcl_ha=
	(description=
		(address = (host = dbstandby)(protocol = tcp)(port = 1521))
		(connect_data = (service_name = orcl))
	)

Or alternatively by using a JDBC-connect:

jdbc:oracle:thin:@dbprod:1521/orcl

will be changed after the switch-over/fail-over into

jdbc:oracle:thin:@dbstandby:1521/orcl

This solution seems to be the easiest way if the changes to be made are limited, or on a single point. This type of configuration is mostly found with clients that have a:

1. centralised tnsnames.ora, or
2. net service resolution via Oracle Internet Directory, Active Directory or
3. any connect string at the Application Server.

This method is only efficient in a centralised names configuration.
The DBA could switch to option 1-b if there is a DNS alias used for the name services. In addition to the host names defined above we define an extra DNS CNAME as dbha, which initially points at the host dbprod.
The tnsnames.ora as well as the JDBC connect string stay as they are after switch-over/fail-over:

orcl_ha=
	(description=
		(address = (host = dbha)(protocol = tcp)(port = 1521))
		(connect_data = (service_name = orcl))
	)

or:

jdbc:oracle:thin:@dbha:1521/orcl

After failover the DNS CNAME dbha is redirected to the host name dbstandby.
The advantage of this method is that it works well for centralised as well as for the de-centralised names configuration services. The disadvantage with this method is that the connect fail-over can have serious time delays, because the new DNS configuration first has to be replicated to the DNS servers. The name service caches of clients also may need to be flushed. So even though the database might be online and available, some of the clients may still not be able to connect because of the DNS update being delayed.

2 – Listener fail-over
The most recommended and most flexible solution is using a dynamic connect listener fail-over. To achieve this the DBA defines dbprod as well as dbstandby into a common connect string and to establish a fail-over between them both.
The related tnsnames.ora entry would be as follows:

orcl_ha=
	(description=
		(address = (host = dbprod)(protocol = tcp)(port = 1521))
		(address = (host = dbstandby)(protocol = tcp)(port = 1521))
		(failover = yes)
		(connect_data = (service_name = orcl))
	)

Also for JDBC the DBA would have to use the complete connect string:

jdbc:oracle:thin:@(description=(address=(host=dbprod)(protocol=tcp)(port=1521))(address=(host=dbstandby)(protocol=tcp)(port=1521))(failover=yes)(connect_data=(service_name=orcl)))

In this configuration it’s essentially to ensure that only the listener at the present primary server is running. Otherwise it’s possible that you run into the problem that the client connections are directed to the standby database, which produces the following error message output:

ORA-01033: ORACLE initialisation or shut down in progress

If the listener is controlled by either Oracle Clusterware, Oracle Grid Infrastructure or Oracle Restart it would be possible to fully automate the start and shut downs of the listeners. This is done by integrating a control resource at the primary and standby server.
For example, create an action script, which is saved as /usr/bin/dbv_lsnr_ctrl.sh and that can be run by the Oracle user:

#!/bin/sh
# Listener status control script for use with Dbvisit standby
# - prevents listener from starting if the corresponding instance has standby role
#
unset DEFAULT_DBV_HOME PRIMARY_ROLE_EXPR INSTANCE_NAME
STANDBY_ROLE_EXPR="^Standby Database"
DEFAULT_DBV_HOME=/u01/app/dbvisit
INSTANCE_NAME=${_USR_ORA_SRV}
# set default Dbvisit Standby home path, if not already set in environment
if [ -z "$DBV_HOME" ]; then
        DBV_HOME=${DEFAULT_DBV_HOME}
fi
case $1 in
    # handle start request and check equally
    # (start/report ok, except when on standby side and instance is running)
    start|check)
        ! ${DBV_HOME}/dbv_oraStartStop status ${INSTANCE_NAME}|grep "${STANDBY_ROLE_EXPR}" >/dev/null 2>&1
        exit $?
        ;;
    # stop request always can be fulfilled
    stop)
        exit 0
        ;;
esac
# paranoia exit
exit 1

Within the script (or alternatively at the environment variable DEFAULT_DBV_HOME) the DBA should define the Dbvisit Standby installation path. In addition the following control resource should also be created on the primary:

crs_profile \
	-create dbv_lsnr_ctrl \
	-t application \
	-a /usr/bin/dbv_lsnr_ctrl.sh \
	-h dbprod  \
	-p restricted \
	-o as=restore,ci=60,ft=0

On the standby we use dbstandby:

crs_profile \
	-create dbv_lsnr_ctrl \
	-t application \
	-a /usr/bin/dbv_lsnr_ctrl.sh \
	-h dbstandby  \
	-p restricted \
	-o as=restore,ci=60,ft=0

In directory $CRS_HOME/crs/public the following .cap file will be created: dbv_lsnr_ctrl.cap.
The database name needs to be entered at line USR_ORA_SRV= exactly the same way that Dbvisit Standby commands are executed:

USR_ORA_SRV=orcl (e.g. at "dbvisit orcl")

The action script (/usr/bin/dbv_lsnr_ctrl.sh) is called with a parameter which is used to call the Dbvisit Standby command to obtain the database status:

dbv_oraStartStop status

To add the control resource to Oracle Clusterware:

crs_register dbv_lsnr_ctrl

Finally the dependency of listener and control resource needs to be defined:

crs_profile -update ora.LISTENER.lsnr -r dbv_lsnr_ctrl

After restarting the listener the dependency on the control resource is created. This determines the status of the database as reported by dbv_oraStartStop, whether it is started or not. If dbv_oraStartStop detects a database in standby role, the control resource goes down and prevents the listener from starting. Otherwise it starts and the listener is allowed to run.

Thanks to author: Thilo Solbrig (Oracle Certified Master) at Aspicon – Dbvisit Partner

One of the options of DBUA is to temporary switch to NOARCHIVELOG mode during the upgrade to speed up the upgrade. However if the database has an associated standby database, then switching on NOARCHIVELOG will invalidate the standby database with Oracle SE and SE1. In Oracle EE, the redo logs can be used by Data Guard to keep the standby database up to date and this may not be an issue.

The reason that it invalidates the standby database is that there will be a gap in the archivelogs during NOARCHIVELOG and the standby database requires all archives logs in sequence to keep the standby database up to date.

Example:
During an upgrade with DBUA the database was switched to NOARCHIVELOG mode as can be seen from the following query:

SQL> select sequence#,name from v$archived_log where sequence#>4380;
SEQUENCE#	NAME
4381	E:\ORACLE\FLASH_RECOVERY_AREA\PCSJP\ARCHIVELOG\2011_10_23\O1_MF_1_4381_7B5PN1LT_.ARC
4382	E:\ORACLE\FLASH_RECOVERY_AREA\PCSJP\ARCHIVELOG\2011_10_23\O1_MF_1_4382_7B5T4KQK_.ARC
4383	E:\ORACLE\FLASH_RECOVERY_AREA\PCSJP\ARCHIVELOG\2011_10_23\O1_MF_1_4383_7B5XO1LJ_.ARC
4384	E:\ORACLE\FLASH_RECOVERY_AREA\PCSJP\ARCHIVELOG\2011_10_23\O1_MF_1_4384_7B615KV4_.ARC
4385	E:\ORACLE\FLASH_RECOVERY_AREA\PCSJP\ARCHIVELOG\2011_10_23\O1_MF_1_4385_7B64P1KQ_.ARC
4386	E:\ORACLE\FLASH_RECOVERY_AREA\PCSJP\ARCHIVELOG\2011_10_23\O1_MF_1_4386_7B686KYQ_.ARC
4387	E:\ORACLE\FLASH_RECOVERY_AREA\PCSJP\ARCHIVELOG\2011_10_23\O1_MF_1_4387_7B6CQ1D2_.ARC
4388	E:\ORACLE\FLASH_RECOVERY_AREA\PCSJP\ARCHIVELOG\2011_10_23\O1_MF_1_4388_7B6H7O6B_.ARC
4389	E:\ORACLE\FLASH_RECOVERY_AREA\PCSJP\ARCHIVELOG\2011_10_23\O1_MF_1_4389_7B6KST7V_.ARC
4402	E:\ORACLE\FLASH_RECOVERY_AREA\PCSJP\ARCHIVELOG\ARC0000004402_0749585225.0001
4403	E:\ORACLE\FLASH_RECOVERY_AREA\PCSJP\ARCHIVELOG\ARC0000004403_0749585225.0001
4404	E:\ORACLE\FLASH_RECOVERY_AREA\PCSJP\ARCHIVELOG\ARC0000004404_0749585225.0001
4405	E:\ORACLE\FLASH_RECOVERY_AREA\PCSJP\ARCHIVELOG\ARC0000004405_0749585225.0001
4406	E:\ORACLE\FLASH_RECOVERY_AREA\PCSJP\ARCHIVELOG\ARC0000004406_0749585225.0001
4407	E:\ORACLE\FLASH_RECOVERY_AREA\PCSJP\ARCHIVELOG\ARC0000004407_0749585225.0001
4408	E:\ORACLE\FLASH_RECOVERY_AREA\PCSJP\ARCHIVELOG\ARC0000004408_0749585225.0001
4409	E:\ORACLE\FLASH_RECOVERY_AREA\PCSJP\ARCHIVELOG\ARC0000004409_0749585225.0001

The logs for sequence 4390-4401 have been not been generated. This means that the standby database cannot be kept up to date. Since the archive logs are not created by Oracle, and you cannot skip archive logs with a standby database, it means the standby database has to be rebuild.

Re-creating the standby database can be easily done with Dbvisit Standby.

Recommendation
Do not switch on NOARCHIVELOG mode during a database upgrade, as this may invalidate your standby database.

When upgrading an Oracle database that has an associated standby database, we recommend the following approach is followed: Upgrading or patching Oracle with a standby database.

1 Dbvisit stand — 6 Staff — Our mission: spread the word

Oracle Standard Edition database users can access smart disaster recovery and database replication solutions and save up to 80% on Oracle licensing.

Six members of the Dbvisit team made the pilgrimage from New Zealand, the Czech Republic, Texas and California to what is considered Oracle’s biggest event in the calendar: the annual Open World conference in the heart of downtown San Francisco.

It was a huge week for us in terms of connecting with our customers, partners and prospects and a great opportunity to network with Oracle thought leaders and the wider Oracle community. It was also a chance for us to see how well our messages resonated with our target market of Standard Edition database users.

So what did we get up to? Well, amongst other things we…

• met with, and bumped into, dozens of our customers
• came away with 150+ potential business opportunities, from resellers to banks to aircraft manufacturers
• talked to our partners, such as Jean-Pierre Bocchi from SETRA Conseil – who claimed the spoils at our Meet & Greet event
• had a bunch of meetings with top Oracle executives
• whet our technical appetites by asking questions and attending technical sessions
• were inspired by, and enjoyed meeting, some of the Oracle community thought leaders – like the team from Pythian
• figured out that, apparently, there are more than a few people interested in holding onto their Standard Edition investments!
  

Thank you to our customers for taking the time to visit our booth and catch up or introduce yourselves and, in many cases, put faces to names. To those of you who stopped at our booth to ask questions, receive demos or just to introduce yourselves, it was a pleasure to meet you. We look forward to working with you on your projects.

Thanks also to a number of those in the wider Oracle community who made the event so enjoyable for us, including the team at Pythian, Oracle ANZ and a number of Oracle ACE’s – you know who you are. For myself, and the other three Dbvisit team members who were Open World first timers, we appreciated the hospitality and the conversation.

I’ll leave you with some photos and we’ll see you there next year!

All the best,

Mike Donovan
Service & Online Delivery Manager

Oracle Open World in San Francisco

And we were in the middle of it all. 6 guys, 1 booth, loads of enthusiasm and a simple message: save up to 80% on Oracle licensing.

There were lights, sounds and speeches.

And golf, free poker, ipad raffles, spinning wheels and big wrestler dudes.

And stretching our legs out beyond the exhibition halls we got to see Sting in concert.

Along with the San Francisco seals, downtown.

And the Golden Gate bridge, of course, with a complimentary air show to boot - which was phenomenal.

While some of the team even managed to catch up with Leonardo DiCaprio! It really is a small world.

Congratulations to Jean-Pierre Bocchi (SETRA-Conseil - France). Winner on the day at the Dbvisit Meet & Greet event

If you register now you will be in to win a prize pack (pictured below) featuring the nifty Selk’bag, perfect for those surprise colder days at OOW! Plus included in the pack is a signed copy of ‘Only Two Seats Left’, the incredible story of how a simple Kiwi idea became an international ‘iconic’ brand name.

Date: Tuesday 4th October
Time: 4:30pm – 6:30pm
Location: Hotel Nikko (view map)
222 Mason St, San Francisco

You are also welcome to visit us at booth 130 in the Moscone South Exhbition Hall, right next to the Database Demo Grounds (view map).

Replication software: who is using it and how can it be effective?

I see companies using Dbvisit Replicate for a number of reasons:

• Distributing data across offices/locations. They may have one source database that they want to distribute to remote offices, or have a need to share data with remote offices.
• Data warehousing, where ETL (extraction, transform and upload) is in play to extract data out of the source database and into the data warehouse. Using Change Data Capture (CDC) by mining the Oracle Logs is the most efficient way to detect and extract inserts and updates out of source data.
• Upgrading Oracle versions or migrating from one Oracle platform to another, e.g. Oracle on Windows to Oracle on Linux.

What are your keys to successful product development?
Successful software and ultimately product development is all about developing with the user experience in mind. My main considerations in developing Dbvisit Replicate were:

• Ensuring it was easy to use, configure and set up
• Making sure it provides solid and useful feedback when things are not going right, and that the software can guide the user in fixing whatever is wrong
• That it provided good guidance but still allowed for flexibility should the user wish to ‘wander off the path’.
• Ensuring that the product accommodated all of the different configuration options allowed by Oracle so our users did not lose any of the power and flexibility inherent to Oracle databases.

What prompted you to develop a Replication product?

Listening to our customers! We kept getting lots of enquiries from customers who wanted real time reporting and Oracle replication across different platforms.

What were some of the major challenges you faced in developing Dbvisit Replicate?

One of the biggest technical challenges around developing Dbvisit Replicate was building our own mining engine to extract the transactions out of the Oracle logs, putting the information together in the right order and turn them into SQL. Also ensuring that all the SQL are happening in the right order to guarantee transaction integrity. We figured it out!

What are some of the issues users have found since you launched Dbvisit Replicate?

All though we try to account for every Oracle configuration we can, by it’s nature replication is complex and there are configurations out there that we may not yet have accounted for. No doubt we will have to make changes to the software to accommodate them as they arise.

As with Dbvisit Standby we are very responsive when it comes to assisting customers and have been able to diagnose and resolve any issues very quickly.

What is your favourite feature in Dbvisit Replicate?

Real time replication progress updates which allow you to watch the replication as it happens in the Dbvisit Replicate console.

Is there still a place for DR software once someone has implemented Replicate?

Yes. They have very distinct functions and benefits: Dbvisit Replicate serves to replicate and distribute your data and Dbvisit Standby is about protecting your data. The great news for Standard Edition users is that Dbvisit products work together to provide the sharing AND complete protection of your data.

Is there anything else you’d like to add about Dbvisit Replicate?

I’m very excited about Dbvisit Replicate. Data replication is a very complicated animal (especially master to master) and it was a huge feat to pull off so I’m immensely pleased and proud of the team that we’ve been able to do it. I am also very excited that we can enable our users to replicate from Oracle to Oracle, Microsoft SQL Server and MySQL databases. It puts us in the unique postion of having two products that encompass the entire Oracle replication spectrum, from physical to logical replication. The possibilities this opens up for our primarily Standard Edition users is immense.

For more information on Dbvisit Replicate go to www.dbvisit.com.

1. Remove dependance on asmcmd to allow for separate Grid install.
2. Graceful Switchover on Windows with ASM now supported.
3. New END-USER LICENSE AGREEMENT.
4. New Dbvisit Logo.

Fixes:

1. In case FRA enabled Dbvisit only searched for an archive to transfer under date subdirectories but not directly under ARCHSOURCEn directories – fixed
2. Attached incorrect PDF User manual – fixed.
3. Remove PFILE setting. This is now obsolete.
4. Display a warning message for Graceful Switchover on Windows to configure Windows service with STARTMODE=MANUAL.
5. Fix minor bugs in functions to stop and start primary and standby databases.
6. Fixed issue with Graceful Switchover and RAC introduced with version 6.0.08 to deal with issue when threads are closed.
7. In some cases Graceful Switchover with RAC may want to transfer compressed archives and this fails – fixed.
8. Scheduler displayed wrong timestamp in email – fixed.
9. Dbvisit does not cope with commas in oracle parameter values when creating a standby database – fixed.

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