Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Firebird, InterBase Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3 4 5 6 7 8 9   вперед  Ctrl      все
 fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
Появилось еще несколько вопросов по юзанию fbtracemgr. Они не связаны друг с другом и какие-то "мелкие", частично это wishlist. Нет смысла на каждый заводить отдельный топег, поэтому пусть будут сгруппированы в одном месте.

1. При последовательных запусках под win-2000 каждая новая сессия получает номер, на единицу больше предыдущей (завершённой по ctrl-C):
+
C:\1INSTALL\FIREBIRD\FB_2_5\bin>fbtracemgr -se localhost:service_mgr -start -config ..\fbtrace_probe01.conf
Trace session ID 1 started

C:\1INSTALL\FIREBIRD\FB_2_5\bin>fbtracemgr -se localhost:service_mgr -start -config ..\fbtrace_probe01.conf
Trace session ID 2 started

C:\1INSTALL\FIREBIRD\FB_2_5\bin>fbtracemgr -se localhost:service_mgr -start -config ..\fbtrace_probe01.conf
Trace session ID 3 started
В тоже время в линухе номер будет на единицу больше только в случае, если к базе есть коннект. Если коннектов нет, то новая сессия на линухе получает снова номер = 1. Это так и было задумано ?

2. Можно ли добавить параметр в conf, заставляющий трейс писать сообщения в лог и формирующий имя этого лога автоматически (например, по принципу database_name.session_ID.yyyymmdd_hh_mi_ss) ?

3. Если включены log_statement_finish true и print_perf true, то по каким принципам выводятся в статистику системные таблицы (помимо тех, что задействованы в самом DML) ?
Например, есть таблица с двумя записями:
recreate table tmpfixed(id int, f01 int) 
Выполняю ISQL-коннект, далее делаю два раза подряд
select * from tmpfixed;
Вижу в консоли fbtracemgr:
* для первого селекта:

Statement 596:
------------------------------------------------------
select * from tmpfixed
2 records fetched
0 ms, 15 fetch(es)

Table Natural Index
RDB$CHARACTER_SETS 1

RDB$COLLATIONS 1


TMPFIXED 2

* для второго селекта:
Statement 598:
----------------------------------------------------
select * from tmpfixed
2 records fetched
0 ms, 7 fetch(es)

Table Natural Index
TMPFIXED 2

PS. Получено при следующем содержимом трейс_конфига:
<database %[\\/](employee|idx_under_load_test).FDB>
enabled true
max_log_size 1
log_transactions true
log_statement_finish true
print_perf true
time_threshold 0
</database>

4. При включенном log_transactions в лог трейса попадут ВСЕ старты и завершения транзакций, в том числе и read only read committed. Можно ли добавить параметр, по которому будут отслеживаться только rollback'и (да и то не всех трн, а лишь тех, что длились свыше указанного в настройках порога, a`la time_threshold для продолжительности стейтментов) ?

5. Можно ли НЕ логгировать все DML к GTT, но логгировать к fixed-таблицам ?

6. Можно ли добавить bool-параметр, при котором в случае переполнения вместо создания новых логов будет просто обнуляться и заполняться заново текущий (он же и единственный) лог ?
24 мар 11, 00:19    [10416513]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Гаджимурадов Рустам
Member

Откуда:
Сообщений: 57325

Таблоид> Это так и было задумано ?

По идее нет, но ничем нехорошим это не грозит.

Таблоид> 2. Можно ли добавить параметр в conf, заставляющий трейс писать
Таблоид> сообщения в лог и формирующий имя этого лога автоматически

Лично я не понял. Это уже есть сейчас и для аудита,
и для трассировки - можно как самостоятельно
(через сервисы) писать в файл, так и просто
перенаправить вывод консоли в файл (твой случай).

Или ты что-то другое хочешь?

Таблоид> 5. Можно ли НЕ логгировать все DML к GTT, но логгировать к fixed-таблицам ?

Юзай инклуд фильтр. Желать фильтр на тип таблиц
(кто-то отдельно внешние таблицы захочет обязательно,
кому-то вьюхи отдельно понадобятся и т.д.) глупо,
ибо фильтр пишется один раз, руки не отсохнут. Да и
сама необходимость log_temporary_tables неочевидна.

Таблоид> 6. Можно ли добавить bool-параметр, при котором
Таблоид> в случае переполнения вместо создания новых логов
Таблоид> будет просто обнуляться и заполняться заново текущий
Таблоид> (он же и единственный) лог ?

