Mark BarinsteinПеред накладыванием S строчной блокировки всегда накладывается IS табличная блокировка (на соотв. таблицу, если ещё её не было), и это не эскалация блокировок.
Она несовместима с X и Z табличными блокировками, и это - её единственный side effect, так сказать...Спасибо. Но тем не менее эскалации возникают. И связаны с процентом блокировок. Возможно, не с S строчными блокировками.
mustaccioДумаю, что в вашей ситуации ("Записей не много - до 50 тыс. в каждой из таблиц. Нагрузка на базу не большая. Добавляется или изменяется около 50-100 записей в день. Пользователей - 20") тратить на это время и силы не стоит. Если на сервере достаточно памяти, индексы прекрасно уживутся в одном пространстве с данными.Спасибо. Последуем Вашему совету.
mustaccioВам надо бояться сканирования таблиц (relation scan) и полного чтения индексов, потому что именно они вызывают эскалацию и таймауты.
Вот это, думаю, уже ближе к моей ситуации. Запустил мониторинг базы со всеми ключами(switches) и сбросил все его счетчики. Через полчаса сделал snapshot и нашел в нем следующее:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
Application Snapshot
Application handle = 242
Application status = UOW Waiting
Status change time = 02.03.2009 14:36:58.865976
Application code page = 1208
Application country/region code = 0
DUOW correlation token = GA0700FC.J784.090302062404
Application name = db2jcc_application
Application ID = GA0700FC.J784.090302062404
Sequence number = 3236
TP Monitor client user ID = guest
TP Monitor client workstation name = l0070003.007.pfr.ru
TP Monitor client application name =
TP Monitor client accounting string =
Connection request start timestamp = 02.03.2009 09:24:04.045132
Connect request completion timestamp = 02.03.2009 09:24:04.045489
Application idle time = 7 seconds
CONNECT Authorization ID = GUEST
Client login ID = GUEST
Configuration NNAME of client = l0070003.007.pfr.r
Client database manager product ID = JCC02100
Process ID of client application = 0
Platform of client application = Unknown via DRDA
Communication protocol of client = TCP/IP
Inbound communication address = 10.7.0.252 14212
Database name = PENSTRAN
Database path = /home/db2inst/penstran/db/db2inst/NODE0000/SQL00001/
Client database alias = PENSTRAN
Input database alias = PENSTRAN
Last reset timestamp = 02.03.2009 13:23:49.684004
Snapshot timestamp = 02.03.2009 14:37:05.638098
The highest authority level granted =
Direct CONNECT authority
Indirect CREATETAB authority
Indirect BINDADD authority
Indirect CONNECT authority
Indirect IMPLICIT_SCHEMA authority
Coordinating database partition number = 0
Current database partition number = 0
Coordinator agent process or thread ID = 16677
Agents stolen = 0
Agents waiting on locks = 0
Maximum associated agents = 1
Priority at which application agents work = 0
Priority type = Dynamic
Lock timeout (seconds) = 30
Locks held by application = 24999
Lock waits since connect = 0
Time application waited on locks (ms) = 0
Deadlocks detected = 0
Lock escalations = 1
Exclusive lock escalations = 0
Number of Lock Timeouts since connected = 0
Total time UOW waited on locks (ms) = 0
Total sorts = 4
Total sort time (ms) = 39
Total sort overflows = 1
Data pages copied to extended storage = 0
Index pages copied to extended storage = 0
Data pages copied from extended storage = 0
Index pages copied from extended storage = 0
Buffer pool data logical reads = 199113
Buffer pool data physical reads = 0
Buffer pool temporary data logical reads = 199
Buffer pool temporary data physical reads = 0
Buffer pool data writes = 0
Buffer pool index logical reads = 172
Buffer pool index physical reads = 1
Buffer pool temporary index logical reads = 0
Buffer pool temporary index physical reads = 0
Buffer pool index writes = 0
Total buffer pool read time (milliseconds) = 20
Total buffer pool write time (milliseconds)= 0
Time waited for prefetch (ms) = 0
Unread prefetch pages = 0
Direct reads = 14
Direct writes = 0
Direct read requests = 7
Direct write requests = 0
Direct reads elapsed time (ms) = 85
Direct write elapsed time (ms) = 0
Number of SQL requests since last commit = 2
Commit statements = 221
Rollback statements = 0
Dynamic SQL statements attempted = 241
Static SQL statements attempted = 221
Failed statement operations = 0
Select SQL statements executed = 223
Update/Insert/Delete statements executed = 4
DDL statements executed = 0
Inactive stmt history memory usage (bytes) = 0
Internal automatic rebinds = 0
Internal rows deleted = 0
Internal rows inserted = 0
Internal rows updated = 0
Internal commits = 0
Internal rollbacks = 0
Internal rollbacks due to deadlock = 0
Binds/precompiles attempted = 0
Rows deleted = 0
Rows inserted = 3
Rows updated = 1
Rows selected = 324
Rows read = 3324284
Rows written = 24625
Мне интересны результаты в строках
Locks held by application ,
Lock escalations ,
Rows written . Последний вообще удивляет. Так должно быть?
И еще. В скриптах приложения часто используются конструкции
select count(*) ... . Слышал, что такие скрипты всегда сканируют таблицу. Может они создают эскалацию?
