> we are currently evalutating the process for mirroring a database using  "write suspend/resume"
> and mirroring the database files (SMS) with  flashcopy/snapshot technic of the raid subsystem.

> In the fixpack docu i found a comment that  using db2inidb with the snapshot option will
> result in a "read only" database!  Has anyone used this option?  Is it really a
> R/O database. We plan to use this "mirror" as a analytical database, where different
> statistical scenarios will be run using different metrics. So we need updating some tables
> for customization for this metrics.

> Thanks
> Thomas

> > we are currently evalutating the process for mirroring a database using

> > In the fixpack docu i found a comment that  using db2inidb with the

> > Thanks
> > Thomas

> When db2inidb was introduced in DB2 I started to investigate it on AIX
> but stranded. 1. My usage resulted in APAR IY16529 (fixed in Fixpack
> 3) 2. It seemed that it was related to SMS tablespaces 3. Asked for
> better explanation of the capability and stopped in the meantime (up
> to now).

> Even with fixpack info and the manual, even with the manual Data
> Recovery and High Availability Guide and Reference lanual,
> documentation remains very obscure (SMS and DMS supported?) and the
> read-only state is part of it. I'm curious to see other postings.

> A number of users (and I implemented it also) take logs from a main
> system and replay the logs on another system (as tablespace definition
> changes could be in the logs, replay of the logs can not be done on
> the same system). But the database remains in rollforward pending, the
> notion read-only does not exist here, I find this very unfortunate and
> missing in the design. I wonder if splitting of the database could
> alleviate this limitation.

> Bernard Dhooghe

> > > Hi,

> > > we are currently evalutating the process for mirroring a database
using
> "write suspend/resume"
> > > and mirroring the database files (SMS) with  flashcopy/snapshot
technic
> of the raid subsystem.

> > > In the fixpack docu i found a comment that  using db2inidb with the
> snapshot option will
> > > result in a "read only" database!  Has anyone used this option?  Is it
> really a
> > > R/O database. We plan to use this "mirror" as a analytical database,
> where different
> > > statistical scenarios will be run using different metrics. So we need
> updating some tables
> > > for customization for this metrics.

> > > Thanks
> > > Thomas

> > When db2inidb was introduced in DB2 I started to investigate it on AIX
> > but stranded. 1. My usage resulted in APAR IY16529 (fixed in Fixpack
> > 3) 2. It seemed that it was related to SMS tablespaces 3. Asked for
> > better explanation of the capability and stopped in the meantime (up
> > to now).

> > Even with fixpack info and the manual, even with the manual Data
> > Recovery and High Availability Guide and Reference lanual,
> > documentation remains very obscure (SMS and DMS supported?) and the
> > read-only state is part of it. I'm curious to see other postings.

> > A number of users (and I implemented it also) take logs from a main
> > system and replay the logs on another system (as tablespace definition
> > changes could be in the logs, replay of the logs can not be done on
> > the same system). But the database remains in rollforward pending, the
> > notion read-only does not exist here, I find this very unfortunate and
> > missing in the design. I wonder if splitting of the database could
> > alleviate this limitation.

> > Bernard Dhooghe

> The snapshot option supports split mirror of both SMS and DMS tablespaces.
> Once the split mirror is initialized with the snapshot option it will
become
> a fully functional database (NOT read-only). The snapshot option of the
> "db2inidb" tool is used to create a clone database. It forces the split
> mirror database to go through a crash recovery and starts a new log chain.
> Therefore, this clone database will not be able to replay any future log
> files from the source database. If the database contains DMS only
> tablespaces, a database backup can be taken from this clone database and
it
> can be restored to the source database. However, it will not be able to
> rollforward through any log records generated on the source database after
> the database was split. Thus it will be a version level copy only.

> In snapshot scenario, the split mirror of a database includes the entire
> contents of the database directory, all the
> tablespace containers, the local database directory and the active log
> directory if it does not reside on the database directory.

> Shahed Quazi