Статистика в FB 2.1 CS

Запросы, планы, оптимизация запросов, ...

Модераторы: kdv, CyberMax

Ответить
OX
Сообщения: 24
Зарегистрирован: 26 окт 2004, 17:08

Статистика в FB 2.1 CS

Сообщение OX » 06 июн 2008, 16:38

Я конечно понимаю что пятница, но прошу пояснить почему у gstat и
MON$DATABASE разные значения OIT, OAT, OST и Next?
Последний раз редактировалось OX 06 июн 2008, 16:48, всего редактировалось 1 раз.

hvlad
Разработчик Firebird
Сообщения: 1244
Зарегистрирован: 21 мар 2005, 10:48

Сообщение hvlad » 06 июн 2008, 16:42

gstat читает header page с диска, на момент сбора статистики
MON$ххх - на момент первого выполнения запроса к любой MON$ таблице, и не меняется до окончания тр-ции

Хотя... у тебя запрос выполнен после gstat и значения в нём меньшие...

Другие активные процессы CS есть ?

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Сообщение kdv » 06 июн 2008, 16:45

за постирование картинок в следующий раз будет бан.
тем более что сохранить статистику в тексте и привести ее тут - плевое дело.
и уж совсем - можно было задать вопрос и без примера статистики.

OX
Сообщения: 24
Зарегистрирован: 26 окт 2004, 17:08

Сообщение OX » 06 июн 2008, 17:19

kdv писал(а):за постирование картинок в следующий раз будет бан.
Виноват, исправлюсь :oops:
hvlad извини, с первого раз я не понял :(
1. Стартуем gstat, Next Transaction = 9141;
2. Запускаем isql после gstat.
3. Запрос к MON$DATABASE, с моей (видимо ошибочной) точки зрения это и есть момент первого выполнения запроса к MON$.
4. MON$NEXT_TRANSACTION = 8735.
Тогда что считать первым обращением к MON$?

hvlad
Разработчик Firebird
Сообщения: 1244
Зарегистрирован: 21 мар 2005, 10:48

Сообщение hvlad » 06 июн 2008, 17:51

OX писал(а): hvlad извини, с первого раз я не понял :(
1. Стартуем gstat, Next Transaction = 9141;
2. Запускаем isql после gstat.
3. Запрос к MON$DATABASE, с моей (видимо ошибочной) точки зрения это и есть момент первого выполнения запроса к MON$.
4. MON$NEXT_TRANSACTION = 8735.
Тогда что считать первым обращением к MON$?
Всё правильно у тебя. Пока что. Вроде бы. :)

Другие коннекты есть ? Кроме твоего.
isql при повторном запуске что выдаёт ?

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Сообщение kdv » 06 июн 2008, 18:06

просто вопрос - а зачем isql?

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Сообщение kdv » 06 июн 2008, 18:09

кстати. раз уж смотришь mon$ - так смотри mon$transactions :)

если коннект первый, то совершенно однозначно Next transaction и в gstat и в isql будет примерно одинаков. например у меня сейчас 622 и 628.

OX
Сообщения: 24
Зарегистрирован: 26 окт 2004, 17:08

Сообщение OX » 06 июн 2008, 19:10

hvlad
Другие коннекты есть, isql при повторном запуске выдает то же, что и при первом т.е. 8735.
kdv
isql - для чистоты эксперимента.
c mon$transactions проблем нет, пока нет :) ведь завтра опять пятница.

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Сообщение kdv » 06 июн 2008, 20:33

c mon$transactions проблем нет,
я имел в виду, что mon$transactions должен показать номера транзакций, со всей др. информацией. которая должна соответствовать маркерам в mon$database.

вместо isql попробуй IBExpert или чего-нибудь вроде.

OX
Сообщения: 24
Зарегистрирован: 26 окт 2004, 17:08

Сообщение OX » 06 июн 2008, 23:17

kdv писал(а):
c mon$transactions проблем нет,
я имел в виду, что mon$transactions должен показать номера транзакций, со всей др. информацией. которая должна соответствовать маркерам в mon$database.

