This section describes read-only hardware operations in a typical scenario.
Read-only hardware functionality does not require WORM disk array hardware. You may remove write privilege from a raw device or file system file after the dbspace is altered read-only.
Consider an IQ database consisting of a single catalog store dbspace named db.db with three main IQ dbspaces: A, B and C.
At time t0, alter all three main dbspaces read-only.
Copy db.db to db.db0, either by shutting the database down and copying db.db or using dbbackup to make a copy while the database is still running.
Freeze dbspaces A, B and C at the hardware level. Store db.db0 in an immutable form, perhaps by storing it in a file system file on the WORM device and freezing it.
At this point, the database has been archived as of time t0 in an immutable form.
Create two new main dbspaces D and E.
Continue using the database db.db as a production database.
The database objects (tables, indexes, etc.) that existed as of time t0 may have changed so that db.db does not equal db.db0. db.db continues to read data from dbspaces A, B and C as long as the tables that existed at time t0 exist and as long as they contain some unmodified rows of data that existed as of time t0. Even if or when this is no longer true, db.db will continue to open A, B and C unless they are dropped from db.db, which is only allowed if they are empty from db.db's point of view.
Suppose that you need to examine the archived database as of time t0.
Copy the archived read-only db.db0 to a read-write file db.db0.working.
Start db.db0.working. Note that as long as the server name db.db0.working does not conflict with the production system db.db, there is no need to stop the production system. db.db0.working will open A, B, C, and D in read-only mode. This will not interfere with db.db's use of these files on UNIX, although Windows returns a sharing violation.
Note that the catalog file db.db0.working is open in read-write mode.
Create a user inv for an investigator who wishes to examine the archived database.
Grant inv RESOURCE permission to create views, stored procedures, global or local temporary tables or any other structures necessary for the investigation.
db.db0 as well as A,B and C remain unchanged.
If years have passed since time t0, you may upgrade the db.db0.working as long as ALTER DATABASE UPGRADE modifies no objects in the IQ Main store.
The temporary dbspaces that existed as of time t0 are not required to start db.db0.working. Use the server startup switch -iqnotemp to start db.db0.working
Drop and create new temporary dbspaces or use the temporary space created by the -iqnotemp parameter.
Create a new archive at time t1 as follows.
Alter dbspaces D and E read-only.
Copy db.db to db.db1.
Freeze D and E.
Save db.db1 in an immutable form.
Create new main dbspace(s), e.g. F and G.
Continue to use the production system db.db.
At any time, it is possible to use the archived databases db.db0 or db.db1, or even both simultaneously, by simply copying db.db0 and/or db.db1 to a working file and starting a server.
Perform the steps in “Creating an archive” followed by the steps in this section to create any number of archived versions of db.db.