Всем привет!
Хочу совета у коллективного разума - особенно у тех, кто использует
фичу fbtrace в 2.5.
Сразу оговорюсь, что потери производительности меня в настоящий момент
не интересуют вообще - мне просто надо понять, что бы такое подкрутить
в большой и толстой системе - т.е. найти самые долгоиграющие места,
которые на реальных данных появляются на, казалось бы, ровном месте.
Насколько я понял документацию (FB 2.5 RN jn 22.07.2009), есть 2 варианта
трассирования и аудита - системный и пользовательский. Системный мне и
нужен, так как мне надо включить трассирование всего и вся, помучать
систему, а потом разбираться, что там и как.
Для этого я прописал значение соответствующей переменной в
firebird.conf
AuditTraceConfigFile = fbtrace.conf
а в самом fbtrace.conf были модифицированы нужные переменные
(комментарии я грохнул для читабельности):
<database>
enabled true
log_filename e:\\fbtrace.log
max_log_size 0
include_filter %(INSERT|UPDATE|DELETE|SELECT)%
log_connections true
connection_id 0
log_transactions true
log_statement_prepare true
log_statement_free false
log_statement_start true
log_statement_finish true
log_procedure_start true
log_procedure_finish true
log_trigger_start true
log_trigger_finish true
print_plan true
print_perf true
log_blr_requests false
print_blr false
log_dyn_requests false
print_dyn false
time_threshold 0
# Maximum length of SQL string logged
# Beware when adjusting max_xxx parameters! Maximum length of log record
# for one event should never exceed 64K.
max_sql_length 1024
# Maximum length of blr request logged
max_blr_length 500
# Maximum length of dyn request logged
max_dyn_length 500
# Maximum length of individual string argument we log
max_arg_length 80
# Maximum number of query arguments to put in log
max_arg_count 30
</database>
--
Best regards,
Sergey mailto:[email protected]
