tempDb, используется ли ?

1. Mi11er 96 21.08.18 12:31 Сейчас в теме
Возникло сомнение, что не используется TempDb.
Сейчас она лежит частями на RAM и SSD, отведено ей 15Gb ( с логами ) при размере основной базы 33Gb.
ОЗУ для MSSQL выделено 35 Gb.

Откуда такие сомнения, судя по отчету, места tempdb не занимает, почти, крохи там какие то
По отчету транзакций, их просто 0...

Мои опасения верны ? или это все паранойя ?
Если все же не используется, то куда копать, где может быть проблема ?
Прикрепленные файлы:
По теме из базы знаний
Найденные решения
7. Gilev.Vyacheslav 1910 22.08.18 13:20 Сейчас в теме
(6)
Что скуль просто не мог получить доступ к RAM.

ну так у вас бы скуль не стартовал и это трудно не заметить
если у вас tempdb только на рам-диске и вы руками создали в студии инсерт во временную таблицу, то все работает, займитесь реальными задачами )
Остальные ответы
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
4. Gilev.Vyacheslav 1910 21.08.18 22:03 Сейчас в теме
(1) если коротко, то у вас паранойя

но если быть педантичным, то Вам нужно выровнять начальные и финальные размеры файлов mdf и ndf, сейчас у вас нагрузка приходится на физический диск, а не на рам-диск судя по скриншоту

если диск E физический и выходите увеличить потенциально максимальный размер tempdb, то можете не выключать автоматический прирост размера
для файлов на tempdb сделайте максимально доступный размер и выключите рост

обратите внимание что оценивать tempdb после рестарта нет смысла, нужно чтобы был как можно больший аптайм
6. Mi11er 96 22.08.18 09:33 Сейчас в теме
(4)Понял, физический диск, я только не давно прицепил, для тестирования, думал, может он начнет расти ... Что скуль просто не мог получить доступ к RAM.
Про аптайм, до последнего рестарта, он был достаточно большой, >месяца, но данные по занятому месту, в целом такие же были.

Только 2 раза за год была ситуация, когда темп съелл весь рам диск... больше такого не повторилось.
7. Gilev.Vyacheslav 1910 22.08.18 13:20 Сейчас в теме
(6)
Что скуль просто не мог получить доступ к RAM.

ну так у вас бы скуль не стартовал и это трудно не заметить
если у вас tempdb только на рам-диске и вы руками создали в студии инсерт во временную таблицу, то все работает, займитесь реальными задачами )
8. Mi11er 96 22.08.18 14:05 Сейчас в теме
(7) Наверное да, лучше оставить этот вопрос =) Спасибо, Вячеслав. Успокоили.
2. Timur.V 78 21.08.18 12:52 Сейчас в теме
Для анализа нагрузки на временную базу данных используется следующий запрос:

SELECT SUM(user_object_reserved_page_count)*8 as usr_obj_kb,
SUM(internal_object_reserved_page_count)*8 as internal_obj_kb,
SUM(version_store_reserved_page_count)*8 as version_store_kb,
SUM(unallocated_extent_page_count)*8 as freespace_kb,
SUM(mixed_extent_page_count)*8 as mixedextent_kb
FR OM tempdb.sys.dm_db_file_space_usage

Соответственно, в первой колонке usr_obj_kb мы видим сколько данных во временной базе данных используется в прикладном коде, например, при создании временных таблиц. Колонка internal_obj_kb показывает, сколько данных используется для системных задач, а version_store_kb показывает объем данных для хранения версий строк при использовании версионности.

Более детальный анализ использования временной базы данных в реальном времени можно сделать с помощью следующего запроса:

SELECT es.session_id
, ec.connection_id
, es.login_name
, es.host_name
, st.text
, su.user_objects_alloc_page_count
, su.user_objects_dealloc_page_count
, su.internal_objects_alloc_page_count
, su.internal_objects_dealloc_page_count
, ec.last_read
, ec.last_write
, es.program_name
FR OM tempdb.sys.dm_db_session_space_usage su
INNER JOIN sys.dm_exec_sessions es ON su.session_id = es.session_id
LEFT OUTER JOIN sys.dm_exec_connections ec ON su.session_id = ec.most_recent_session_id
OUTER APPLY sys.dm_exec_sql_text(ec.most_recent_sql_handle) st
Показать

В этом запросе мы видим объем данных во временной базе для каждой сессии.

Для оценки производительности необходимо сделать анализ производительности ввода-вывода для файлов данных временной базы данных:

SELECT files.physical_name, files.name,
stats.num_of_writes, (1.0 * stats.io_stall_write_ms / stats.num_of_writes) AS avg_write_stall_ms,
stats.num_of_reads, (1.0 * stats.io_stall_read_ms / stats.num_of_reads) AS avg_read_stall_ms
FR OM sys.dm_io_virtual_file_stats(2, NULL) as stats
INNER JOIN master.sys.master_files AS files 
ON stats.database_id = files.database_id
AND stats.file_id = files.file_id
WH ERE files.type_desc = 'ROWS'

Если время записи данных (avg_write_stall_ms) меньше 10 мс, то это значит хороший уровень производительности. Между 10 и 20 мс — приемлемый уровень. Более 20 мс — низкая производительность, необходимо сделать детальный анализ. Более 50 мс — имеются проблемы с вводом-выводом для временной базы данных.
shaykhelov; collider; Mi11er; +3 Ответить
3. Mi11er 96 21.08.18 12:59 Сейчас в теме
(2) Спасибо, сейчас займемся.
5. Gilev.Vyacheslav 1910 21.08.18 22:06 Сейчас в теме
(2) конечно для общего развития скрипты могут пригодиться, но какая практическая польза?
Оставьте свое сообщение
Вакансии
1С аналитик
Москва
зарплата от 210 000 руб.
Полный день

Руководитель направления 1С
Москва
зарплата от 350 000 руб.
Полный день

1С Программист
Москва
зарплата от 180 000 руб.
Полный день

Программист 1С
Москва
зарплата от 180 000 руб. до 220 000 руб.
Полный день

Аналитик 1С / Бизнес-аналитик
Нижний Новгород
зарплата от 100 000 руб. до 250 000 руб.
Временный (на проект)