2Yo:
В последней версии - ASA10 появилась поддержка snapshot.

Сейчас на сайбэез.ком в разделе документации доступны олько pdf-файлы, а онлайн хтмл-ек я не нашел. Я кое-что вставлю сюда из втроенной справки, но т.к эта тема в этом топике оффтоп, то при желании можно продолжить в сайбезовом разделе. Версии хрянятся таки в темповых фалах, не в темпдб, т.к у аса нет темпдб. Любые темповые данные аса сохраняет во временных файлах, множество которых она создает и удаляет по своему усмотрению в процессе работы. Внендрение поддержки снапшот изоляции, кстати улучшило аса как блокировочник, т.к. они разработчики изменили алгоритмы управления индексами (версионность индексов), которые даже в режиме чистого блокировочника позволяют АСАшке лучше управлять блокировками.
Итак:

SQL Anywhere® Server - SQL Usage > Using Transactions and Isolation Levels > Isolation levels and consistency
A snapshot is a set of data that has been committed in the database. When using snapshot isolation, all queries within a transaction use the same set of data. No locks are acquired on database tables, which allows other transactions to access and modify the data without blocking. SQL Anywhere supports three snapshot isolation levels that let you control when a snapshot is taken:

snapshot Use a snapshot of committed data from the time when the first row is read, inserted, updated, or deleted by the transaction.

statement-snapshot Use a snapshot of committed data from the time when the first row is read by the statement. Each statement within the transaction sees a snapshot of data from a different time.

readonly-statement-snapshot For read-only statements, use a snapshot of committed data from the time when the first row is read. Each read-only statement within the transaction sees a snapshot of data from a different time. For insert, update, and delete statements, use the isolation level specified by the updatable_statement_isolation option (can be one of 0 (the default), 1, 2, or 3).
...[skiped]...
The following statements cannot be executed within a snapshot transaction:

ALTER INDEX
ALTER TABLE
CREATE INDEX
DROP INDEX
REFRESH MATERIALIZED VIEW
REORGANIZE TABLE
TRUNCATE TABLE is allowed only when a fast truncation is not performed because in this case, individual DELETEs are then recorded in the transaction log. See TRUNCATE TABLE statement.

In addition, if any of these statements are performed from a non-snapshot transaction, then snapshot transactions that are already in progress that subsequently try to use the table return an error indicating that the schema has changed.

Materialized view matching avoids using a view if it was refreshed after the start of the snapshot for a transaction.
...[skiped]...
Row versions
When snapshot isolation is enabled for a database, each time a row is updated, the database server adds a copy of the original row to the version stored in the temporary file. The original row version entries are stored until all the active snapshot transactions complete that might need access to the original row values. Remember that a transaction using snapshot isolation sees only committed values, so if the update to a row was not committed or rolled back before a snapshot transaction began, the snapshot transaction needs to be able to access the original row value. This allows transactions using snapshot isolation to view data without placing any locks on the underlying tables.

The VersionStorePages database property returns the number of pages in the temporary file that are currently being used for the version store. To obtain this value, execute the following query:

Old row version entries are removed when they are no longer needed. Old versions of BLOBs are stored in the original table, not the temporary file, until they are no longer required, and index entries for old row versions are stored in the original index until they are not required .

You can retrieve the amount of free space in the temporary file using the sa_disk_free_space system procedure. See sa_disk_free_space system procedure.

If a trigger is fired that updates row values, the original values of those rows are also stored in the temporary file.

Designing your application to use shorter transactions and shorter snapshots will reduce temporary file space requirements.

If you are concerned about temporary file growth, you can set up a GrowTemp system event that specifies the actions to take when the temporary file reaches a specific size. See Understanding system events.


И часть изменений в индексах:

Indexing enhancements The following enhancements have been made to indexing:

New index implementation Previous releases of SQL Anywhere contained two different indexing implementations that were chosen automatically based on the declared size of the indexed columns. In SQL Anywhere 10, a new implementation of compressed B-tree indexes is used throughout, and older B-tree indexing technology has been eliminated. The new indexes store a compressed form of the index key value in the index entry, separate and distinct from the value in the row. This is required to support snapshot isolation.

Support for snapshot isolation In previous SQL Anywhere releases, index entries were deleted on UPDATE or DELETE statements immediately. To support snapshot isolation, there is potential for several index entries to point to the same logical row with different index key values. These multiple index entries are managed by the database server so that any one connection can see only one of the entries for any given row. Periodically, a daemon within the server will physically delete these extra index entries when they are no longer needed (as transactions COMMIT or ROLLBACK). Retaining index entries for uncommitted DELETEs also improves semantic consistency of the concurrency control mechanisms in SQL Anywhere. See Snapshot isolation.