Pythian Group

Is your database in archive log mode?

Is your database in flashback mode?

Have you defaulted your archive location to the flash recovery area?

Is your ORACLE_SID lowercase?

Do you use SQL BackTrack?

If your answer is yes to all these questions then beware!

There is a bug in SQL BackTrack (at least in version 6.8) that prevents your backing up of the archive logs from the flash recovery area. This will result in the inability to recover from any online backups that you have taken if you somehow lose those archive logs.

You do not receive any obvious errors when doing the backup but, if you are observant, you may spot the fact that the backup report does not show that it backed up any archive logs. To really check whether you are suffering from this problem then you need to check the $DTBASE/obacktrack/log/datatools.log. This is the log that gets written whenever any SQL BackTrack command is run. You will see an error such as

17:29:16.61 obacktrack[839826](2835/oramisc.cpp): Unable to open directory: '/home/oracle/data/test/test/archivelog'

You will know if you have been caught by this bug when you try to restore and you get messages that look something like this.

BMCBKO4802051E: The following Oracle error occurred during
BMCBKO4802051E: SQL-BackTrack processing : 'ORA-01195: online backup of file 1 needs more recovery to be consistent'
BMCBKO4802051E: The following Oracle error occurred during
BMCBKO4802051E: SQL-BackTrack processing : 'ORA-01110: data file 1: '/home/oracle/data/test/system01.dbf''
BMCBKO4805906E: Unable to perform recovery.

The problem arises when Oracle creates a directory in the flash recovery area that correspond to the database name. This directory is in uppercase. So, in my case, my ORACLE_SID is test and the init.ora parameter db_recovery_file_dest='/home/oracle/data/test'.

Oracle creates the directory
/home/oracle/data/test/TEST.

However when SQL BackTrack sees that the archive location is defaulted to the flash recovery area it tries to look in the directory
/home/oracle/data/test/test.

This fails … silently!

There are 2 workarounds to this issue that I have tested.

1. Create a symbolic(soft) link to point to the real directory using ln -s
2. Explicitly set the archive location using the init.ora parameter log_archive_dest_n

The workaround suggested by BMC (the supplier of SQL BackTrack) is to change the database name to uppercase. This will work too, but I haven’t tested it.

In 3 words:

They already do.

MySQL Enterprise is more than just a binary. http://mysql.com/products/enterprise/ has the details on the other features MySQL Enterprise includes.

One of these features is the MySQL Enterprise Monitor, which is closed source, proprietary alerting software.

So when bloggers make statements such as:

MySQL will start offering some features (specifically ones related to online backups) only in MySQL Enterprise. This represents a substantive change to their development model — previously they have been developing features in both MySQL Community and MySQL Enterprise. However, with a shift to offering some features only in MySQL Enterprise, this means a shift to development of those features occurring (and thus code being tested) only in MySQL Enterprise.

source

All they are doing is showing their lack of knowledge about what MySQL Enterprise really is. Complaining that MySQL will likely charge for online backups is a valid one, but currently InnoDB Hot Backup is for sale only. There are solutions out there that do not cost anything, but nothing that MySQL produces. The only free [mostly] online backup product is mysqlhotcopy, and that has limitations such as “for MyISAM tables only”.

While I have said that software should be open source and free, where “free” means “free as in water”, that does not mean that we should take it for granted that free software will always be there. The path to that is to have a contrast of software one pays for, and software one does not.

Of course, that is not why MySQL charges for the software. They charge for some of their products because without money, they cease to exist, and then even the free version stops being developed on.

“A necessary evil” is a dangerous phrase, and can lead to a slippery slope….but in this case, I do not envision that it is a big problem. Maybe I will regret saying this if things keep getting more and more closed, but I do not believe so.

And I, too, am frustrated that we have been told that “online backups are coming” only to find out that they may not come in the means I expected. However, software is not bug-free, often does not come out on time (MySQL 5.1 itself is a year late!), and sometimes, promises get broken.

My faith in MySQL is unbroken, and I hope most others reading this feel this way as well.