7.6.3. Сколько свободного места имеется у сервера бд

Для того, чтобы узнать, сколько свободного места имеется у конкретного экземпляра сервера базы данных существует команда onstat -d (она уже затрагивалась в разделе про устройство Informix Dynamic Server). Вот типичный листинг, выдаваемый данной утилитой:

> onstat –d INFORMIX-IDS Version 7.11.UC1 - On-Line - Up 17 days 00:24:59 -- 11480 Ks Dbspaces address number flags fchunk nchunks flags owner name a33e0e8 1 1 1 2 N informix rootdbs a36b9c0 2 1 2 1 N informix db1 a36ba28 3 1 3 1 N informix db2 a36ba90 4 1 4 1 N informix db3 a36baf8 5 1 5 1 N informix db4 a36bb60 6 1 7 1 N informix agspace1 6 active, 2047 maximum Chunks address chk/dbs offset size free flags pathname a33e150 1 1 0 32485 256 PO- /data/chunw a36b228 2 2 0 20000 0 PO- /data/chun1 a36b300 3 3 0 20000 6593 PO- /data/chun2 a36b3d8 4 4 0 20000 1053 PO- /data/chun3 a36b4b0 5 5 0 20000 6957 PO- /data/chun4 a36b588 6 1 0 50000 2024 PO- /data/chun10 a36b660 7 6 0 5000 2283 PO- /data/chun5 7 active, 2047 maximum

В листинге данной утилиты, в разделе “Chunks” для каждого чанка в колонке “free” указывается количество КБт, свободных для использования у каждого доступного чанка. Если пространство данных состоит из нескольких чанков, то для того, чтобы узнать сколько свободного места в пространстве, надо просуммировать свободное место для каждого чанка из данного пространства. Так, у пространства rootdbs свободно 2280 (сумма 2024+256) КБт, а у пространства db2 вообще нет свободного места.

7.7. Достижение требуемой производительности

7.7.1. Как узнать, что ждет некоторый запрос

Иногда бывает так, что иногда некоторый запрос выполняется необоснованно долго. Причем, когда проводится специальное тестирование этого запроса, он выполняется быстро. Обычно, подобная ситуация возникает из-за появления блокировки. То есть какой-то другой запрос, поступивший от другого пользователя, заблокировал доступ к информации, которая нужна первому запросу. Подробно правила блокировки рассмотрены в параграфе «Многопользовательский доступ к данным» в разделе про язык SQL. Здесь же мы рассмотрим методику определения того, чьи действия привели к возникновению блокировки.

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

onstat -u

и определить значение поля wait для требуемой сессии. Это поле как раз и является идентификатором объекта, который заблокирован и разблокирование которого ожидается данным запросом. Кстати, поле tout говорит о том, сколько секунд ожидается разблокирование данного запроса. В следующем листинге видно, что запрос пользователя guest ждет освобождение ресурса с идентификатором 831055c0 в течении 13 секунд:

address flags sessid user tty wait tout locks nreads nwrites 83214014 ---P--D 1 informix - 0 0 0 18 13 83214448 ---P--F 0 informix - 0 0 0 0 164 8321487c ---P--B 5 informix - 0 0 0 0 0 83214cb0 L--PR-- 13 guest bibirevo 831055c0 13 1 0 0 832150e4 Y-BP--- 10 andrey taganka 83372a78 0 3 70 18 83215518 ---P--D 8 informix - 0 0 0 0 0 6 active, 128 total, 11 maximum concurrent

Далее, надо определить, кто именно установил данную блокировку. Для этого надо выполнить команду

onstat –k или onstat -s

Команда onstat –k показывает все блокировки, существующие на сервере БД:

Locks address wtlist owner lklist type tblsnum rowid key#/bsiz 83105590 0 832150e4 0 HDR+S 100002 203 0 831055c0 83214cb0 832150e4 83105590 HDR+IX 100080 0 0 831055f0 0 832150e4 831055c0 HDR+X 100080 100 0 83105620 0 83214cb0 0 S 100002 203 0 4 active, 1000 total, 1024 hash buckets

На данном листинге видно, что заблокированный ресурс с идентификатором (колонка lklist) 831055c0 принадлежит пользователю (колонка owner) с идентификатором 832150e4. Колонка owner в команде onstat –k соответствует колонке address, выдаваемой командой onstat –u. Возвращаясь к листингу команды onstat –u видим, что блокировка принадлежит пользователю andrey.

Данная методика основана на анализе листингов стандартных утилит. Такой «ручной» подход не всегда удобен. Для получения аналогичной информации можно воспользоваться и запросом на языке SQL. Дело в том, что вся информация о сессиях и блокировках имеется в системной базе данных sysmaster, в частности, в таблицах syslocks и syssessions. Подробное описание использования данных из этих таблиц имеется в руководстве администратора по Informix Dynamic Server.