aEremenko: Излучая оптимизм

[Blog bot]

Источник: http://blogs.msdn.com/aeremenk/archi...15/666245.aspx
==============

В обновлении ядра Kernel Rollup для версии 3.0 был впервые использован механизм Optimistic Concurrency Control (OCC), более подробно о механизме можно почитать в SQL Server 2005 Books Online
Строго говоря, в Kernel Rollup OCC был задействован только для источников данных форм, остальные области, порождающие запросы к базе данных, не оптимизированы. Для поддержки OCC (а именно для обработки версий записей), в Kernel Rollup появилось поле RecVersion.

С точки зрения Microsoft Dynamics Ax модель OCC, реализованная в 4.0 и частично (как описано выше) в Kernel Rollup, состоит из следующих областей:

• Удаления (выключения) подсказок типа 'forupdate' в коде X++ (со стороны ядра).
• При обновлении одного или нескольких столбцов строки происходит проверка статуса изменения значения со времени, когда значение было считано в транзакции. Если значение было изменено, возникает исключительная ситуация и ядро генерирует исключение (Exception:UpdateConflict)
• X++ код изменен для обработки таких исключений в обработчике try-catch

OCC подразумевает оптимистический и пессимистический сценарии. Выдержка из SQL Server Books Online:
"In a database scenario, there are two types of concurrency control mechanisms:

• Optimistic concurrency control
  Optimistic concurrency control works on the assumption that resource conflicts between multiple users are unlikely, and it permits transactions to execute without locking any resources. The resources are checked only when transactions are trying to change data. This determines whether any conflict has occurred (for example, by checking a version number). If a conflict occurs, the application must read the data and try the change again. Optimistic concurrency control is not provided with the product, but you can build it into your application manually by tracking database access.
• Pessimistic concurrency control
  Pessimistic concurrency control locks resources as needed, for the duration of a transaction. SQL Server Mobile supports pessimistic concurrency control that locks resources as needed for the duration of a transaction."

Собственно, пессимистический сценарий очень уж напоминает работу Microsoft Dynamics Ax до Kernel Rollup.

В 4.0 возможны следующие параметры работы OCC:

• Оптимистический для тех таблиц, где включен параметр
• Оптимистический для всех таблиц
• Пессимистический

Есть также возможность использования уровня изоляции READ UNCOMMITED для всех запросов на чтение.

Что в итоге? В зависимости от нужд, можно оптимизировать производительность работы с базой данных. И это классно!

Однако надо учесть, что для оптимальной работы версионности записей (помните о RecVersion?) и, соответственно, OCC в Microsoft SQL Server 2005 необходимо включить уровень изоляции Read Committed Snapshot Isolation (RCSI).

Сделать это можно следующим запросом:
ALTER DATABASE
SET READ_COMMITTED_SNAPSHOT ON;

По умолчанию, данный уровень выключен, поведение Microsoft SQL Server 2005 при выключенном режиме соответсвует предыдущим версиям. Однако, данный механизм работает и в режиме совместимости (т.е. при работе базы с типом 80 на Microsoft SQL Server 2005).


Часто задаваемый вопрос: "А поможет ли включение READ_COMMITED_SHAPSHOT для Microsoft Dynamics Ax 3.0"? Вообще-то, версия 3.0 не поддерживает Read Committed Snapshot Isolation (RCSI) в Microsoft SQL Server 2005.

В заключение. Если код написан неоптимально, транзакция длится часами, то, чтобы не оптимизировал и не предлагал вендор со стороны ядра - большого выигрыша не достичь. Пишите оптимальный код, следите за селективностью создаваемых индексов...


Источник: http://blogs.msdn.com/aeremenk/archi...15/666245.aspx