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