Oracle Open World 2009

oracle-openworld-banner-ad-200x200Oracle Open World 2009 is scheduled for October 11-15 in San Francisco.

I will be presenting 2 papers at Oracle Open World.

This is my first time at OOW and I am very much looking forward to it.
It will be a great chance to meet new people and to catch up with friends and customers.

I will be presenting the following 2 papers:

1) How to Create a Technical Disaster Recovery Implementation Plan.

A technical disaster recovery implementation plan involves the actual implementation of the hardware and software at the disaster recovery location. It ensures that there are no surprises when building the disaster recovery servers and that all critical systems and their components have been accounted for. This session focuses on Oracle-centric applications in the UNIX/Linux environment.
When: Monday Oct 12 16:00 – 17:00, Moscone South, Room 270

2) Perl:DBA’s and Developers best (forgotten) friend.

This session reintroduces Perl as a language of choice for DBAs and developers for developing a range of programs and scripts. Discover what makes Perl so successful and why it is so versatile. Perl can automate all those manual tasks, and it is truly platform-independent. It may not be in the limelight like other languages, but it is a remarkable language for development and is still very current with ongoing development. Oracle and VMware still use it as part of their latest software releases.
When: Tuesday Oct 13 16:00 – 17:00, Moscone South, Room 270

If you are attending OOW and are interested in these topics, please come along.

If you are one of our Dbvisit customers or just want catch up with me during OOW – please tweet me @dbvisit or send me an email. I am looking forward to meeting with you.

Dbvisit 5.2.16 released

Dbvisit 5.2.16 has been released for all platforms.

This is an exciting release as we now have the ability for graceful switchover for RAC and ASM databases. Many companies have been requesting this feature and we are pleased that it is now available.

The roles between a primary RAC node and the standby database can be switched and be switched back with no dataloss. The RAC database will become a single instance database and the other RAC nodes will be shutdown during switchover. However after the switchover the database can be converted back to the original RAC database again very simply.

The standby database creation has also been improved with now a lot more checking on the standby database to see if the correct directories exist.

When Dbvisit detects an error, the Dbvisit trace files is now automatically attached to the email, making the process to send the trace file to support very easy.

The full details of the features are:
New features:

  1. Graceful Switchover for ASM and RAC. RAC database will become a single
    instance database during switchover. After switchover database can be
    converted to a RAC database again.
    Note: The Oracle ASM instance needs to be version 11gR1 or higher. The Oracle
    database itself can be Oracle 10g or higher.

  2. Upgrade Bitvise WinSSHD to 4.28 and Tunnelier to 4.29 for Windows only.
  3. Improve error message when standby fails to start during standby database creation.
  4. Add message to remove old archives when activating standby database.
  5. Add smtp authentication and other advanced Mail settings.
    See MAILCFG_AUTH_USER and MAILCFG_AUTH_PASSWD settings.

  6. Attach trace files to email when Dbvisit errors to forward to Dbvisit support. Set filesize limit of 768000 bytes for attachments.
  7. Database files are tested for correct location during creation of standby database. If not correct then user is asked to rename them.
  8. Standby redo log names are tested for correct location during graceful switchover.
  9. Add variable SEND_MAIL_FLAG_DR to turn off mailing from standby server.
  10. Add ability to manually email trace files as attachments with option:
    dbv_functions -m tracefilename

Fixes:

  1. Check if Oracle database admin directories exists before creating the standby database.
  2. Fixed Dbvisit repository create error in Oracle 8i.
  3. Add check for ORA-00344: unable to re-create online log when activating standby database.

Dbvisit can be downloaded from our website http://www.dbvisit.com.

Activating the standby database to become the primary database is also refered to as a failover. Failover happens in case of a disaster or severe failure on the primary site and users are no longer able to connect to the primary database. The standby database is activated to become the new primary database so that users can connect to the new primary database on the standby site.

The decision for failover or activating the standby database should be made carefully as this process cannot be reversed so it is crucial that this only happens in case of a real disaster or severe outage.

Automatic Failover
Automatic failover is where the software determines when the standby database should be activated to become the new primary database. There are numerous conditions that can occur (ie: network glitches/outages) in any system which theoretically could disrupt communications between the primary and standby sites. Because of this variability the decision to perform a failover, and activate the standby database, is left in the hands of the operator(s), and is not built in to Dbvisit itself.

However it is possible to automate this failover process, if one choses to do so, and was aware of the associated risk inherent in this. This could be achieved with some scripts or a basic app, created to run on the standby server or a third “observer” server.

