Informix onunload/onload to take a snapshot and then restore

informix

I have an Informix database. I want to take a snapshot, make some changes, then restore the database from that snapshot. (If Informix supported nested transactions, I would be using transactions.)

The database is of moderate size (it can run on a consumer laptop) and there is no replication. It is critical that this backup/restore procedure is as fast as possible (I would like to do a backup-modify-restore cycle several times per second if possible). Only a small part of the database would be modified between the backup/restore points.

Reading around a bit, it sounds like onupload/onload commands are the way to go. I can't quite figure out how to use them.

Can you please show me the way to take a snapshot of a running database, and restore that database after some changes? (All on one machine.)

Or if there is a better way to achieve this effect? (Perhaps there is a way to fork the process and all its files in a copy-on-write manner and have the child process serve a clone of the database on a different port?) If so please let me know.

Best Answer

First of all, Informix supports transactions if you create a logged database (WITH LOG or WITH BUFFERED LOG). Further, it supports transactions (BEGIN) and transaction nesting with SAVEPOINT and COMMIT and ROLLBACK TO SAVEPOINT.

Using onunload and onunload might be workable, but you need to be confident you aren't using blobs (smart blobs), or UDTs (user-defined types). I'd have to research the details of how to use them for your proposed task; it probably is fiddly. I'm not sure that I've seriously used either command this millennium, and I didn't often use them in the last millennium either.

If you have several Informix server instances, you could consider using ER (Enterprise Replication) to make a copy of the relevant sections of the database in a separate server, and then do your experimentation on that other server.

If you have shared disks, you might be able to use an SDS (shared disk secondary) node with care.

If transactions are sufficient, I recommend using them rather than the alternatives. Just ensure you have enough logical log space to be able to roll the transactions back (look up 'long transaction', LTXHWM and LTXEHWM).

Related Question