Exclusive Operations on Aggregate Storage Cubes

Some operations on Essbase aggregate storage (ASO) cubes are exclusive, meaning they cannot run concurrently with others of the same type of operations. Queries against the cube can continue while exclusive operations are in progress.

On aggregate storage cubes, multiple exclusive operations cannot be performed simultaneously on the same cube. If one exclusive operation is running and a second exclusive operation is attempted simultaneously, the second operation is rejected with a message indicating that the operation cannot proceed while the first operation is in progress. For example, when performing a partial data clear, a second partial data clear cannot run concurrently, even if the operations are clearing different regions. While most exclusive operations are mutually exclusive, there are some exceptions.

Exclusive operations and exceptions:

• Export

  Multiple export operations can run at the same time because export is a read-only operation. Export operations can run at the same time as build aggregations and backup, both of which are exclusive operations; however, export is not compatible with any other exclusive operation.

• Build aggregations

• Backup (putting the cube in read-only archive mode)

• Data load (committing the contents of a load buffer to the cube)

  Creating an aggregate storage load buffer and loading data into the load buffer are not exclusive operations. These operations can run concurrently with any other operations. However, committing the data in the load buffer to the cube is an exclusive operation.

• Spreadsheet send operations (for example, updating cells)

  If a send operation is running while another exclusive operation is attempted, the new operation waits for the send operation to finish before proceeding. Even though not compatible with the send operation, the new operation does not error out, because send operations are assumed to be small and fast (<5 seconds). This means it is possible for many users to perform spreadsheet send operations at the same time without those operations being rejected because they are incompatible with each other.

  Note:

  In the case where multiple exclusive operations are attempted while a send operation is running, the order in which the new exclusive operations execute after the send operation completes is random; the order is not based on the sequence in which the new exclusive operations were attempted. For example, if a send operation is running and an exclusive operation of a different type is attempted, the new exclusive operation waits for the send operation to finish before proceeding. If, in the meantime, more send operations are attempted by other users, those send operations might be executed before the other exclusive operation, even though they were attempted afterward. Therefore, the exclusive operation might wait indefinitely as long as there is at least one send operation waiting to be executed.

• Merge slices

• Custom calculations, allocations, and other write operations

• Data clear operations (full, aggregates only, and partial)

Queries are allowed to run concurrently with all exclusive operations. However, if an operation adds, changes, or removes any data in the cube, the following sequence takes place at the end of the operation, when the changes are made visible to queries:

1. Any new queries are temporarily blocked from starting (the queries wait).

2. Existing queries finish running.

3. Data changes from the exclusive operation are committed to the cube.

4. Queries that are waiting proceed.

Queries are never rejected or canceled because of an operation that changes data on an aggregate storage cube.