Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Что же делать с tempdb  [new]
.Anatoly.
Member

Откуда: Екатеринбург
Сообщений: 310
Добрый день.

Вот и у меня случилась проблема с tempdb. Суть все та же. Размер mdf файла постоянно растет, перерастает размер самой базы в два раза(около 2*75ГБ) и упирается в размер диска. После этого вся система не может нормально работать.

Я не гордый могу и шринкануть
DBCC SHRINKFILE ('tempdev', 1024, NOTRUNCATE )
DBCC SHRINKFILE ('tempdev', TRUNCATEONLY)
но результата это не приносит. Или результат не значительный - несколько ГБ.

Самое интересное, что
select cast(cast(fileproperty('tempdev','SpaceUsed')as bigint)*8/1024. as numeric(19,3))
Показывает что используются лишь 12 МБайт.

На данный момент размер mdf ~57ГБ, а ldf 1ГБ
exec sp_spaceused 
database_size      unallocated space
------------------ ------------------
56811.81 MB        55809.41 MB


В данный момент(времени) с сервером практически никто не работает. То есть создается ощущение, что это просто утечка памяти. Подскажите как можно найти в чем проблема? Хотя бы в какую сторону копать?


PS
select @@version

Microsoft SQL Server 2005 - 9.00.5057.00 (X64) Mar 25 2011 13:33:31 Copyright (c) 1988-2005 Microsoft Corporation Standard Edition (64-bit) on Windows NT 6.0 (Build 6002: Service Pack 2)

PSS Пока эта проблема решается перезагрузкой сервера раз в несколько дней.
29 сен 12, 20:11    [13244084]     Ответить | Цитировать Сообщить модератору
 Re: Что же делать с tempdb  [new]
Гавриленко Сергей Алексеевич
Member

Откуда:
Сообщений: 37254
Ищите долгоиграющие запросы профайлером. Чтобы записать 150 Гб в tempdb, нужно прилично времени.

Сообщение было отредактировано: 29 сен 12, 20:54
29 сен 12, 20:54    [13244139]     Ответить | Цитировать Сообщить модератору
 Re: Что же делать с tempdb  [new]
.Anatoly.
Member

Откуда: Екатеринбург
Сообщений: 310
Гавриленко Сергей Алексеевич, с помощью
select * from sys.dm_exec_cursors(0)
нашел незакрытые курсоры, которые висят более суток. Посмотрел по идентификаторам сессии и понял, что это сессии открытые из desktop'ных приложений пользователей, которыми в тот момент никто не пользовался. То есть фактически пользователь в конце рабочего дня встал, ничего не закрыл и ушел на домой. После того как я убил эти сессии, файл tempdb смог уменьшить до минимальных размеров.

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

Как проверить размер который занимает курсор в памяти? Если он занимает меньше, то почему нельзя перераспределить оставшеюся память под другие задачи?
30 сен 12, 10:13    [13244774]     Ответить | Цитировать Сообщить модератору
 Re: Что же делать с tempdb  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31956
.Anatoly.
Большой минус разработчикам приложения, что курсоры отстаются висеть незакрытыми, когда никаких действий не происходит. Но мне кажется сомнительным, чтобы пользователь смог занять столько места курсорами.
Приложение создало какие то временные таблицы и делает из них выборки. Второй вариант - приложение делает выборки из постоянных таблиц, при этом сервер создеёт слепок выборки в tempdb. Т.е. это весь слепок данных выборки, он может занимать очень много места.

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

Обычно так бывает у приложений, которые разрабатываются как развитие настольных СУБД, там приняты такие архитектуры.

Это не только увеличивает размер tempdb, но и сильно снижает производительность. Нормальный подход - выполнить запрос и сразу получить данные, вообще не начинать не обрабатывать данные до полного их получения от сервера и закрытия текущей команды.
30 сен 12, 11:58    [13244875]     Ответить | Цитировать Сообщить модератору
 Re: Что же делать с tempdb  [new]
.Anatoly.
Member

Откуда: Екатеринбург
Сообщений: 310
Оказывается проблемы были не в забытых курсорах. Или не только в забытых курсорах.
После того как все пользователи стали закрывать клиентские приложения сами или принудительно, проблема не исчезла.
При попытке шринкнуть файл, он уменьшался в размерах до 40-45ГБ. А скрипт выдавал сообщение.
DBCC SHRINKFILE: Page 1:4637320 could not be moved because it is a work table page.

Посмотрев в tempdb я увидел много объектов типа #344946C3. Погугли нашел сообщения, что в таком случае, если все эти объекты хочется удалить, а базу все-таки узжать, нужно сначала удалить неиспользуемый кеш командой
DBCC FREESYSTEMCACHE ('ALL')

Так и сделал после чего файл благополучно ужался до 8ГБ.

В мсдн пишут, что этот сброс кеша приведет так же к удалению всех планов, что в свою очередь временно снижает производительность.

Хочется понять, а действительно ли у меня хранилось 40-45ГБ ненужного кеша? Можно ли отчистить кеш не трогая планы? Стоит ли игра свеч?
7 окт 12, 22:08    [13281259]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить