Click here to view and discuss this page in DocCommentXchange. In the future, you will be sent there automatically.
This window has the following components:
Choose an isolation level to be used for the refresh operation Select one of the following isolation levels to specify the type of locking to use on the underlying base tables during the refresh. The type of locking determines how the materialized view is populated and how concurrency for transactions is affected.
Read uncommitted (level 0) This option provides the maximum level of concurrency, but dirty reads, non-repeatable reads, and phantom rows may be observed in result sets.
Read committed (level 1) This option provides less concurrency than level 0, but eliminates some of the inconsistencies in result sets at level 0. Non-repeatable rows and phantom rows may occur, but dirty reads are prevented.
Repeatable read (level 2) This option allows phantom rows to occur. Dirty reads and non-repeatable rows are prevented.
Serializable (level 3) This option provides the least concurrency, and is the strictest isolation level. Dirty reads, non-repeatable reads, and phantom rows are prevented.
Snapshot This option uses a snapshot of committed data from the time when the first row is read, inserted, updated, or deleted by the transaction. Snapshot is the default if the view is a manual view and the database is using snapshot isolation.
Share mode This option provides read access on underlying tables to other transactions while the refresh operation takes place. When this clause is specified, shared table locks are obtained on all underlying base tables before the refresh operation is performed and until the refresh operation completes the REFRESH MATERIALIZED VIEW statement.
Share mode is the default if the view is a manual view and the database is not using snapshot isolation. Share mode is also the default if the view is an immediate view, regardless of whether snapshot isolation is enabled.
Exclusive mode This option places exclusive table locks on all underlying base tables. No other transaction can execute queries, updates, or any other action against the underlying table(s) until the refresh operation is complete. If exclusive table locks cannot be obtained, the refresh operation fails and an error is returned.
Choose this mode if you do not want to change the isolation level, but want to guarantee that the data is updated to be consistent with committed data in the underlying tables. See REFRESH MATERIALIZED VIEW statement.
|Send feedback about this page via email or DocCommentXchange||Copyright © 2008, iAnywhere Solutions, Inc. - SQL Anywhere 11.0.0|