Propagating Accelerator In-Memory Changes and Condensing the Log

This section covers instructions on how to manage in-memory changes and the transaction log for the Accelerator database. It includes steps for monitoring the size of in-memory changes, propagating these changes to the database, and condensing the log to ensure optimal performance and stability.

Introducing in-memory changes and the transaction log

To ensure high performance, the columnar database driving Accelerator performs most tasks in memory. Transactions are only written to disk when the system is idle. The Actian system tries to propagate transactions and condense the log periodically, but this can fail if the system is constantly processing transactions.

As an Accelerator administrator, you need to monitor the volume of in-memory changes to prevent them from growing too large. When stopping the accelerator, for example, for an upgrade, make sure all database transactions are written to disk. Failure to do so can cause startup delays as unpropagated in-memory changes are read into memory, or the system may fail to start if the in-memory changes exceed the allowed memory size for the Actian process.

This is a two-stage process:

Propagate in-memory changes: Write the in-memory changes to the database.
Condense the log: Remove the in-memory changes now written back to the database. For more details, refer to Appendix 1: Additional Information Relating to Log Propagation.

Note: Propagating the in-memory changes and condensing the log can take some time. This will fail if in-memory changes are made via queries while this is running. As such you must ensure that the steps in the previous sections to effectively stop all queries running on the database must be carried out to ensure that this will complete successfully. This activity, given the time that it is likely to take must be planned at a time when it is least disruptive to the users of the system.

How to Monitor the size of In-Memory Changes

The command vwinfo -M <DATABASE> will return what tables are accumulating in memory change and the size of these.

Thus on a typical Accelerator the steps will be:

Connect to Hubble Accelerator server.
Switch user to the Accelerator database user.
```
# su actian
```
Run the above vwinfo command.
```
# vwinfo -M db
```

How to Propagate the In-Memory Changes into the Log and Condense the Log

Proceed as follows:

Connect to Hubble Accelerator server.
Switch user to the Accelerator database user.
```
# su actian
```
At this point you need to decide if you want to propagate specific tables where the in-memory changes are particularly large or if you want to do this for all tables in the schema. As noted above, propagating changes can take some time and as the administrator you need to know how large a downtime window your business can tolerate and plan accordingly.

To propagate the in-memory changes for specific tables you need to run the command echo "call vectorwise (combine '<TABLE>')\g" for each table.
```
echo "call vectorwise (combine 'jde.f0911')\g" | sql db
```
Alternatively, to propagate the in-memory changes for all tables in the database run the following command.
```
echo "call vectorwise (combine)\g" | sql db
```

After propagating the changes to all the desired tables in a given schema the following command should be run to condense the log.
```
echo "call vectorwise (condense_log)\g" | sql db
```