Headed by the energetic Managing Directors Steffen Fenger and Dirk Melzer, Aspicon have been a reseller of Dbvisit since 2008. Dirk comments, “We are very pleased to have such an agile and innovative partner as Avisit. With their product Dbvisit we are able to complete our full range of HA solutions, especially for those customers not running an Enterprise Edition environment, but having the same requirements in terms of system reliability. Our partnership with Avisit has been successful for us and also offers value to our clients.”

Steffen and Dirk have successfully grown their company to offer an extensive range of mainly Oracle-related services  including the conceptual design and implementation of complete Oracle system environments, remote DBA services as well as trouble shooting. They have built a strong reputation specializing in Oracle High Availability and Real Application Cluster (RAC) solutions, and are often called upon to resolve difficult Oracle issues. Passionate about Oracle database technology, they are also Oracle Beta Testers for Oracle Enterprise Linux and Oracle VM Virtualization.

Like us Aspicon is a company that strives to build strong relationships with their clients and partners. They are an Oracle Platinum partner and are the recipients of numerous awards for excelling in IT innovation, Oracle sales, support and implementation. They are an appreciated and valued member of the Dbvisit Reseller Network. If you wish to find out more about Aspicon, or a reseller in your area, you can do so here.

His insightful presentation reveals what a standby database is and could be used for, how it should be managed and best practices. Topics include logical vs physical standby databases, the differences between replication and disaster recovery and why businesses should care about which strategy they implement. Although suitable for all DBAs it is aimed at those looking  to increase their knowledge of standby databases for Oracle(R) Database Standard Edition and Standard Edition One implementations.

A regular speaker at Oracle events in New Zealand and overseas, Arjen weaves into his presentations over 20 years of database experience as a developer, data warehouse consultant, technical project manager and Oracle DBA. His previous presentation at OOW received a presentation feedback score of 4.89 out of 5, so he’s not one to miss.

Arjen’s presentation is on Thursday 23^rd September from 1.30pm to 2:30pm, in Room 307 at the Moscone South venue and we look forward to seeing you in the audience.

Are you going to OOW? For more information on Oracle OpenWorld 2010 and to register go to http://www.oracle.com/us/openworld/036763.htm?src=6896290&Act=46

With Dbvisit 5.3 we have added a feature called Transportable Media (TM) which allows for the creation of very large standby databases. Transportable Media is a removable storage device (such as a USB disk) which is first plugged into the primary server. Dbvisit will create a backup of the primary database onto the local Transportable Media device. The Transportable Media device is then manually taken to the standby or secondary site and plugged into the standby server. The Dbvisit Create Standby Database wizard will continue the operation of completing the creation the standby database on the standby server. This is a very efficient way of creating the standby database without utilizing the network. Once the standby database is created, Dbvisit can be activated to keep the standby database up to date.

We have also added Templates to the Dbvisit Create Standby Database wizard to make the disaster recovery process simpler, faster and more convenient for DBAs. Templates store all the settings to create the standby database which means that a new standby database can be easily recreated at any stage, even after a disaster.

For the complete list of new features:

• ASM support. The standby database can now be created in ASM as well, Oracle’s proprietary file system format. This completes the types of standby databases that can be created with Dbvisit.
• Templates. To make the disaster recovery process simpler, faster and more convenient for DBAs the Dbvisit standby database creation wizard now includes the option to create a template. This template stores all the information on how the standby database was created. When the standby database needs to be recreated, for example after a failover situation, this template can be used for fast and simple recreation.
• Transportable Media support. Some databases are too large to transfer across the network. Now the Dbvisit standby database creation process includes an option to interface with a local removable disk. This disk can then be manually transported to the remote site where the creation of the standby database can be restarted and completed.
• Ability to customize the standby pfile/spfile settings before creation of the standby database. These settings will be saved in the template for easy recreation of the standby database.
• Dbvisit installation, upgrades and creation of standby databases can now be scripted to run in batchmode for simple and efficient deployment.
• Rsync transfer method. DBAs now have the ability to use Rsync as the data transportation mechanism on Linux and Unix, facilitating efficient restarts when there are network issues or large file transfers.
• Oracle database parameters for the standby database can now be customized and saved in the template.

