iBase.ru Forum

Я конечно понимаю что пятница, но прошу пояснить почему у gstat и
MON$DATABASE разные значения OIT, OAT, OST и Next?

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

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

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

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

kdv писал(а):за постирование картинок в следующий раз будет бан.

Виноват, исправлюсь

hvlad извини, с первого раз я не понял

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

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

Всё правильно у тебя. Пока что. Вроде бы.

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

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

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

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

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

ведь завтра опять пятница.

c mon$transactions проблем нет,

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

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

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

OX писал(а):MON$TRANSACTIONS. MON$TRANSACTION_ID > MON$DATABASE.MON$NEXT_TRANSACTION

Круто.
Будем смотреть на соотв. код в сервере.

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

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

sales at ibase.ru тоже молчит как партизан

так письма писать же надо. с данного emai у меня одно письмо, от 3 октября 2006 года.

Находим старый IbAnalyst, запускаем

т.е. статистика, получаемая через services api идентична получаемой из gstat?

kdv писал(а):т.е. статистика, получаемая через services api идентична получаемой из gstat?

Да

так письма писать же надо

Ok, повторяю письмо 21.04.2008(правда последние 2 года наша переписка идет по другому адресу

, тема "FW: Покупка ПО" )
P.S
Кстати, удалось повторить на employee, чуть позже опишу последовательность действий.

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

Очень хорошо, ждем описания

Сервер - 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 до тех пор пока не будет зарыто первое соединенение.

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

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

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

iBase.ru Forum

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

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