вместо isql попробуй IBExpert или чего-нибудь вроде.
Так, рискуя получить в лоб, опишу все подробно. После очередного релиза софта опять застрял ОАТ, обнаружили уже на рабочем объекте, клиентов отключать нельзя, точнее очень проблематично. Что было сделано на объекте:
1. IbExpert, запрос на mon$transaction join на mon$attachments.
2. О чудо, вредители обнаружены, разработчики уже правят код.
3. Закрываем IBExpert, ждем когда прибудет update. пытаемся согласовать перезагрузку софта.
4. С сожалением вспоминаем об отстутствии
- IBTM;
- IbAnalyst;
- IbReplicator;
Которые некто отказывается нам продавать с января месяца(кстати sales at ibase.ru тоже молчит как партизан)
5. Находим старый IbAnalyst, запускаем, видим что к окончанию рабочего дня стало еще хуже, сожалеем что бросили курить, выгружаем IbAnalyst(статистику не сохраняем);
6. Загружем IbExpert, снова запрос на mon$transaction + mon$attachments, смотрим на долгоиграющие пишущие транзакции, вспоминаем что не сохранили статистику.
7.Лезем в MON$DATABASE за OAT и видим что значения MON$TRANSACTIONS. MON$TRANSACTION_ID > MON$DATABASE.MON$NEXT_TRANSACTION;
8. Сразу gstat -h, затем снова MON$DATABASE, значения отличаются как писал выше.
9. Возвращаемся на базу, для чистоты эксперимента берем isql, стартуем snapshot, повторяем полученный на объекте результат.
10. Своих знаний не хватает, у Борри искать MON$ глупо, чтение релизнутых нот просветления не вызывает.
11. Поиск по sql и ibase.ru ничего не дал.
12. Отвлекать некто по телефону не решаемся, обращаемся за помощью.
В качестве чего-нибудь вроде, готов попробовать свежий IbAnalyst :)

hvlad
Разработчик Firebird
Сообщения: 1244
Зарегистрирован: 21 мар 2005, 10:48

Сообщение hvlad » 07 июн 2008, 00:25

OX писал(а):MON$TRANSACTIONS. MON$TRANSACTION_ID > MON$DATABASE.MON$NEXT_TRANSACTION
Круто.
Будем смотреть на соотв. код в сервере.

Запросы делали от SYSDBA ?

OX
Сообщения: 24
Зарегистрирован: 26 окт 2004, 17:08

Сообщение OX » 07 июн 2008, 08:17

Да, sysdba, сегодня в офисе постараюсь сделать воспроизводимый пример на employee.fdb

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Сообщение kdv » 07 июн 2008, 09:38

sales at ibase.ru тоже молчит как партизан
так письма писать же надо. с данного emai у меня одно письмо, от 3 октября 2006 года.
Находим старый IbAnalyst, запускаем
т.е. статистика, получаемая через services api идентична получаемой из gstat?

OX
Сообщения: 24
Зарегистрирован: 26 окт 2004, 17:08

Сообщение OX » 07 июн 2008, 10:39

kdv писал(а):т.е. статистика, получаемая через services api идентична получаемой из gstat?
Да
так письма писать же надо
Ok, повторяю письмо 21.04.2008(правда последние 2 года наша переписка идет по другому адресу :), тема "FW: Покупка ПО" )
P.S
Кстати, удалось повторить на employee, чуть позже опишу последовательность действий.

hvlad
Разработчик Firebird
Сообщения: 1244
Зарегистрирован: 21 мар 2005, 10:48

Сообщение hvlad » 07 июн 2008, 11:38

OX писал(а):Кстати, удалось повторить на employee, чуть позже опишу последовательность действий.
Очень хорошо, ждем описания

OX
Сообщения: 24
Зарегистрирован: 26 окт 2004, 17:08

Сообщение OX » 07 июн 2008, 13:18

Сервер - Win 2003, FB 2.1 CS, employee.fdb
Клиент - WinXP, клиентская библиотека fbclient 2.1.0.17798, IBExpert 2008.04.09
1. Соединяемся с БД под SYSDBA.
2. Создаем второе содинение с этой же БД, снова под SYSDBA.
3. Далее все в контексте второго соединения

Код: Выделить всё

  select count(*) from mon$attachments;
         COUNT = 2

  select mon$transaction_id from mon$transactions;
  MON$TRANSACTION_ID = 841

  select  mon$next_transaction from mon$database;
  MON$NEXT_TRANSACTION = 841
4. Commit; Закрываем второе соединение.
5. gstat на сервере
Next Transaction = 853
6. Новое соединения под SYSDBA.

Код: Выделить всё

  select mon$transaction_id from mon$transactions;
  MON$TRANSACTION_ID = 863

  select  mon$next_transaction from mon$database;
  MON$NEXT_TRANSACTION = 841
MON$NEXT_TRANSACTION = 841 до тех пор пока не будет зарыто первое соединенение.

dimitr
Разработчик Firebird
Сообщения: 888
Зарегистрирован: 26 окт 2004, 16:20

Сообщение dimitr » 07 июн 2008, 14:46

баг подтверждаю, спасибо. Сегодня поправим.

dimitr
Разработчик Firebird
Сообщения: 888
Зарегистрирован: 26 окт 2004, 16:20

Сообщение dimitr » 07 июн 2008, 15:38

исправление официально войдет в версию 2.1.2, в снапшотах будет доступно уже завтра.

OX
Сообщения: 24
Зарегистрирован: 26 окт 2004, 17:08

Сообщение OX » 07 июн 2008, 19:02

Спасибо, будем ждать 2.1.2.

Ответить