Dbvisit 5.3 is free to all customers who have current Dbvisit support and maintenance. A new license key will be required for Dbvisit 5.3. Existing Dbvisit 5.1 and 5.2 license keys are not valid. Please contact Dbvisit to obtain a new license key.

Dbvisit 5.3 can be download from Dbvisit download

Avisit Solutions Ltd, creators of disaster recovery solutions for Oracle® Database Standard Edition & Standard Edition One sites worldwide, is one of the latest recipients of TechNZ funding. TechNZ is the Foundation for Research, Science and Technology’s business assistance programme.

Building on the success of their flagship product Dbvisit, Avisit Solutions is to develop database replication software that protects and distributes data enterprise-wide; extending the usefulness of standby infrastructure for business intelligence needs, integration and information sharing.

“We’re delighted to have received this R&D funding to expand our disaster recovery product portfolio,” says Arjen Visser, CTO and company founder, Avisit Solutions.

“There is strong demand for affordable, cross platform database replication solutions as organisations look for ways to protect their data and improve business profitability. This funding will allow us to extend our product offering over the coming year to meet this demand. We’re pleased that TechNZ have decided to invest in our growth.”

“Investment in businesses that raise New Zealand’s global reputation for innovation and creativity is at the core of what we do,” says Mark Gallagher, TechNZ spokesperson. “We look forward to seeing Avisit Solutions step up to the next level through research and development.”

Founded in 2000, Avisit Solutions grew out of Arjen Visser’s previous experience as a database specialist in New Zealand and Europe. Routinely called in to fix “home-grown” disaster recovery solutions that lacked robustness, or were very hard to configure and maintain, inspired him to develop and launch Dbvisit in 2006. Today Dbvisit is trusted by customers in over 50 countries worldwide.

About Avisit Solutions Limited
Avisit Solutions enables organizations with Oracle® Database Standard Edition and Standard Edition One software to inexpensively protect their critical data infrastructure. By eliminating the need to upgrade to Oracle® Enterprise Edition to access Data Guard our customers can save up to 85% on their disaster recovery solution.

Designed by Database Administrators (DBAs) for DBAs, 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 to DBAs and free up their valuable time to focus on other activities.

Avisit Solutions founded in 2000 and is based in Auckland New Zealand with customers in 50 countries around the world.

For further information please contact:
Libby Russell
Arjen Visser
Tel: +64 9 950 3301
www.dbvisit.com

Unfortunately DIY projects don’t always stick to plan (or budget) and can be somewhat experimental, often costing more to manage and support than originally anticipated. When it comes to disaster recovery, if your data is critical to the business continuing to function it is essential to to have the best solution you can afford in place. If you’re weighing up DIY versus ‘off the shelf’, here are some important considerations to look at:

• Has the DBA covered all the bases? (bearing in mind it is very difficult to test and simulate all the issues that can go wrong).
• Is it going to be reliable, stable and easy to support in the long run?
• What happens when the DBA that developed the script leaves your organisation, is there someone else who knows how it works?
• Will a new DBA understand how the script works and be confident enough to use it (and fix it) when things go wrong?
• What will happen when you upgrade or patch Oracle? Will you be confident that it still works?
• What will happen if you migrate to another platform?
• What happens if there is a temporary glitch. Will it automatically recover and continue without intervention from the DBA?
• Does it support the Oracle features such as RAC, OMF, ASM?
• Does it create the standby database automatically?

Using a proven, reliable and stable solution like Dbvisit can really pay off in the long term. Dbvisit works on most platforms that are supported by Oracle including Windows, Linux and Unix and is backed by world class support. The team behind Dbvisit specialises in Oracle Disaster Recovery and as such are fully committed to ensuring you have full confidence in your Disaster Recovery solution.

Whichever path you decide to take, the most important things to think about are: Have I really done the right thing by my data? Does my solution tick all the boxes and protect my data the way it needs to be  protected? Have I thought about the long term effect of my decision on my departmental budget?

www.dbvisit.com

To re-create the standby controlfiles use the dbv_functions -Q option:

dbv_functions -Q w112g
Dbvisit Database configuration (DDC) file dbv_w112g.env.
=>Replace current standby controfiles on dbvisit52 with new standby
controlfile?  [No]: yes
Starting...
Completed.
Transferring X.dbvisit.10010921.w112g.standbycontrolfile.ctl to host
dbvisit52:X.dbvisit.10010921.w112g.standbycontrolfile.ctl
Initiating replacing standby controlfiles on standby server...
Dbvisit Database configuration (DDC) file dbv_w112g.env.
Completed.
Database w112g on dbvisit52 is already down.
No action is taken.
Completed.
Standby controfiles on dbvisit52 replaced.