What happens during activation?
What happens when the Oracle standby database is activated to become a primary database?
To activate the standby database one of the following commands can be given:
1) Manual SQL comand:
SQL> alter database activate standby database;
2) Dbvisit command:
dbv_oraStartStop activate database_name
Ensure that all archives have been applied to the standby database before activating the standby database.

This initiates an OPEN RESETLOGS operation on the standby database to create the redo logs. The redo logs are newly created because in its normal standby database state, the redo log files are not present and are not needed. Note Oracle Enterprise Edition uses standby redo logs, but these are different to normal redo logs.
When you create a standby database, you actually do not need to copy the redo logs from the primary database.

So the OPEN RESETLOGS operation creates the physical redo log files. If Oracle cannot create the redologs then the operation will fail and the database will still be a standby database. Oracle uses the information from the controlfile to determine where to create the redo log files. The redo log file information in the standby controlfile is therefore just a reference to where the redolog files should be created if OPEN RESETLOGS operation is given.

Example
In the example below the redo log is renamed to an invalid filename to emulate what happens when the standby database is activated:
SQL> alter database rename file '/oracle/oradata/dbvisitp/redo01.log'
to '/oracleX/oradata/dbvisitp/redo01.log';

Database altered.

SQL> alter database activate standby database;
alter database activate standby database
*
ERROR at line 1:
ORA-00344: unable to re-create online log
'/oracleX/oradata/dbvisitp/redo01.log'
ORA-27040: file create error, unable to create file
Linux Error: 2: No such file or directory

The database is still a standby database as the activation failed. We cannot manually create the redo logs, as this is an Oracle internal operation. The only thing we can do is to give the correct location for the redo log files.

Rename the redo log to the correct location:
SQL> alter database rename file '/oracleX/oradata/dbvisitp/redo01.log' to
'/oracle/oradata/dbvisitp/redo01.log';

Database altered.
SQL> alter database activate standby database;

Database altered.

SQL>