А это вообще смешно, ей Богу. Расстреляют же ведь и за дело.
Тебе место на диске жалко или в чем проблема? :-)

Posted via ActualForum NNTP Server 1.4

24 мар 11, 01:11    [10416568]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
hvlad
Member

Откуда:
Сообщений: 9234
Таблоид
1. При последовательных запусках под win-2000 каждая новая сессия получает номер, на единицу больше предыдущей (завершённой по ctrl-C):
...
В тоже время в линухе номер будет на единицу больше только в случае, если к базе есть коннект. Если коннектов нет, то новая сессия на линухе получает снова номер = 1. Это так и было задумано ?
Ты не внимателен. На линуксе у тебя CS и кроме тебя нет других коннектов.
А на win-2000 или не CS, или есть другие коннекты во время твоих экспериментов.

Нумерация трейс сессий начинается заново тогда, когда "стартует сервер".
Для SS\SC "старт сервера" это первый коннект после запуска процесса, "стоп сервера" - это завершение процесса.
Для CS нет единого процесса, поэтому "старт сервера" == первый коннект, "стоп сервера" == полный дисконнект.

В любом случае, нумерация сессий не должна тебя особо волновать. Она нужна больше для оперативной работы со списком сессий администратору.

Таблоид
2. Можно ли добавить параметр в conf, заставляющий трейс писать сообщения в лог и формирующий имя этого лога автоматически (например, по принципу database_name.session_ID.yyyymmdd_hh_mi_ss) ?
Такой параметр уже есть. Для аудита.
Если ты хочешь его для пользовательского трейса, то учти, что конфигурацию интерпретирует только трейс-плагин и сам ответь почему не возможно задавать имя файла лога на клиенте в конфигурации трейса.

Таблоид
3. Если включены log_statement_finish true и print_perf true, то по каким принципам выводятся в статистику системные таблицы (помимо тех, что задействованы в самом DML) ?
По простым. Что было задействованно при выполнении запроса, то и выводится.

Таблоид
4. При включенном log_transactions в лог трейса попадут ВСЕ старты и завершения транзакций, в том числе и read only read committed. Можно ли добавить параметр, по которому будут отслеживаться только rollback'и (да и то не всех трн, а лишь тех, что длились свыше указанного в настройках порога, a`la time_threshold для продолжительности стейтментов) ?
В принципе - можно.

Таблоид
5. Можно ли НЕ логгировать все DML к GTT, но логгировать к fixed-таблицам ?
Про фильтры тебе уже сказали.

Таблоид
6. Можно ли добавить bool-параметр, при котором в случае переполнения вместо создания новых логов будет просто обнуляться и заполняться заново текущий (он же и единственный) лог ?
См. ответ на вопрос 2 и сам скажи, почему этот вопрос бессмысленен.
24 мар 11, 02:01    [10416601]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
Еще пожелание. Можно ли заменить двойные переводы строк в логе трейса одинарными CR/LF, а также убрать отчеркивающие линии (звездочки, черточки) ?
26 мар 11, 16:08    [10427434]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
Пример статистики в fbtrace:
select count(*) from zzz$tmp
1 records fetched
1692 ms, 20429 read(s), 874 write(s), 2040838 fetch(es)

По сравнению с ISQL, не хватает инфы по buffers. Нельзя ли добавить, чтобы не вспоминать это через gstat -h или fb.conf ?

Кроме того, в одном из тестов было выявлено заметное (30%!) влияние FileSystemCacheThreshold на время выполнения "тяжелого запроса". Это был тот самый тест на сравнение скорости джойна трёх таблиц в ФБ и в m$ sql, который тут недавно обсуждался. Можно ли FileSystemCacheThreshold тоже выводить в трейсе ?
26 мар 11, 20:25    [10428074]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
hvlad
Member

Откуда:
Сообщений: 9234
Таблоид,

autoexec.bat не нужно выводить в трейсе ?
26 мар 11, 20:36    [10428106]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
hvlad,

зачем тогда в ISQL стали выводить buffers ? не выводили бы вообще - не было бы вопроса.
Хочется удобный вывод, чтобы всё было видно сразу, без лишних телодвижений.
26 мар 11, 20:52    [10428148]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Гаджимурадов Рустам
Member

Откуда:
Сообщений: 57325

Таблоид> Хочется удобный вывод, чтобы всё было видно сразу, без лишних телодвижений.

Фигней не майся. В трейс нужно выводить то, что имеет прямое отношение к самому событию.
Параметры конфига, как ты сам можешь догадаться, к нему отношения не имеют.