This command has created a new standby controlfile from the primary database, copied this to the standby server and replaced the existing standby controlfiles with the new copy. It will shutdown and restart the standby database during this process.

Running Dbvisit on the standby server will be back to normal with Dbvisit applying the archive logs files as per usual:

dbvisit w112g
=============================================================
Dbvisit Standby Database Technology (pid 26054)
dbvisit started on dbvisit52
=============================================================

Log file(s) for w112g from dbvisit51 will be applied to dbvisit52...
201006122346 - Log seq 21 thread 1 applied to standby database w112g.

Starting Dbvisit Archive Management Module (AMM)...
Dbvisit Archive Management Module (AMM)
(Number to keep: 0) (Days to keep: 7) (Diskspace full threshold: 80%)
Archive log dir: /oracle/app/oracle/oraarch/w112g
Total number of archive files   : 9
Number of files deleted         : 0
Current Disk percent full       : 64%

=============================================================
dbvisit ended on dbvisit52
=============================================================

The location of the controlfiles for the standby database must be same as the location of the controlfiles for the primary database for the dbv_functions -Q command to work.

For other Dbvisit tips and tricks please see: http://blog.dbvisit.com/category/dbvisit-tips/

New features:

1. Allow the use of other external non sendmail clients on Linux/Unix. Use MAILCFG_SENDMAIL_CLIENT to set the full path of the client.
2. Update Dbvisit man pages.

Fixes:

1. Correct default Oracle password file for Windows.
2. In some cases, Oracle SID information was not obtained from registry in Windows 64bit.
3. Improve error message when Oracle Windows service cannot be stopped or started.
4. Improve locking mechnism on Windows. In some cases the pid lock file does not get removed after successfully running Dbvisit.
5. Activation of standby database may not update the Dbvisit repository correctly. Initiating a Graceful Switchover after failover may result in error: ORA-00001: unique constraint (DBVISIT.DBV_TRANSFER_LOG_PK) violated. This has been fixed.
6. Change creation of tempfile from bytes to Mb. If the file is too big then error “ORA-02237: invalid file size” may result. This has been fixed.
7. If SOURCE or DESTINATION host names are set to long names, then Dbvisit does not use the correct starting sequence after graceful switchover. This has been fixed.

Please download from http://www.dbvisit.com/dbvisit_download.php

The 2 options we have been looking at are:

• VMware ESXi 4.0
• Citrix XenServer 5.6

One of the important criteria for choosing, was an easy conversion path from our current VM’s (using VMware Server) to the new solution.

VMware ESXi 4.0.
The natural choice was to go with VMware ESXi 4.0 as an upgrade to VMware Server. The installation and configuration was easy and we successfully converted our existing VM’s to ESXi using the Converter Standalone Client . We installed ESXi on a USB stick which can then be used to boot the server to run ESXi. This gives the ability to clone the USB stick for DR and backup purposes.

The management console using vSphere Client is also easy to use, although some features are hidden away and take some time to find (ie. uploading and downloading files to the datastore). With vSphere Client you get a nice overview of the VM’s and the resources used by each VM.

We were all set to go with deploying VMware ESXi on our hardware and the last step was checking the security and tightening the security of ESXi. We deploy some of our servers on public facing networks and as such we need to be very careful about security and we have some strict policies around security.

This is where ESXi was not secure enough for us. It is not possible to change any of the default ESXi ports used by the management console and it is also not possible to run a firewall service on ESXi. The operating system that runs on the host, is a cut down Linux version with limited possibilities for any configuration changes and additions. This also makes it difficult to use standard methods for VM backups such as rsync and scp.

VMware states that the ESXi management console interface should not be on a public network, and/or should have a firewall in front of it. Having a firewall in front is still not secure enough for us, we want the ability to change the default ports that the management console communicates on, otherwise those ports will still get hammered even if they are behind a firewall.  With our configuration it would be possible to have the management console on a private internal network and have one of the VM’s connect to this private network. This is a bit of a chicken and egg situation where the VM has to be running in order to manage the VM’s. Not an ideal situation for us.

