За какое время?

И чем PAGE_READS отличается от PAGE_FETCHES?

Спасибо!

А что такое старт БД и как его увидеть?

P.S.
Время старта - это ведь не время создания, нет?

У меня база 44 Гб (страница 16Кб), и статистика PAGE_WRITES = 500. И постепенно растет, да. Но 500 * 16Кб = 8 Мб, но никак не 44Гб. Или что, или как? База создана с нуля, потом набивалась данными.

Первый коннект после отсутствия коннектов? А, ну тогда понятно.

Спасибо!

Остался интересный вопрос.

Как узнать время старта базы?

kdv,

Ну как зачем? Вот я смотрю PAGE_WRITES, пытаясь оценить интенсивность накопления/обновления данных, и вижу значение 500. О чем мне это говорит? Да ни о чем. А вот 500 страниц/час, или 500 страниц/сек, или 500 страниц/сутки - совсем другое дело. Можно и предсказания сделать какие-никакие. Зная время старта, я могу вычислить удельные величины. Или сам сервер пусть вычисляет, отдавая PAGE_WRITES/сек.

Старый плюшевый мишка,

От том и речь. Ничего из интегральной статистики не понять, а из дифференциальной кое-что понять можно.

Понятно, надо огород городить. Я просто запустил некое обновление одной процедурой, а оно что-то неожиданно для меня затянулось. Ну я и полез в мониторинг в надежде посмотреть, что происходит, как там обновляется, и обновляется ли вообще. Увидел, но только примерно зная время старта, или потом делая новые снимки, чтобы подсчитать разницу.

Короче, я спросил, мне ответили, спасибо!

pastor,

Может, конечно, может. Это и есть огород, который надо вскопать заранее. А иногда ничего не предвещало такую потребность, а посмотреть вдруг хочется. Или вообще чужой огород. На то вроде и даны системные инструменты.

kdv,

Вы описываете отладку, настройку, исследование и т.п. Там все можно и нужно, и можно заранее предусмотреть, и соломки (датчики, счетчики) подстелить. А я смотрю на текущий рабочий процесс, которому ничего заранее не подстелено, но посмотреть, что там внутри деется, все же хочется. И по результату смотрения принять решение, может его (процесс, процедуру) зациклило, ввело в ступор, и давно уже прерывать пора.

Причем процедура идет в одной транзакции, поэтому никаким иным sql-способом, кроме мониторинга, увидеть изменения я не могу.

pastor,

Проблему решить. Запущена процедура, долго не возвращается. Известно, что процедура проводит обновления в определенной таблице. Надо принять решение - прерывать её и дальше разбираться, или все-таки ждать завершения? Ваши действия? Времена - единицы суток. То есть, если прервать, пара суток коту под хвост.

Да, теперь понял, не надо так делать, надо набольшими порциями отдельными транзакциями. Но ничего такие времена не предвещало.

По факту увидел, что PAGE_WRITES растет, дождался завершения, 72 часа.

Старый плюшевый мишка,

Уверяю вас, все просмотрено-проверено, в плане планов все путем. У меня не селекты, а апдейты, в довольно длинные записи вставляется некое значение, за которым процедура идет в другую базу этого же сервера через execute statement external. В планах этих внешних запросов тоже все неплохо. Firebird 4.0, пул коннектов включен. Я рассчитывал на пару часов, оказалось 3 суток. Плохо рассчитал, что тут скажешь. Кроме планов, есть, видать, и другие важные знания.

У меня так и есть. Меняется одно жалкое маленькое поле в огромной длины записи. Тем не менее по дифференциальным PAGE_WRITES я могу оценить количество обновленных записей в единицу времени, используя предположение (надеюсь, верное), что при изменении одного поля обновляется вся запись.

Вот только не знаю, как соотносится число измененных записей и число измененных страниц: если изменилось N записей, но все они попали на одну страницу, счетчик обновленных страниц увеличится на 1 или на N? А там ведь еще и индексы, и блобы... Короче, все непросто, но в моем случае очень длинных записей это ошибка в разы, а не на порядки, что приемлемо.

Спасибо! Я вам тоже верю!

Какие вы тут суровые. Автор уже почти ничего не хочет, он получил нужные ответы весьма быстро, за что искренне благодарен гуру. А дальше пошла дискуссия, в которой автор посчитал невежливым не участвовать, ибо сам запустил тему.

И еще автору, то есть мне, непонятно, что непонятно осталось вам. Попробую еще раз, простыми словами.

1. Запустил процедуру.

2. Процедура не возвращается. Час не возвращается, другой не возвращается... Что делать?
Вдруг она зациклилась, или ждет на suspend, или еще что? А может, и нормально работает, просто долго. Как узнать?

3. К счастью, известно, что процедура должна последовательно обновлять определенную таблицу.
Из других транзакций изменения не видны, но сам факт наличия обновлений можно посмотреть из мониторинга (надеется автор).
Коннектов всего два, один исполняет процедуру, другой мониторит.

4. Ура, есть такая штука, как PAGE_WRITES! Ну-ка, что там? 500. Что 500, чего 500? Вопрос на форум - ответ получен!
Это 500 страниц обновлены с какого-то момента старта. Ладно, смотрим через минуту - 510, через 2 минуты - 520, через 3 минуты 530,
равномерно и поступательно. Отлично, значит работа идет по плану, откладываем беспокойство, ждем результата.

Собственно, все, ответы получены, проблема снята.

А дальше философия: от абсолютного числа 500 проку никакого нет, и непонятно, когда и кому он может быть, если неизвестно время старта. Зато очень полезны разницы, через минуту, через час и пр. Да не вопрос, можно и руками разницы вычислить. Просто философия.


Эт точно. Вот и набираюсь тут помаленьку. А где еще? В "Руководстве по языку" прочитал ровно то, что вынес в топик. Других документов, где рассказывалось бы про мониторинг, не видел, и на ibase.ru тоже. Наверное, плохо искал. А здесь хорошо, мне уже много рассказали, спасибо hvlad'у прежде всего.

Логично. Схватился за первое, что попалось вроде подходящее. MON$IO_STATS по алфавиту раньше, чем MON$RECORD_STATS.


Вот это спасибо. Маленькие секреты всегда хороши. Особенно, если в памяти остаются. Хотя бы в памяти остается факт существования маленького секрета.

Всех с наступающим Новым Годом! Всем здравого по возможности ума и твердой памяти!

Dimitry Sibiryakov,

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