shalamyansky,

никак. мог быть самый первый коннект, после него еще 10, а потом первый отваливается, и ... всё. Статистика существует дольше, чем самый старый коннект на этот момент.
А зачем это надо? Какая в этом может быть, так сказать, положительная мулька?
Можно, например, регулярно торкать fb_lock_print и смотреть на Owners (кол-во коннектов), рисуя при этом график.

shalamyanskyпытаясь оценить интенсивность накопления/обновления данных
это не туда надо смотреть. А например в bytes written в перфмоне (виндовом, на линуксе х.з.). По крайней мере там как раз будут данные с "самого первого коннекта к БД".
Но если "разрывы" коннектов есть, то и таким образом тоже полноценную картину не получить. Это надо на уровне ОС включать счетчики, и мониторить их уже там.

Таблицы мониторинга это снимок текущего состояния сервера. Они в памяти. Сервер никуда их не складирует, и при отсутствии коннектов к БД "там" ничего нет.
Если надо - делайте свою службу, которая будет раз в 5 минут круглые сутки скидывать page writes и другое куда-нибудь. Главное только делать коннект-получение_данных_дисконнект :-)

shalamyansky,

божечки мои. берешь эту базу на тестовый стенд (нбэкапом или еще как), открываешь коннект, запускаешь процедуру, и смотришь page writes хоть процедуры, хоть коннекта. Понятно что тут не будет видно влияния вытеснения кэша конкурирующими коннектами, но всё-таки. Но если это классик или суперклассик, то данные будут точными, хоть в многопользовательском режиме.
С супером - да, в многоюзерском будет не так точно. Но минимум отловить точно можно.

shalamyanskyЗапущена процедура, долго не возвращается.
ну и, посмотрел в mon, увидел. Зачем тогда какие-то счетчики от рождества христова???
shalamyanskyсчетчик обновленных страниц увеличится на 1 или на N? А там ведь еще и индексы, и блобы
а вот х.з. если кто-то еще в базе молотит, страница может упасть на диск, а потом попадет в кэш еще раз, поэтому получится что количество измененных записей и количество page writes не совпадает.
Но это всё лирика.
Например - в базе внезапные тормоза, работает запрос. В чем причина? Оказалось, что была длинная транзакция (чья-то, х.з.), после чего накопились тонны мусора, кто-то запустил запрос и в это время сработал репликатор (который программно собирает записи по всей базе), и началась адова сборка мусора.
Определили причину трейсом плюс мон.