Posted via ActualForum NNTP Server 1.4

26 мар 11, 21:41    [10428260]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
Еще вопрос + пожелание.

1) есть некая база (допустим, 192.168.0.1:/var/db/firebird/my_prod.fdb). есть также алиас к этой базе (у него имя = my_prod). Львиная доля ярлыков на рабочих местах усеров настроена так, что обращение к этой базе идет через алиас, т.е. "192.168.0.1:my_prod". Разработчики же стучатся к ней методом явного указания пути и файла.
Так вот: надо указать в трейс-конфиге, чтобы при старте польз. сессии он отлавливал обращения как к файлу, так и к алиасу.
Попробовал так:
<database %[\\/](my_prod.fdb|my_prod)>
    enabled true
    log_connections true
    log_transactions true
...
</database>
- не получается, обращения к базе через алиас НЕ отлавливаются.
Пробовал еще вот так:
<database %[\\/]my_prod[.fdb]%>
...
- не перехватывается вообще ничего.

ВОПРОС. Как правильно указывать (перечислять) в секции <database> имя файла и его алиаса ?

2) идёт сессия, вывод направлен на экран. Часто желательно очистить экран, чтобы легче было отследить начало некоего "важного события", без выхода из трейса и выполнения cls с повторным запуском. Можно ли добавить некий "хоткей" для этого ?
30 мар 11, 01:16    [10442920]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
Таблоид
4. При включенном log_transactions в лог трейса попадут ВСЕ старты и завершения транзакций, в том числе и read only read committed. Можно ли добавить параметр, по которому будут отслеживаться только rollback'и (да и то не всех трн, а лишь тех, что длились свыше указанного в настройках порога, a`la time_threshold для продолжительности стейтментов) ?
Алаверды к этому пункту (см стартовый пост). Можно ли фильтровать транзакции еще и по уровням изолированности и типам ? (к примеру, exclude read only read committed или include read write concurrency).
+
Открыл только что трейс нашего продакшена, установив временно дефолтную database-секцию в .conf'e, и вижу "нечто": каждую секунду от аттачей (с невыключенных компов) создается и коммитится по 2-3 транзакции, все они read only read committed. Что это такое, еще буду выяснять. Но поскольку они не влияют на OIT - зачем они мне в логе ?
30 мар 11, 01:24    [10442927]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
hvlad
Member

Откуда:
Сообщений: 9234
Таблоид
ВОПРОС. Как правильно указывать (перечислять) в секции <database> имя файла и его алиаса ?
Проверяй свой шаблон, используя SIMILAR TO
30 мар 11, 02:55    [10442983]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
hvlad
Member

Откуда:
Сообщений: 9234
Таблоид
Можно ли добавить некий "хоткей" для этого ?
Нет.
fbtracemgr - тупая консольная утилита ибо таковой задумана и останется.
Хотите сервиса - пользуйтесь другими утилитами. В том же ИБЕ есть базовая поддержка трассировки.
30 мар 11, 02:57    [10442984]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
hvlad,

еще вопрос (может, он и не по fbtracemgr, не знаю).
Начинаю отслеживать что-то с выводом лога в файл, работа идёт под win-2000.
Файл просматриваю в третьем окне.
Вижу, что содержимое файла "отстаёт" от того, что реально должно быть, примерно на 3...4 Кб.
Например, после завершения вот этих команд:
isql -n idx_under_test.fdb
Database: IDX_UNDER_LOAD_TEST.FDB
SQL> select 1 from rdb$database;

CONSTANT
============
1

SQL> commit;
SQL> recreate global temporary table tmp$xxx(id int); commit;
SQL> insert into tmp$xxx values(1); commit;
SQL> exit;
- в файле окажется далеко не всё. Остальное сбросится на диск только при закрытии сессии.
Вот "хвост" того, что вижу в логе:
+
-------------------------------------------------------------------------------

recreate global temporary table tmp$xxx(id int)

0 records fetched

0 ms



2011-03-30T09:01:21.4680 (428:01FDC274) COMMIT_TRANSACTION

C:\1INSTALL\FIREBIRD\DATA\IDX_TEST\IDX_UNDER_LOAD_TEST.FDB (ATT_121, SYSDBA:NONE, NONE, XNET:BALAHA)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1380

(TRA_2341, CONCURRENCY | WAIT | READ_WRITE)

193 ms, 7 read(s), 26 write(s), 193 fetch(es), 21 mark(s)



2011-03-30T09:01:40.2650 (428:01FDC274) START_TRANSACTION

