SQL Server 2016 Move tempdb to another drive. Переносим и настраиваем TempDB
HTML-код
- Опубликовано: 3 окт 2024
- Смотрим на "криво" настроенную tempDB. Переносим с одного диска на другой и настраиваем по best practices.
Мой LinkedIn
/ alexanderbereznev
Мой сайт
www.datainterna...
Александр, в финале не хватает только результатов Pedro-скрипта, в котором видно, что Latch-и после всех описанных манипуляций уходят. А в общем, фокус с Initial Size ушел в заметки, спасибо!
Еще раз спасибо. по тесту выполнение обработки изначально занимало 43 сек
Электропитание в панели управление переключил на "максимальная производительность" - результат 33 сек
tempdb перенесен на ССД - результат 28 сек
в БИОСе отключены С3,С6 - результат 23 сек
Директория ТЕМР винды и пользователя, а также журналы регистрации 1С (srvinfo) перенесен на ССД - результат 17 сек!
//единственное пока остается прыганье частоты проца 1.6-2.8ГГц, хотя в биосе принудительно выставлено 2.8 в том числе и для турбобуста... буду разбираться... думаю еще секунд 3-5 даст....
//а вот использование РОМ-диска для темпдб не дало вообще ничего....
Если есть дисковые проблемы, можно посмотреть на задержки чтения/записи должно быть менее 20мс, то можно попробовать использовать сжатие индексов и таблиц на Enterprise редакции. Гуглится по SQL Server Page Compression. Правда это "слетит" после пересборки 1С. Но эффект бывает глобальным и серьезным.
Еще можно попробовать погонять флаг трассровки 4199, надо только проверить поддерживаемость для SQL2008 (я честно уже не помню).
@@datainternalsru6025 сами базы лежат на обычном нормальном хдд, задержки порядка 5-35мс,
спасибо, помогло
Также обнаружил полезную информацию - перенос в РАМ-диск
А также вы забыли упоминуть, что считать стоит только физические ядра процессора, а не виртуальные....
Спасибо за добавление. В одном из соседних видео тоже обсуждали эту тему. С RAM Drive штука отличная, вопросы только возникают в этом случае к "пожирателям" tempDB. И еще есть проблемка, пользователи привыкают к хорошему, а когда RAM Drive заканчивается и начинает(ют) использоваться файл(ы) на диске, то пользователи начинают жаловаться, что все "умирает". В такой ситуации становишься заложником желания помочь/ускорить и приходится докупать память для RAM drive. Мое мнение, что любые оптимизации только лишь за счет железа, заканчиваются плохо. Параллельно нужно "ковырять" код приложения, смотреть что там и почему используется tempDB. По практике, даже сервера с 3-мя Террами РАМа на борту не выживают под напором "крутого" кодинга:)
@@datainternalsru6025 подскажете, есть 2 сервера
i7 930 на материнке x58
И
2 хеона 5620 на intel 5520
В остальном железе полностью идентичны
ПО 2008р2 , скуль 2008 - всё тоже одинаково
Но второй сервер показывает на 30-50% ниже производительность, хотя должно быть наобот...
Куда копать?
@@ELITEkaluga Так сложно сказать, не видя систему. я так понимаю, что тестировалось идентичное ПО, идентичная БД, идентичная нагрузка?
Я бы посмотрел на
1. дисковую подсистему. время отклика дисков должно быть 10-15мс.
2. настройки экземпляров , точно ли они одинаковые (sp_configure)
3. посмотрите ожидания на серверах (sql server waits), насколько они схожы. По типу ожидания можно уже судь о том, что тормозит выполнение запроса/ов.
А вообще, есть вот такой проект - www.hammerdb.com/ у них есть софт для тестирования серверов, он создает идентичную БД, нагрузку и после этого "гоняет сервер" и выдает бенчмарковские "попугаи". Попробуйте сравнить этой тулой сервера.
@@datainternalsru6025 да , именно по, база, нагрузка полность одинаковые.
Все отличие только в материской плате и процессорах
@@datainternalsru6025 нашлась засада - С6 в биосе включен был, отключил и результат сразу на 30% лучше стал
Добрый день . каким образом с генерировали нагрузку ??? Скрипт ????
Добрый день! И да и нет, это утилита, внутри неё сидят скрипты уже. Честно сказать, какой именно скрипт использовался, уже сложно вспомнить.
Лайк подписка =) скрипт отличный на 7 минуте
i dont mean to be so offtopic but does anybody know of a method to log back into an instagram account..?
I stupidly lost the account password. I would appreciate any help you can offer me!
@Dominick Max instablaster =)
@Colten Ben thanks for your reply. I found the site on google and Im in the hacking process now.
Takes a while so I will get back to you later when my account password hopefully is recovered.
@Colten Ben it worked and I finally got access to my account again. I'm so happy:D
Thanks so much you saved my ass !
@Dominick Max You are welcome =)
Интересуют еще параметры роста- вы про них ничего указали
@@1boxingclub378 про рост, да, наверное стоило. Вообще, autogrowth сам по себе процесс не очень удачный и может оказать негативное влияние. Тут не так давно нарвались на интересное ожидание, связанное с ростом лога и я могу сказать, что не зря процесс autogrowth считается нежелательных для высокопроизводительных БД.
@@datainternalsru6025 А вы можете дать рекомендации относительно параметров роста? Например у меня сервер с 1 физическим процессором 3 логических. У нас сейчас спор идет с коллегами относительно настройки файлов tempdb. Я топлю что надо оставить 8 файликов которые были до меня но изменить параметры роста. А коллеги говорят что надо ставить к-во файлов равное количеству процессоров. Что вы можете сказать по своему опыту? Система сама по себе имеет среднюю нагрузку
у меня 48 ЦП и 48 файлов данных, при этом есть ожидания (10ms)PAGELATCH_SH:tempdb:28(PFS). Что будет если я сделаю 64 файла данных при 48 процессорах? не будет ли хуже
Антон, приветствую!
Для начала проверьте, что у вас файлы одного размера (текущий размер имеет значение) и размер автоприроста у всех файлов стоит одинаковый. Еще хорошая практика флаги - T1117, T1118. до 2016 они актуальны, потом уже не очень ( blog.sqlauthority.com/2020/02/27/sql-server-tempdb-and-trace-flag-1117-and-1118-not-required/ www.mssqltips.com/sqlservertip/4364/sql-server-2016-trace-flags-1118-and-1117-for-page-allocations/)
После этого можно наверно подумать про увеличение количества файлов, но 48 и так довольно много, у меня как-то сомнения, что доп. файлы помогут такой проблеме. Я не могу припомнить, чтобы кто-то из моих заказчиков имел такой конфиг, чтобы файлов было больше, чем физических ядер на сервере. Сложно предположить, какой может быть от этого эффект.
А что у вас за нагрузка такая на tempdb? Много временных объектов или механизм версионности работает?
Спасибо за видео, есть вопрос создал 10 файлов темп дб и один лог а как удалить 2 лишних файла когда в нем уже есть данные.
приветствую! вопрос удаления файлов базы данных tempDB не так прост, для начала я бы рекомендовал ознакомиться со статьей Erin Stellato - www.sqlskills.com/blogs/erin/remove-files-from-tempdb/
В ней есть набор команд DBCC, которые по своей сути выполняют "software reset" SQL Server-у, если можно так сказать и помогают избавиться от ненужных файлов. Я бы очень аккуратно применял эти команды, но могу сказать, что они работают, использовал.
Я всегда исхожу из принципа "не навреди", поэтому перестраховался бы и выполнял работы во время минимальной нагрузки или в окне обслуживания.
7 бед 1 ресет...
Ресет - удаление - ресет
А вот так прокатывает : DBCC FREEPROCCACHE;
DBCC DROPCLEANBUFFERS;
GO
USE tempdb;
GO
-- Очистка файлов
DBCC SHRINKFILE (N'temp10', EMPTYFILE);
DBCC SHRINKFILE (N'temp9', EMPTYFILE);
DBCC SHRINKFILE (N'temp8', EMPTYFILE);
DBCC SHRINKFILE (N'temp7', EMPTYFILE);
GO
USE master;
GO
-- Удаление файлов
ALTER DATABASE tempdb REMOVE FILE temp10;
ALTER DATABASE tempdb REMOVE FILE temp9;
ALTER DATABASE tempdb REMOVE FILE temp8;
ALTER DATABASE tempdb REMOVE FILE temp7;
GO Далее рестарт и все порядок
Появилась мысль обновить проц (сейчас i7-930)
Подскажите что лучше:
Итак выбор между X5687, X5690, i7-990x
базы две по 12гб (совсем не большие) - пользаков около 50 на толстых клиентах, особо никаких выборок и выгрузок нет (список товаров да бухи отчеты стандартные)
текущая нагрузка на сервер по процу выше 5-6% редко скачет
Почему хочу обновить - потому, что их щас на БУ рынке много и цены весьма дешевые
так вот x5687 = 1100р, привлекает более высокой частотой = 3.6 и потенциалом разгона
а Х5690 и 7-990х имеют 6 ядер, но горячее и меньше потенциал разгона, а также цена уже 4500 и 5500р....
склоняюсь больше к более высоким частотам, чем числу ядер не только по цене, но и потому, единовременных операций мало - и скорость их выполнения будет на прямую от частоты зависеть....
//по тесту даже мой проц на частоте 2.8 при разгоне до 2.93 дает +5% ускорения работы 1с....
что можете посоветовать? я правильно мыслю? или все же лучше побольше ядер ?
Добрый день, а можно получить ваши волшебные скрипты по анализу ms sql?
приветствую! думаю можно:), а какой скрипт интересует? скажите минуту, на которой он мелькает в видео, я найду его
7 минута 32 секунда
мною скрипт был найден где-то на просторах интернета, точное место уже не помню, но...
По ссылке ниже есть этот же скрипт, пользуйтесь:)
jonlabelle.com/snippets/view/sql/show-sql-server-database-files
Я так и не понял, как удалось переместить tempdb, так же было сообщение "The new path will.....". Использовал тот же самые скрипт. 1 база прошла нормально, 2 (которая больше всего интересовала) так и не изменила место хранения файлов. Почему может такое быть?
Сервер перегружал, не помогло.
Далее можете показать полный скрипт на отрезке 13:47, конец не видно.
приветствую!
перенос осуществлялся правкой метаданных - команда ALTER DATABASE TempDB MODIFY FILE...
, реальный перенос файлов происходит только после перезагрузки экземпляра SQL Server.
Скрипт на 13:47
use tempdb
go
select name, size*8/1024 [current size MB],* from sys.database_files
use master
go
select name,size*8/1024 [initial size MB] ,* from sys.master_files where database_id=2
Что касается вопроса о переносе на втором сервере. Я бы проверил метаданные, что они показывают, какой путь. Скрипт выше.
похожи на Мясникова 😆
*голосом кота матроскина
а я и на гита-а-аре тоже немного умею :)