Проблемы производительности SAN, хранящие SQL Server tempdb на SAN, это сохраняется
Для меня это было бы:
poedit - межплатформенные gettext каталоги (.po файлы) редактор
ncftp - очень хороший клиент ftp
htop - интерактивное средство просмотра процесса для Linux
nmap - Сканер безопасности Для Сетевого Исследования и Взламывающий - неоценимое обнаружение всех этих проблем с брандмауэром
wireshark - анализатор сетевого протокола для Unix и Windows - фантастический инструмент, чтобы обеспокоить охоту сетевые проблемы, изучить, как протоколы работают или восстановить некоторые пароли, и очень, намного больше
inkscape - Редактор Векторной графики, который фокусируется на Соответствии SVG
Вы не должны отступать/зеркально отражающий tempdb вообще, так как это воссоздается после перезапуска SQL Server так или иначе.
На другой точке даже в случаях, где я имел репликацию зеркального отражения/SAN В НАЛИЧИИ, я все еще поддержал цикл резервных копий SQL как пояс и точка восстановления фигурных скобок - но это обычно, потому что резервными копиями SAN управляли другие, и мне нравится иметь некоторые bak файлы, что я могу легко работать со сделать тестовые восстановления и т.д.
-
1Достигните единой точки зрения - I' m никакой инженер SAN, но это doesn' t чувствуют себя безопасными мне полагаться на резервные копии блочного уровня когда I' d очень скорее используют обеспеченные транзакцией резервные копии SQL Server. Проблемой является I' m не в управлении того, как SAN настроен, но конечно все пальцы укажут мне с тех пор it' s мой (частично) приложение that' s порождение проблемы! – 11 May 2010 в 15:26
Однако эквивалентность tempdb имеет много записей, необходимо попытаться устранить их. tempdb ПЫТАЕТСЯ не записать в диск, это, мерил делает так, когда требуется больше страниц, чем доступная память. ОЧЕНЬ часто это - знак дрянного SQL, как избыточные ОТЛИЧНЫЕ пункты (вызывающий для ведения весь учет в tempdb для устранения удваивается). Высказывание всегда, но если Вы получаете много записей tempdb, пытается узнать, нужны ли Вам действительно они.
-
1Добрался для согласия с TomTom здесь. SQL всегда собирается съесть ресурсы SAN по своему характеру, но все еще необходимо проверить, что замечаемыми проблемами является not' t на самом деле вызванный плохим SQL/отсутствием производительности, настраивающейся & оптимизация. – Chris W 11 May 2010 в 11:11
-
2Я соглашаюсь, но что I' m взволнованный по поводу в данный момент в настоящее время мы don' t имеют проблему производительности, нам просто связали проблему с резервным копированием базы данных по SAN это doesn' t должен быть сохранен во-первых!! – 11 May 2010 в 15:22