Citrix XenServer 5.6
The other option was to try Citrix XenServer. We had a few issues installing XenServer on a USB stick. Turns out a 16GB USB stick needs to be used, smaller sizes are possible but require tweaking on the install scripts.

XenServer is a nice solution and the XenServer management Console called XenCenter is great. With XenServer you get a full blown Linux operating system allowing you to to secure the host and do regular VM backups.

XenServer works quite differently to ESXi, and although not being experts in this area, we understand it as follows: XenServer is more “bare bones” than ESXi. The VM’s on XenServer talk more directly to the hardware whereas with ESXi there is more of an abstraction layer. The advantage for XenServer is that it runs the VM’s faster and more efficient than ESXi. The downside is that each OS has to be certified to run as a VM in XenServer as it has to talk directly to the hardware and specific drivers have to be build. This means each new release of Linux has to be certified against XenServer before being able to create a VM for that specific OS. With ESXi (and other VMware solutions), the VM uses generic VMware drivers so the OS is not so crucial. For example, we are running Solaris x86 and older versions of Linux in VMware Server.

To convert our existing VMware Server VM’s to XenServer, we use Citrix XenConvert. We first imported the VM’s to ESXi and then exported the VM’s out of ESXi using the Open Virtualization Format (OVF) and then converted it to XenServer. That was where we started to have issues with XenServer.

If the VM had only one virtual disk, then the conversion was fine, but as soon as the VM had more than one virtual disk the conversion was not successful. With a lot of tweaking we may have been able to improve the conversion but our VM’s are quite complicated systems and we did not want to find out three months down the track that one of the components in our VM was not working due to a conversion error.
The MS Windows server VM that we had converted to XenServer also required new activation because Windows detected a significant change in the underlying hardware.

Also the limited ability to only run specific OS as VM’s was also a limiting factor for XenServer. Our software Dbvisit runs on many different platforms and we need to be able to test on all of them.

Conclusion
What did we decide in the end to use? Who is the winner between VMware ESXi versus XenServer?

We have gone back to using VMware Server. While there is a performance penalty, you can install the OS of your choice and harden it as much as you like.
ESXi 4.0 is not secure enough for our configuration and it was too difficult to convert our existing VM’s to XenServer.

Had we started out from scratch and did not have any existing VM’s, then the clear winner would be XenServer for us.

To achieve this Dbvisit had to demonstrate “competency development, business results, expertise and proven success to be recognized by Oracle, and preferred by customers.*” For Dbvisit these values underpin everything we do and are vital to delivering a product that Oracle users want and prefer.

Thanks Oracle, the recognition is well received.

(* source: http://blogs.oracle.com/certification/2009/12/0127.html)

To generate test data use the dbv_functions -T option:

dbv_functions -T w120n
>>> Creating test table and inserting test data into w120n.
Test table dbvisit.dbv_test_data created.
Test table dbvisit.dbv_test_data dropped.

The data is inserted into a new table created in the Dbvisit database schema and then the table is dropped after completion of the insert to ensure that the database is left in the same state as when the command was started.

To add more data, a cycle number can be given:

dbv_functions -T w120n 2
>>> Creating test table and inserting test data into w120n.
Test table dbvisit.dbv_test_data created.
Insert cycle 1 completed. Rows inserted: 49974
Insert cycle 2 completed. Rows inserted: 99948
Test table dbvisit.dbv_test_data dropped.

This has added 99,948 rows and then dropped the table.

The higher the cycle number, the more data is added:

dbv_functions -T w120n 5
>>> Creating test table and inserting test data into w120n.
Test table dbvisit.dbv_test_data created.
Insert cycle 1 completed. Rows inserted: 49974
Insert cycle 2 completed. Rows inserted: 99948
Insert cycle 3 completed. Rows inserted: 199896
Insert cycle 4 completed. Rows inserted: 399792
Insert cycle 5 completed. Rows inserted: 799584
Test table dbvisit.dbv_test_data dropped.

This has added 799,584 records to the database, and then dropped the table.

After running the command, Dbvisit can be run as normal to transfer the archive log files to the standby server.
To see the size of the archive logs and statistics of the transfer see http://blog.dbvisit.com/dbvisit-tip-of-the-week-1/