C:\1INSTALL\FIREBIRD\DATA\IDX_TEST\IDX_UNDER_LOAD_TEST.FDB (ATT_121, SYSDBA:NONE, NONE, XNET:BALAHA)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1380

(TRA_2342, CONCURRENCY | WAIT | READ_WRITE)



2011-03-30T09:01:40.2650 (428:01FDC274) EXECUTE_STATEMENT_START

C:\1INSTALL\FIREBIRD\DATA\IDX_TEST\IDX_UNDER_LOAD_TEST.FDB (ATT_121, SYSDBA:NONE,
А вот что оказалось возможным увидеть только после завершения сессии:
+
Statement 116:

-------------------------------------------------------------------------------

insert into tmp$xxx values(1)



2011-03-30T09:01:40.2960 (428:01FDC274) EXECUTE_STATEMENT_FINISH

C:\1INSTALL\FIREBIRD\DATA\IDX_TEST\IDX_UNDER_LOAD_TEST.FDB (ATT_121, SYSDBA:NONE, NONE, XNET:BALAHA)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1380

(TRA_2342, CONCURRENCY | WAIT | READ_WRITE)



Statement 116:

-------------------------------------------------------------------------------

insert into tmp$xxx values(1)

0 records fetched

24 ms, 3 write(s), 16 fetch(es), 13 mark(s)



Table Natural Index Update Insert Delete Backout Purge Expunge

***************************************************************************************************************

TMP$XXX 1



2011-03-30T09:01:40.3430 (428:01FDC274) COMMIT_TRANSACTION

C:\1INSTALL\FIREBIRD\DATA\IDX_TEST\IDX_UNDER_LOAD_TEST.FDB (ATT_121, SYSDBA:NONE, NONE, XNET:BALAHA)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1380

(TRA_2342, CONCURRENCY | WAIT | READ_WRITE)

52 ms, 1 read(s), 5 write(s), 1 fetch(es), 1 mark(s)



2011-03-30T09:01:43.3590 (428:01FDC274) DETACH_DATABASE

C:\1INSTALL\FIREBIRD\DATA\IDX_TEST\IDX_UNDER_LOAD_TEST.FDB (ATT_121, SYSDBA:NONE, NONE, XNET:BALAHA)

C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1380



2011-03-30T09:01:43.3590 (428:01FDC274) TRACE_FINI

SESSION_1

ВОПРОС-1. Как сделать, чтобы лог сразу сбрасывался на диск ? Если в реестре винды надо что-то подкрутить, то в где ?
ВОПРОС-2. Возможен ли "параллельный" вывод сообщений на консоль и в файл ?
30 мар 11, 09:09    [10443227]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
hvlad
Member

Откуда:
Сообщений: 9234
Таблоид
ВОПРОС-1. Как сделать, чтобы лог сразу сбрасывался на диск ? Если в реестре винды надо что-то подкрутить, то в где ?
CORE-3324
Таблоид
ВОПРОС-2. Возможен ли "параллельный" вывод сообщений на консоль и в файл ?
У нас вроде нет утилит с таким функционалом ? В принципе - возможно, но сейчас точно не до того.
30 мар 11, 11:38    [10444164]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 43650

hvlad
У нас вроде нет утилит с таким функционалом ? В принципе - возможно, но сейчас точно не до
того.

А что, обязательно должны быть "наши" аналоги всех стандартных утилит? Для тех идиотов,
которые неспособны воспользоваться tee/WinTee?..

Posted via ActualForum NNTP Server 1.4

30 мар 11, 11:47    [10444247]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
LI-V6.3.0.26084 Firebird 2.5, Classic.

Есть в firebird.conf такой параметр: MaxUserTraceLogSize, default = 10 Mb.
В комментариях указано, что при превышении логом этого размера трейс будет приостановлен до "прочтения интерактивным сервисом пользователя и удаления некоторых лог-файлов".
Я его установил равным 1, после чего включил трейс.
Лог быстро достиг размера 1 Мб и прёт дальше, никакой остановки нет.

2 hvlad: можно ли всё-таки подправить трейс, чтобы он по достижении пользовательским логом размера, который указан в MaxUserTraceLogSize, не останавливался, а переименовывал добавлением суффикса в формате yyyymmdd_hhmmss, после чего открывал новый файл и возобновлял в него запись новых данных ?

PS. Объясню причину этой паранойи: мне нужно найти sql-операторы, которые выполнялись в OIT. У нас какая-то странная картина: то по 5-10 дней OAT-OIT=1, то вдруг совершенно дикие разницы по полтора-два миллиона, с утра и до ночного пылесоса.
Причем, "набор высоты" происходит за каких-то 1-2 часа. Откуда могут у нас быть по 400-500 транзакций в СЕКУНДУ - пока не ведаю. Разработчики божатся, что никакие пакетные операции не выдают транзакции с такой частотой.
Чтобы найти эти операторы, надо логгировать долго и много. Чтобы не загадить диск, хочу добавить в крон задание на упаковку "суффиксных логов" и отправку их мне в почту, с последующим удалением. Как только увижу "дикий зазор", буду поднимать архивы логов.
1 апр 11, 00:05    [10454570]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
hvlad
Member

Откуда:
Сообщений: 9234
Таблоид
LI-V6.3.0.26084 Firebird 2.5, Classic.

Есть в firebird.conf такой параметр: MaxUserTraceLogSize, default = 10 Mb.
В комментариях указано, что при превышении логом этого размера трейс будет приостановлен до "прочтения интерактивным сервисом пользователя и удаления некоторых лог-файлов".
Я его установил равным 1, после чего включил трейс.
Лог быстро достиг размера 1 Мб и прёт дальше, никакой остановки нет.
Это касается временных файлов, создаваемых сервером для ещё не прочитанной юзером инф-ции.
Никакого отношения к файлам на клиенте оно не имеет.

Таблоид
2 hvlad: можно ли всё-таки подправить трейс, чтобы он по достижении пользовательским логом размера, который указан в MaxUserTraceLogSize, не останавливался, а переименовывал добавлением суффикса в формате yyyymmdd_hhmmss, после чего открывал новый файл и возобновлял в него запись новых данных ?
Нет.

Таблоид
PS. Объясню причину этой паранойи: мне нужно найти sql-операторы, которые выполнялись в OIT. У нас какая-то странная картина: то по 5-10 дней OAT-OIT=1, то вдруг совершенно дикие разницы по полтора-два миллиона, с утра и до ночного пылесоса.
Это у тебя OAT застрял и стоит на месте. Next в это время движется вперёд.

Таблоид
Причем, "набор высоты" происходит за каких-то 1-2 часа. Откуда могут у нас быть по 400-500 транзакций в СЕКУНДУ - пока не ведаю. Разработчики божатся, что никакие пакетные операции не выдают транзакции с такой частотой.
Чтобы найти эти операторы, надо логгировать долго и много.
А потом OAT таки завершается и её новое значение становится намного больше застрявшего OIT.

Таблоид
Чтобы не загадить диск, хочу добавить в крон задание на упаковку "суффиксных логов" и отправку их мне в почту, с последующим удалением. Как только увижу "дикий зазор", буду поднимать архивы логов.
Тебе нужен аудит. Он как раз имеет такие настройки.
См. log_filename и max_log_size в fbtrace.conf и AuditTraceConfigFile в firebird.conf
1 апр 11, 00:16    [10454586]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
hvlad
Тебе нужен аудит. Он как раз имеет такие настройки.
См. log_filename и max_log_size в fbtrace.conf и AuditTraceConfigFile в firebird.conf
А вот в релнотах сказано:
FB 2.5 RN
Administrator creates or edits the trace configuration file, sets its name via the AuditTraceConfigFile setting in firebird.conf and restarts Firebird. Later, the administrator could suspend, resume or stop this session without needing to restart Firebird.
правильно ли понимаю, что для случая CLASSIC server'a достаточно просто выгнать всех усеров из проги, т.е. просто сделать gfix -shut и затем -online &
1 апр 11, 00:32    [10454606]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
hvlad
Member

Откуда:
Сообщений: 9234
Таблоид
правильно ли понимаю, что для случая CLASSIC server'a достаточно просто выгнать всех усеров из проги
Да.
1 апр 11, 00:34    [10454611]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
Операторы, выполняемые внутри автономных транзакций, в логе трейса не показываются:
DDL:
+
set term ^;
execute block as
  declare ddl varchar(32760);
  declare n int = 100;
  declare i int;
begin
  ddl='recreate table wide(';
  while (n>0) do begin
    ddl = ddl || 'f'||n||' int default 0' || iif(n>1, ',', ');');
    n=n-1;
  end
  execute statement :ddl;
end^
set term ;^
commit;
EB:
rollback;
set transaction read write read committed;
set term ^;
execute block as
declare k int = 3;
begin
  while (k>0) do begin
     in autonomous transaction do begin
        insert into wide default values;
        delete from wide;
     end
     k=k-1;
  end
end^
set term ;^
rollback;
Trace log:
+
2011-04-08T23:37:59.5150 (428:020DB9D0) TRACE_INIT
SESSION_1 Firebird Audit


2011-04-08T23:37:59.5150 (428:020DB9D0) ATTACH_DATABASE
C:\1INSTALL\FIREBIRD\DATA\TEST.FDB (ATT_10, SYSDBA:NONE, NONE, XNET:BALAHA)
C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1204

2011-04-08T23:37:59.5150 (428:020DB9D0) START_TRANSACTION
C:\1INSTALL\FIREBIRD\DATA\TEST.FDB (ATT_10, SYSDBA:NONE, NONE, XNET:BALAHA)
C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1204
(TRA_34226, CONCURRENCY | WAIT | READ_WRITE)

2011-04-08T23:38:02.8590 (428:020DB9D0) ROLLBACK_TRANSACTION
C:\1INSTALL\FIREBIRD\DATA\TEST.FDB (ATT_10, SYSDBA:NONE, NONE, XNET:BALAHA)
C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1204
(TRA_34226, CONCURRENCY | WAIT | READ_WRITE)
0 ms, 1 read(s), 1 write(s), 1 fetch(es), 1 mark(s)

2011-04-08T23:38:02.8590 (428:020DB9D0) START_TRANSACTION
C:\1INSTALL\FIREBIRD\DATA\TEST.FDB (ATT_10, SYSDBA:NONE, NONE, XNET:BALAHA)
C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1204
(TRA_34227, READ_COMMITTED | NO_REC_VERSION | WAIT | READ_WRITE)

2011-04-08T23:38:02.8590 (428:020DB9D0) START_TRANSACTION
C:\1INSTALL\FIREBIRD\DATA\TEST.FDB (ATT_10, SYSDBA:NONE, NONE, XNET:BALAHA)
C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1204
(TRA_34228, READ_COMMITTED | NO_REC_VERSION | WAIT | READ_WRITE)

2011-04-08T23:38:02.8590 (428:020DB9D0) COMMIT_TRANSACTION
C:\1INSTALL\FIREBIRD\DATA\TEST.FDB (ATT_10, SYSDBA:NONE, NONE, XNET:BALAHA)
C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1204
(TRA_34228, READ_COMMITTED | NO_REC_VERSION | WAIT | READ_WRITE)
0 ms, 1 read(s), 2 write(s), 1 fetch(es), 1 mark(s)

2011-04-08T23:38:02.8590 (428:020DB9D0) START_TRANSACTION
C:\1INSTALL\FIREBIRD\DATA\TEST.FDB (ATT_10, SYSDBA:NONE, NONE, XNET:BALAHA)
C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1204
(TRA_34229, READ_COMMITTED | NO_REC_VERSION | WAIT | READ_WRITE)

2011-04-08T23:38:02.8590 (428:020DB9D0) COMMIT_TRANSACTION
C:\1INSTALL\FIREBIRD\DATA\TEST.FDB (ATT_10, SYSDBA:NONE, NONE, XNET:BALAHA)
C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1204
(TRA_34229, READ_COMMITTED | NO_REC_VERSION | WAIT | READ_WRITE)
0 ms, 1 read(s), 2 write(s), 1 fetch(es), 1 mark(s)

2011-04-08T23:38:02.8590 (428:020DB9D0) START_TRANSACTION
C:\1INSTALL\FIREBIRD\DATA\TEST.FDB (ATT_10, SYSDBA:NONE, NONE, XNET:BALAHA)
C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1204
(TRA_34230, READ_COMMITTED | NO_REC_VERSION | WAIT | READ_WRITE)

2011-04-08T23:38:02.8590 (428:020DB9D0) COMMIT_TRANSACTION
C:\1INSTALL\FIREBIRD\DATA\TEST.FDB (ATT_10, SYSDBA:NONE, NONE, XNET:BALAHA)
C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1204
(TRA_34230, READ_COMMITTED | NO_REC_VERSION | WAIT | READ_WRITE)
0 ms, 1 read(s), 2 write(s), 1 fetch(es), 1 mark(s)

2011-04-08T23:38:02.8590 (428:020DB9D0) EXECUTE_STATEMENT_FINISH
C:\1INSTALL\FIREBIRD\DATA\TEST.FDB (ATT_10, SYSDBA:NONE, NONE, XNET:BALAHA)
C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1204
(TRA_34227, READ_COMMITTED | NO_REC_VERSION | WAIT | READ_WRITE)

Statement 35:
-------------------------------------------------------------------------------
execute block as
declare k int = 3;
begin
while (k>0) do begin
in autonomous transaction do begin
insert into wide default values;
delete from wide;
end
k=k-1;
end
end
0 records fetched
0 ms, 4 read(s), 3 write(s), 60 fetch(es), 13 mark(s)

Table Natural Index Update Insert Delete Backout Purge Expunge
***************************************************************************************************************
WIDE 3 3 3 2

2011-04-08T23:38:02.8590 (428:020DB9D0) ROLLBACK_TRANSACTION
C:\1INSTALL\FIREBIRD\DATA\TEST.FDB (ATT_10, SYSDBA:NONE, NONE, XNET:BALAHA)
C:\1INSTALL\FIREBIRD\FB_2_5\bin\isql.exe:1204
(TRA_34227, READ_COMMITTED | NO_REC_VERSION | WAIT | READ_WRITE)
0 ms, 1 read(s), 1 write(s), 1 fetch(es), 1 mark(s)
(видно, что после старта основной трн стартуют и тут же коммитятся автономки; текста и данных по производительности выполняемых внутри них операторов не видно).
8 апр 11, 23:39    [10494307]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
hvlad
Member

Откуда:
Сообщений: 9234
Таблоид
Операторы, выполняемые внутри автономных транзакций, в логе трейса не показываются
Ну так и отдельные операторы внутри процедуры\триггера тоже не показываются
9 апр 11, 01:13    [10494648]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
LI-V6.3.0.26083 (Classic)

Из таблицы, содержащей 100 млн строк и 5 индексов (один ПК и 4 составных по 4 int-полям) выполняю удаление 1 млн строк.
Подключен пользовательский трейс, вывод перенаправлен в лог.
Удаление идёт больше минуты, при этом ВСЁ это время вижу в top'e, что fbtracemgr ощутимо грузит проц:

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
29299 firebird 20 0 128m 6772 4576 S 46.5 0.0 0:51.11 fbtracemgr
29308 firebird 20 0 104m 45m 5352 R 38.2 0.1 0:22.75 isql

Самое интересное, что:
1) в процессе выполнения в top'e (при сортировке по CPU_load desc)в первых строках видел fbtracemgr и isql - "моего" fb_inet_server'a там даже не показалось;
2) эта же загрузка (примерно 45-47%) не прекратилась и после того, как оператор удаления выполнился и в ISQL управление вернулось к подсказке.

