Open topic with navigation
A snapshot storage manager is a storage manager that has the ability to save database snapshots. An SSM is considered to be a database process in the same way that storage managers and transaction engines are referred to as database processes. A database can have zero or one snapshot storage manager.
An SSM has an archive and a journal just like a storage manager and communicates in the same way as a storage manager. Just like a storage manager, an SSM receives replication messages and saves the effects of those messages. An SSM communicates with all processes (TEs and SMs) that serve the same database.
In addition, an SSM saves a snapshot for every committed transaction and stores these snapshots in its snapshot archive. Saving and storing database snapshots provides continuous data protection (CDP) because each snapshot provides a virtual copy of the entire database. A snapshot shows what the database looks like at that point in time.
During development in a small test environment, it is permissible to locate a database’s archive, journal and snapshots all on the same disk. However, for best performance when SSMs are supported for a production environment you will want to locate a database’s archive, journal and snapshots on three different disks.
An SSM can serve only the
ALL storage group. See About Storage-Group All.
An SSM captures schema as part of a snapshot and each snapshot reflects the schema at the time the snapshot was saved regardless of most subsequent DDL operations. In this release,
DROP SCHEMA is not supported by an SSM. While you may drop a schema from your database, you cannot restore to a snapshot in order to access a dropped schema.