Storage Provisioning for TimesTen

Storage provisioning is the process of allocating server storage space.

• TimesTen installation storage allocation: A TimesTen installation includes all of the software.

  Plan to allocate at least 1.5 GB for each TimesTen installation. If you run multiple instances on the same system, they can all share a single TimesTen installation. In order to incorporate software version upgrades, you should provision double that amount of space, plus some additional space.

• TimesTen instance storage allocation: Each TimesTen instance runs its own set of daemon processes (with associated daemon log files).

  Plan to allocate at least 256 MB for each TimesTen instance.

• Checkpoint files: Each TimesTen database requires disk space for two checkpoint files, each of which is stored in the directory that is specified with the DataStore attribute. As each checkpoint file grows on the file system, it never decreases in size. This can result in the size of each checkpoint file being equal to the maximum size that the database has ever reached in the permanent memory region. Thus, you should plan as though each checkpoint file occupies approximately the same amount of space as defined for permanent memory (as defined with the PermSize connection attribute).

  Plan to allocate twice the total permanent space of your databases plus 30%.

  Note:

  For TimesTen Classic, you can set the Preallocate connection attribute to 1 to have TimesTen reserve file system space at connect time for checkpoint files. This is useful for large databases, which ensures that the file system always has room for the checkpoint files as data is added to the database. For more information, see Preallocate in the Oracle TimesTen In-Memory Database Reference.

• Transaction log files: Transaction log files are the most difficult space requirement to estimate. See Storage Provisioning for Transaction Log Files for how to plan for space provisioning for transaction log files.

• Local space to facilitate backup or export files for repositories in TimesTen Scaleout.

  When you use an SCP-attached repository, any operations are first saved locally by the target instances before copied to the repository. The target data instances initially store the backup (or export) files to the $timesten_home/grid/admin/temp directory. You must ensure that you provision enough storage in this directory to accommodate the maximum size for backup or export files that would end up in a repository.

  Plan to allocate space of PermSize times the number of replica sets.

• Repository storage provisioning in TimesTen Scaleout.

  A single backup file contains one element from each replica set. Thus, the number of backup files needed to contain all of the rows of the tables in the database corresponds to the number of replica sets in your database.

  Note:

  For hash distributed tables, only a portion of the rows of the tables are included in each backup file. The rows of hash distributed tables are distributed across the number of replica sets.

  For duplicated tables, each backup file contains all rows in each table.

  Plan to allocate space of PermSize times the number of replica sets.

Storage Provisioning for Transaction Log Files

There is a process for estimating the necessary file system space allocation for transaction log files

Note:

You can generate a more accurate estimate of the transaction log volume within a test environment.

Consider the following when estimating the necessary file system space allocation for transaction log files:

• TimesTen keeps enough transaction log files to support recovering from either checkpoint file. Transaction log files may accumulate depending on the settings for background checkpoint operations (defined with the CkptLogVolume and CkptFrequency first connection attributes). In addition, TimesTen preallocates space for three additional transaction log files.

• TimesTen uses fuzzy checkpoint operations for background operations. Transaction log files can accumulate during fuzzy checkpoint operations. The amount of time taken to create a checkpoint scales with the value assigned to the PermSize connection attribute.

• Transaction log files may accumulate between incremental backups.

• In TimesTen Scaleout, each element in each replica set has its own transaction log files to store transaction log records. If a transaction modifies data in a replica set, then the changes are usually recorded in both elements of the replica set. However, if one of the elements in the replica set is down, then the changes are only recorded in the transaction log files for the active element. Transaction log files can accumulate if one element in a replica set is down for a very long time.

• In TimesTen Classic, transaction log files may accumulate on the master during temporary replication outages or if the subscriber is down.

  Note:

  You can limit the number of transaction log files retained with the FAILTHRESHOLD clause on the CREATE REPLICATION and ALTER REPLICATION statements.

See CkptLogVolume, CkptFrequency, and PermSize in the Oracle TimesTen In-Memory Database Reference for more information on these connection attributes. See CREATE REPLICATION and ALTER REPLICATION in the Oracle TimesTen In-Memory Database SQL Reference for more information on these SQL statements.

The estimate of the transaction log volume depends on the peak update transaction rate and the average complexity of each transaction that modifies the database.

Consider:

• B represents the transaction log volume in bytes per transaction.

• C represents the number of columns updated. The minimum transaction update (which is an update of a single number column) generates 400 bytes of transaction log data. Each additional number column update generates another 250 bytes.

• V represents the average size of larger data inserted or updated (columns of type CHAR, VARCHAR2, BINARY, VARBINARY or LOB) for each write transaction.

To estimate the transaction log volume for each transaction, use this formula:

B = 400 + ((C-1) * 250) + V

Note that the first column is just 150 bytes more than all subsequent columns, as follows:

B = (C * 250) + (400-250) + V

which simplifies to:

B =(C * 250) + 150 + V

Multiply the estimated transaction log volume value (B) by the expected peak transaction rate to find the expected peak transaction log rate.

Where:

• L = total storage space to provision for transaction log files in bytes.

• C = average number of columns inserted or updated per write transaction.

• V = average bytes of large data (CHAR, VARCHAR2, BINARY, or VARBINARY columns) inserted or updated for each write transaction.

• S = time in seconds of required transaction log retention.

• T = peak transaction rate per second averaged over intervals of S seconds.

• f = fraction of transactions that include insert, update, or delete operations.

• Lastly, increase the estimated file system space by an additional 30% for contingencies.

Taking all these factors into account, estimate provisioned transaction log file space in bytes according to this formula:

L = ((C * 250) + 150 + V) * S * T * f * 1.3

For example, a workload consists of 35% update transactions. Each transaction updates four columns, including two character columns each averaging 30 bytes updated total. The workload runs at 1 million transactions per second and needs enough transaction log space to hold one hour's worth of transactions.

• C = 4 columns

• V = 30

• S = 3600

• T = 1,000,000

• f = 35% = 0.35

Thus, you would estimate that the storage provisioning workload requires:

L = ((4 * 250) + 150 + 30) * 3,600 * 1,000,000 * 0.35 * 1.3 = 1.9 TB

Thus, provision file system space of 1.9 TB for the transaction log files.