Это почему так ?
PS. Содержимое конфига трейса:
+
[firebird@firebirdG ~]$ cat fbtrace_probe01.conf
<database %[\\/]test.fdb>
enabled true
#log_filename ./test_trace.log
max_log_size 10
log_connections true
log_transactions true
#include_filter %(SELECT|INSERT|UPDATE|DELETE|MERGE)%
#exclude_filter
#connection_id 12345
#log_statement_prepare true
#log_statement_free true
#log_statement_start true
log_statement_finish true
print_plan true
print_perf true
# max_sql_length 500
time_threshold 0
</database>
12 апр 11, 21:07    [10508898]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
PS. Забыл указать полный список процессов от user = 'firebird', которые вижу в top'e при работе трейса и "долгом запросе" к большой таблице:
+
top - 21:08:56 up 20 days,  8:57,  8 users,  load average: 2.61, 2.15, 1.70
Tasks: 269 total, 4 running, 265 sleeping, 0 stopped, 0 zombie
Cpu0 : 0.3%us, 1.0%sy, 0.0%ni, 78.2%id, 17.2%wa, 0.0%hi, 3.3%si, 0.0%st
Cpu1 : 1.0%us, 2.6%sy, 0.0%ni, 18.6%id, 77.8%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu2 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu3 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu4 : 12.5%us, 48.9%sy, 0.0%ni, 34.6%id, 0.0%wa, 0.0%hi, 3.9%si, 0.0%st
Cpu5 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu6 : 3.3%us, 3.3%sy, 0.0%ni, 92.6%id, 0.3%wa, 0.0%hi, 0.3%si, 0.0%st
Cpu7 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 49548000k total, 32727144k used, 16820856k free, 24324k buffers
Swap: 51367828k total, 20k used, 51367808k free, 29828832k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
29299 firebird 20 0 128m 6772 4576 S 47.2 0.0 5:20.06 fbtracemgr
29308 firebird 20 0 73940 14m 5532 R 3.7 0.0 0:30.03 isql
3623 firebird 20 0 97484 2056 1204 S 0.0 0.0 0:23.88 sshd
3624 firebird 20 0 105m 1844 1400 S 0.0 0.0 0:00.01 bash
3651 firebird 20 0 115m 2904 1884 S 0.0 0.0 0:15.52 mc
3653 firebird 20 0 105m 1868 1404 S 0.0 0.0 0:00.01 bash
8636 firebird 20 0 97484 2060 1204 S 0.0 0.0 0:03.77 sshd
8637 firebird 20 0 105m 1848 1400 S 0.0 0.0 0:00.00 bash
8664 firebird 20 0 115m 2756 1860 S 0.0 0.0 0:00.18 mc
8666 firebird 20 0 105m 1860 1404 S 0.0 0.0 0:00.03 bash
22612 firebird 20 0 97444 2116 1284 S 0.0 0.0 0:00.15 sshd
22613 firebird 20 0 105m 1840 1400 S 0.0 0.0 0:00.00 bash
22640 firebird 20 0 115m 3416 1936 S 0.0 0.0 0:00.10 mc
22642 firebird 20 0 105m 1856 1400 S 0.0 0.0 0:00.00 bash
25702 firebird 20 0 97484 2148 1288 S 0.0 0.0 0:00.21 sshd
25703 firebird 20 0 105m 1840 1400 S 0.0 0.0 0:00.00 bash
25730 firebird 20 0 115m 3068 2016 S 0.0 0.0 0:00.51 mc
25732 firebird 20 0 105m 1860 1404 S 0.0 0.0 0:00.04 bash
25793 firebird 20 0 97484 2148 1288 S 0.0 0.0 0:00.12 sshd
25794 firebird 20 0 105m 1848 1400 S 0.0 0.0 0:00.00 bash
25821 firebird 20 0 115m 3052 2020 S 0.0 0.0 0:00.45 mc
25823 firebird 20 0 105m 1860 1404 S 0.0 0.0 0:00.04 bash
29249 firebird 20 0 135m 10m 5348 S 0.0 0.0 0:06.67 fb_inet_server
29317 firebird 20 0 15076 1340 912 R 0.0 0.0 0:01.50 top
29442 firebird 20 0 97484 2020 1180 S 0.0 0.0 0:00.00 sshd
29443 firebird 20 0 105m 1844 1400 S 0.0 0.0 0:00.00 bash
29470 firebird 20 0 115m 3016 1936 S 0.0 0.0 0:00.11 mc
29472 firebird 20 0 105m 1848 1396 S 0.0 0.0 0:00.00 bash

