В Temp-папке есть файлы fb_sort_... и fb_table_... Один из файлов сортировки занимает 2,5 Гб. Один из файлов таблицы занимает 250 Мб. Мне интересно, что это за сортировка и что это за табличка. Можно ли сделать способ это увидеть?

hvladУвидеть к чему он относится - не получится.
Меня как раз вот это интересует. А можно ли доработать сервер, например, добавить MON$-таблицу со статистикой по памяти для сортировки? Или это очень проблематично посчитать?
Например, поля: MON$ID_STATEMENT (номер стейтмента), MON$QUERY (запрос в нем, если это EXECUTE BLOCK), MON$TYPE (MEMORY, FILE), MON$MEMORY.
И оставлять статистику на коннекте или в течении часа, чтобы можно было помониторить пользователей.

hvladФайлы fb_table_XXX содержат временные данные - GTT, временные блобы и прочее.
Они создаются по-одному на БД для SS или по-одному на коннект для SC\CS.
Я думал, тут по одному файлу на таблицу. Опять таки, можно ли сделать MON$-таблицу по GTT? У нас есть больше десятка таблиц с PRESERVE ROWS и статистика по их размерам под конец работы пользователя была бы любопытной.

hvladИспользование памяти под сортировку логичнее добавлять в общую статистику выполнения запроса. Уже оттуда она может попасть и в мониторинг, и в трейс.
Согласен.
Но тут нюанс. Собственно, почему заинтересовался файлом сортировки. Он был размером 2.4 Гб во время рестора базы, при создании какого-то индекса. Хочу узнать, что это за индекс и почему файл такой большой. Но я не смогу это выяснить, так как с базой начну работать уже после окончания рестора. Может, есть какие-то другие способы решения?

hvladНо есть практические вопросы без ответов:
- нет способа сделать это для чужих процессов CS
- нет способа указать gstat'у, что нужно работать с временным табл.пр-вом
- для SS непонятно что показывать - инф-цию о каждом экземпляре GTT, или суммарно
- для SS нужно решить, можно ли Васе видеть статистику временных объектов Пети
и т.п.
п. 3 - о каждом.
п. 4 - согласно правам. Админам можно видеть все, иначе Вася видит только статистику по своему имени пользователя.
И опять-таки, в случае виртуальной таблицы администратор может отбирать и группировать данные так, как ему надо.
CONNECTTRANSACTIONNAME_TABLETYPESIZE11001TMP$IDPRESERVE ROWS409611002TMP$FILTERDELETE ROWS6553621010TMP$FILTERDELETE ROWS8192

И вопрос - файлы fb_table_... - это не обычные ли FDB, только временные?

kdv- в бэкапе индексы не хранятся, только их описание (метаданные)
- большой темп-файл при создании индекса получается из-за того, что большой ключ индекса и много данных в таблице
- сколько данных в таблице - нельзя узнать до окончания ее перелива из бэкапа в БД. Впрочем, можно, если открыть базу IBBackupSurgeon - он просканирует бэкап и покажет размер таблиц. Однако, имена индексов к таблицам IBBackupSurgeon не показывает.

Дмитрий, ну что вы мне базовые знания рассказываете?

kdvчто??? какие еще "fdb"? fb_table - это GTT. Во время рестора их не может быть.
Не может. Речь не про рестор.

kdvВообще, если ты наблюдаешь указанные файлы в temp после рестарта сервера или firebird, значит, ДО этого (время последнего доступа к файлам) сервер целиком рубанули по reset (а не просто упал ФБ или его терминировали).
Я спрашиваю не про то, зачем эти файлы и откуда они, а как узнать, чем они заполнены.

hvladРестор с указанием -v покажет какой индекс сейчас строится
Да, придется рестор через обычный cmd запускать. сейчас вывод лога сливается в файл, и данные в нем отстают от реальности.