Блокировки в базе данных DB2.

Настройка базы данных для снижения нагрузки ввода/вывода поможет справиться с блокировками, однако хранимая процедура new_edit_state все равно может часто блокировать вызывающее приложение и все другие возможности использования базы данных ArcSDE.

Представьте себе ситуацию, когда хранимая процедура получает большое число блокировок строк из таблицы STATE_LINEAGES. При этом превышается ограничение максимального количества блокировок и совершается попытка эскалации до исключительной блокировки таблицы. К сожалению, в запросе вызывающего приложения уже имеется общая блокировка таблицы STATE_LINEAGES, в результате чего происходит полная блокировка. Большое количество блокировок строк связано с глубоким происхождением состояния. При этом низкое значение размера списка блокировок гарантирует возникновение проблем. В зависимости от обработки эскалации блокировок возможны и другие сценарии полной блокировки.

Здесь подразумевается, что полная блокировка может часто происходить в определенных местах, поскольку это зависит от приложений и конфигурации баз данных. Однако необходимо отметить, что проблема может быть усугублена глубоким происхождением состояний.

Однако в IBM DB2 имеются параметры для настройки контроля размера списка блокировок (LOCKLIST), максимальной доли блокировок в приложении (MAXLOCKS), времени ожидания получения блокировки запросом (LOCKTIMEOUT), интервала определения блокировки (DLCHKTIME) и действий при откате при полной блокировке (DB2LOCK_TO_RB).

Для увеличения вместимости списка блокировок и повышения ограничения эскалации блокировок следует соответственно изменить параметры LOCKLIST и MAXLOCKS.

По умолчанию в DB2 9 параметр LOCKLIST и MAXLOCKS имеют значение AUTOMATIC, т.е. они настраиваются автоматически. Это позволяет отладчику памяти DB2 динамически распределять ресурсы памяти между разными потребителями. Автоматическая настройка происходит только тогда, когда в базе данных включена самостоятельная настройка памяти (SELF_TUNING_MEM=ON).

Кроме того, может появиться возможность оптимизации параллельной работы посредством предотвращения блокировок. Для этого используются переменные реестра отсрочки блокировок DB2_EVALUNCOMMITED, DB2_SKIPDELETED и DB2_SKIPINSERTED. Эти переменные реестра допускают выполнение сканирования для безусловного пропуска незаписанных операций удаления и вставки.

По умолчанию по прошествии срока ожидания блокировки происходит откат запрошенной транзакции. Для изменения такого поведения и выполнения отката только выражения, отправляющего запрос на блокировку, необходимо установить для DB2LOCK_TO_RB значение db2set DB2LOCK_TO_RB=STATEMENT. Поведение по умолчанию также должно подходить для ArcSDE.

Подробную информацию о правильной настройке этих параметров можно найти в документации по DB2 и руководствах по отладке производительности. Обзор использования этих параметров приведен ниже.

Диагностика проблем блокировки

Ниже перечислено несколько полезных средств для диагностики проблем блокировки.

• Поиск идентификаторов приложения db2 для процессов SDE.

  SELECT  appl_id 
  FROM  TABLE(SNAPSHOT_APPL_INFO('SDE',-1)) 
  AS SNAPSHOT_APPL_INFO 
  WHERE appl_name LIKE 'gsrvr%'
  
  SELECT  appl_id,appl_name 
  FROM  TABLE(SNAPSHOT_APPL_INFO('SDE',-1))
  

• Использование снимков для получения информации о блокировках и приложении, например:

  db2 get snapshot for locks on sde > all_locks.txt
  
  db2 get snapshot for locks for application applid
  '*LOCAL.DB2.00AB42215335' > app_locks.txt
  
  db2 get snapshot for application applid '*LOCAL.DB2.00AB42215335' > app_info.txt
  

  быстрый поиск интересующих элементов на снимке дает следующее:

  Application status = Lock-wait
   Locks held by application = 1254
   Number of SQL requests since last commit = 12
   Open local cursors = 1
   Most recent operation = Execute
  
   Object type	= Table
   Tablespace name	= USERSPACE1
   Table schema	= SDE
   Table name	= STATE_LINEAGES
   Mode = X
   Status	 = Converting
   Current mode = IX
   Lock escalation	= YES

• Как указывалось выше, глубокое происхождение может быть проблемой при получении большого числа блокировок строк. Следующие выражения SQL позволяют быстро проверить глубину происхождения и максимальную глубину происхождения:

  SELECT COUNT (*) 
  FROM state_lineages 
  GROUP BY lineage_name
  
  SELECT MAX(a.depth) 
  FROM (SELECT COUNT (*) FROM state_lineages GROUP BY lineage_name) a(depth)
  

Параметры, связанные с полными блокировками

Для просмотра параметров списка блокировок используется следующая команда:

db2 get db cfg

Ниже приведен пример информации, выводимой в результате запуска этой команды:

Max storage for lock list (4KB)		(LOCKLIST) = 50
Interval for checking deadlock (ms)	(DLCHKTIME) = 10000
Percent. of lock lists per application	(MAXLOCKS) = 22
Lock time out (sec)			(LOCKTIMEOUT) = -1
Max number of active applications	(MAXAPPLS) = AUTOMATIC

Подробную информацию об установке этих параметров можно получить в информационном центре IBM DB2.