Прошу обратить внимание на то, что fb_inet_server вообще не грузит ЦПУ и находится явно среди "аутсайдеров".
12 апр 11, 21:13    [10508919]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
hvlad
Member

Откуда:
Сообщений: 9234
Таблоид
LI-V6.3.0.26083 (Classic)

Из таблицы, содержащей 100 млн строк и 5 индексов (один ПК и 4 составных по 4 int-полям) выполняю удаление 1 млн строк.
Подключен пользовательский трейс, вывод перенаправлен в лог.
Удаление идёт больше минуты, при этом ВСЁ это время вижу в top'e, что fbtracemgr ощутимо грузит проц:

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
29299 firebird 20 0 128m 6772 4576 S 46.5 0.0 0:51.11 fbtracemgr
29308 firebird 20 0 104m 45m 5352 R 38.2 0.1 0:22.75 isql

Самое интересное, что:
1) в процессе выполнения в top'e (при сортировке по CPU_load desc)в первых строках видел fbtracemgr и isql - "моего" fb_inet_server'a там даже не показалось;
2) эта же загрузка (примерно 45-47%) не прекратилась и после того, как оператор удаления выполнился и в ISQL управление вернулось к подсказке.
а) В логе трейса только искомое удаление оказалось или куча параллельной активности от других коннектов тоже ?
б) коннект в isql небось локальный ?
12 апр 11, 21:29    [10508982]     Ответить | Цитировать Сообщить модератору
 Re: fbtracemgr: разные мелкие вопросы  [new]
Таблоид
Member

Откуда:
Сообщений: 9454
Блог
hvlad
а) В логе трейса только искомое удаление оказалось или куча параллельной активности от других коннектов тоже ?
б) коннект в isql небось локальный ?
a) только аттач + каунт строк в ИБЭ (т.е. еще всего лишь 1 коннект, который сделал предварительный подсчет числа удаляемых строк).
б) да, локальный... а что? :-)
12 апр 11, 21:34    [10508997]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3 4 5 6 7 8 9   вперед  Ctrl      все
Все форумы / Firebird, InterBase Ответить