The standby database has been activated and is now a primary database. Oracle has created the redo logs at the location specified.
Note: all previous backups of this database are now invalid and cannot be used to restore this database. This is because of the RESETLOGS command which resets the archive sequence number (SEQUENCE#) and invalidates all previous archive logs. The SCN number of the database is not reset.
Now is a good time to make a new backup of your database!

We are pleased to release Dbvice – a Free Oracle Database Security Audit Utility that can be run against any Oracle database. We are still in Beta testing, but we have made it available for public download.
Dbvice is run directly on the Oracle database server. Dbvice does not need to be installed or configured. Dbvice will automatically detect the databases installed on the database server, and will prompt for which database to run the audit.

Dbvice audits the database based on the recommended security checks published by Oracle to ensure a database is secure. Dbvice does not alter the database or implement any changes, it only reports on recommended security settings.
Dbvice performs the following checks:

  • Listener secure
  • User privileges
  • Database options
  • Sample schemas
  • Remote Authentication
  • Oracle file security
  • Public Privileges

Dbvice can be run against any Oracle version, and on most platforms.
Free download www.Dbvice.com – Oracle Database Security Audit.

Dbvisit 5.2.15 has been released for all platforms.

Fixes:

  1. Create standby database fix. If the size of the tablespace is displayed as a float instead of number, then the insert into the Dbvisit repository fails. This has been fixed.
  2. Improve error message when controlfile is a backup controlfile.
  3. If the word export is used too many times in the DDC file, then assumes the DDC file is from Dbvisit version 4. This has been fixed.
  4. Improve message when standby database has insufficient SGA size.

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

A good location for the Disaster Recovery (DR) site could be current primary site. The primary site then becomes the remote location.

The reason for this is, that in the event of a disaster at the primary site (housed in the remote location), your current staff will be on hand and available to manage the standby site (which will now become the primary site).

Distance between primary and disaster recovery sites: How Far Away is Far Enough?
An interagency white paper by the SEC, Federal Reserve and other agencies that came out after 9/11 suggested a 200-mile or 320-km plus separation between the primary and secondary facilities. The two locations should be in a geographically different location. So if one location is prone to earth quakes or floods, then the other location should not be prone to the same conditions. Ideally they should be on a different power grid.

One of the first things to go when a disaster strikes is cellphones or mobile phones. Even if the cellular infrastructure is still intact, there will be some many cellphone calls made, that the system could easily be overloaded. So make sure your DR plan has sufficient contigencies in place without the use of mobile phones.

One of our successful partners in South America – Palacios Software has organised a number of presentations on interesting topics including fusion middleware, JDeveloper, ADF, Jheadstart and Disaster Recovery. The Disaster Recovery topic focuses on how Dbvisit can assist companies with business continuity (BC) and high availability (HA) in case of a disaster, outage or failure.

To view our Dbvisit power point presentation (in English) please see Dbvisit presentation.

Dbvisit 5.2.14 has been released for all platforms.

New features:

  1. Provide the ability to logon with sys user and password. This can be used when sysdba logon without password cannot be used or when SQLNET.AUTHENTICATION_SERVICES= (NTS) cannot be set.
  2. Improve message for error 837, sqlplus not found.
  3. Improve message for ORA-01031: insufficient privileges.

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

Overview of all the latest changes: http://www.dbvisit.com/changes.php

Every time I use Perl, I am amazed at this programming language created by Larry Wall. I have used several languages in the past, but Perl is now my favourite. It takes a little getting used to, but once you are used to it, it is great.

What makes it so great

  • CPAN site. Small and large Perl modules that can be easily plugged into your code to make life easier. Some of the modules available are: logging, email, html template engines etc. There are over 70,000 modules.
  • Runs on Windows, Linux, Mac and Unix as well as other OS. It is truly a multi-platform language. For each OS you do have to take certain precautions, but there are CPAN modules that allow you to deal with each OS’es peculiarities like file name conventions.
  • It can be used in OO style but also conventional style.
  • It is very efficient. With very few lines of code, a lot can be achieved.

I have read the following negative things being said about Perl:
- “Good for little programs, but not for large programs because you get spaghetti code.”
I think this is not true, in any language you can write spaghetti code. This is not due to the programming language but due to the programming style.

- “Things can be done in more than one way”
I think this can be a good thing or a bad thing. With Perl, I consider this a good thing as it demonstrates the power and flexibility of the language.
True this can mean that Perl can be a bit cryptic as you may be used to seeing things solved another way. However it is a great language if you are a perfectionist and always keen to learn new things. With Perl there is almost always a better way to do things and you learn all the time. At least I do.

True, Perl is not so trendy anymore as say Python, Ruby or Java. It is also cometimes difficult to compare different languages as some are more suited to a particular application than others. You also have to look at how well the language is known and how many resources are available. For example to build a website I would probably choose PHP over Perl as there are so many more PHP programmers in the world than Perl programmers ( I also like PHP).

If you are an Oracle DBA that likes to automate specific tasks, I would highly recommend using Perl. I used to do everything in Korne Shell, and I thought it was a great language. But once you learn Perl, you realise your hands are no longer tied behind your back!

Perl is great to automate some of the tasks that may be required in your disaster recovery plan. This can be changing tnsnames.ora entries, or DNS entries.

You are not in isolation if you use Perl in your organisation. Oracle 11g uses Perl to write some of their interfaces. For example asmcmd (and asmcmdcore) are witten in Perl. Vmware uses Perl for their installation routine.

CPAN

To install a cpan module, type cpan (in Windows use PPM. Start cmd and type ppm):

CPAN>i /mailer/

The i is for information, this will list all modules with the word “mailer”.

To install a particular module, you have to specify the name exactly as it appears:

CPAN> install Mail::Mailer
That’s it and you can use it.

How to learn Perl

The best way to learn Perl is to start with a small project. For example write a little Perl program that scans the Oracle alert log and send an email if an error appears. You will probably have Perl installed already because Perl comes pre-installed on Unix and Linux. On Windows go to activestate.com and download Perl.

The best Perl book in my opinion is Programming Perl by Larry Wall, Tom Christiansen, Jon Orwant.

So thanks to Larry Wall and all the great people that help support Perl and CPAN.

One of the questions we get asked a lot is:
In terms of ORACLE licensing, do we need a separate Orcacle license for the DR / Standby database?

Yes, you require a separate Oracle license for the DR / Standby database. This license has to be the same license metric as the primary database. This means that if you license the primary database per CPU, then the standby database must also be licensed per CPU (although it does not have to be the same number of CPU).

Or if the primary database is licensed per user then the standby database must also be licensed per user.

It must be the same license type, so if your primary database is Standard Edition, then the standby database must also be Standard Edition.

We might go for Standard Edition Processor based licensing option, which allows us to have up to 4 CPU in total. If we have a production / primary server with 4 CPU, will the licensing work with standby database?

You will require a separate Oracle Standard Edition license for the standby database which is also processor based. With Dbvisit we include the standby database with the Dbvisit license for the primary database.

How would the licensing work for Multiple standby databases?
Oracle is licensed per server not per database, so you can have as many databases as you wish on the same server. With Dbvisit we have 2 types of licenses, Single Instance or Multiple Instance (or server license). If you have Dbvisit for 1 primary database, then the Single Instance license is needed. If you have Dbvisit for more than 1 primary database on the same server, then the Multiple Instance license is required. With all Dbvisit licenses you can have unlimited standby databases.