Smart Database Technology

Replacing the standby controlfiles on the standby server
If for any reason the standby controlfiles have become corrupted or have been accidentally removed on the standby server, Dbvisit can re-create the standby controlfiles from the primary server without any outage on the primary database.

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/

Dbvisit version Dbvisit 5.2.30 has been released. This is a minor release which includes an improved Dbvisit man or help page and fixes a small number of issues.

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

As mentioned in a previous blog (ESXi), we have purchased additional hardware for our development environment. We have been using VMware Server for our existing hardware but wanted to go with a bare-metal hypervisor as this is more efficient for running VM’s (Virtual Machine) than running VMware Server.

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.