Проблемы производительности SAN при хранении базы данных tempdb SQL Server в резервной копии SAN
Боюсь, я не знаю много о SAN, поэтому, пожалуйста, прости меня за отсутствие деталей или технических терминов.
Как разработчик, я только что закончил и включил в существующую производственную систему новое приложение, но, похоже, оно изменило масштаб производительности резервных копий, взятых из SAN. Насколько я понимаю, есть зеркало того, что SAN используется постоянно на уровне блоков. Однако, похоже, что на диск столько новых записей, что процесс зеркалирования / резервного копирования SAN уже не может идти в ногу. Я считаю, что я сузил это до базы данных SQL Server tempdb, которая существует на диске, который вносит наибольший вклад в проблему! На самом деле, я думаю, что tempdb всегда вносил основной вклад в решение проблем независимо от моего приложения!
Поэтому мой вопрос заключается в том, должен ли tempdb когда-либо отражаться или поддерживаться в сети SAN, и прошел ли кто-нибудь еще такую боль? Мне интересно, будет ли лучше убедиться, что база данных tempdb никогда не зеркально отражается в SAN просто потому, что нет необходимости сохранять какие-либо записи в нее. Это также поднимает немного связанный вопрос - лучше ли полагаться на встроенные в SQL Server инструменты резервного копирования базы данных (БД в режиме полного восстановления с полным / разностным резервным копированием и резервным копированием журнала транзакций) или, как в случае с нашим приложением, SQL-сервер находится в простом режиме восстановления и никогда не резервируется, поскольку SAN зеркалируется и резервируется?
Большое спасибо
3 ответа
Вам вообще не нужно выполнять резервное копирование / зеркалирование базы данных tempdb, поскольку она все равно воссоздается при перезапуске SQL Server.
С другой стороны, даже в тех случаях, когда у меня было доступно зеркальное копирование / репликация SAN, я все еще поддерживал цикл резервных копий SQL как точку восстановления пояса и фигурных скобок - но это обычно потому, что резервные копии SAN управлялись другими, и я хотел бы иметь некоторые bak-файлы, с которыми я могу легко работать, чтобы сделать тестовое восстановление и т. д.
Все это говорит о том, что если у tempdb много записей, вы должны попытаться их устранить. tempdb ПЫТАЕТСЯ не записывать на диск, он делает это, когда ему нужно больше страниц, чем доступно памяти. ОЧЕНЬ часто это признак дрянного SQL, например, лишних предложений DISTINCT (заставляющих хранить все записи в базе данных tempdb для устранения двойных чисел). Не всегда говорю, но если вы получаете много записей в tempdb, попробуйте выяснить, действительно ли они вам нужны.