Я изучаю, как управлять базами данных для своей компании, и, хотя у меня есть довольно хорошее представление об использовании базы данных, я определенно вижу, что администрирование базы данных совершенно другое.
Я считаю, что мы небольшая команда, и раньше у нас не было никого, кто управлял бы серверами баз данных, и если что-то пойдет не так, мы исправим это, но профилактического обслуживания не было.
Я составляю некоторую документацию с лучшими практиками, которые мы должны использовать, исправлениями обнаруженных проблем и методами предотвращения их возникновения. На данный момент мои менеджеры не хотят исправлять серверы БД (ОС и программное обеспечение БД), что я считаю безумием, но они старшие и «лучше всех знают».
Наша среда - Server 2003, с 5 серверами БД, тремя MSSQL 2005 и двумя MSSQL2000. Все серверы БД частные и не выходят в Интернет. Они находятся за нашим брандмауэром. Тот факт, что они не являются общедоступными, является причиной нежелания менеджеров исправлять серверы.
Что я хотел бы знать:
Как люди управляют установкой патчей для SQL-серверов и ОС? Надо ли их патчить? Элемент списка Когда вы применяете исправления (сразу же, через пару дней, чтобы дождаться появления и документирования проблем, другое)? Перечислите белые книги, техническую документацию, хорошие блоги и т. Д., Которые вы можете порекомендовать. Любая помощь будет принята с благодарностью, поскольку я считаю, что они должны быть исправлены, по крайней мере, до самого последнего SP и, возможно, второго недавнего накопительного обновления, но у меня нет каких-либо передовых методов, на которых можно было бы основывать это, поэтому я очень хотел бы узнать что люди делают.
Если вам нужна дополнительная информация, свяжитесь со мной.
Спасибо,
Лима
Мой совет: да, патчите их. Как мы видим уже сегодня, вредоносный контент может и будет сделать это в вашей внутренней сети. Мысли, противоположные этому, просто наивны и безответственны. В свое время Slammer открывал глаза, и многое было сделано для того, чтобы заблокировать SQL и предотвратить это, но возникают новые угрозы, бла-бла-бла.
Что касается серверов db, он почти такой же, как и другие ваши серверы. Составьте план установки, составьте план отката, примените исправления в тестовой среде, когда удобно, примените их в производственной среде. Их следует оценивать по приоритету вместе со всеми другими исправлениями.
Я согласен, без патчей - безумие. Если ваш бизнес полагается на эти системы, и они не устанавливают исправлений из-за неудобства при администрировании SQL Server, попросите кого-нибудь пройти обучение администратора SQL.
Редактировать: К вашему комментарию, на своем тестовом сервере вы максимально точно дублируете свою производственную среду. Чтобы протестировать процесс исправления, вы выполняете весь процесс на тестовом сервере. Если он не удастся, то есть приличный или лучший шанс, что он выйдет из строя и в производстве. Не исправляйте производственную среду, пока исправления в тестовой среде не станут стабильными.
На серверах приложений вы также хотите убедиться, что ваше приложение продолжает работать так, как задумано, после установки исправлений, поэтому вам нужно будет не только убедиться, что сама система выживает после исправления, но и чтобы вы использовали функциональные возможности своего приложения.
Согласны с вышеизложенным относительно «да, вы должны установить патч, и да, сначала проверьте патчи».
Однако я отмечу, что, когда вы упомянули, что ваша команда новичок в администрировании БД, я считаю, что MSSQL требует исправлений реже, чем Windows. В моем случае я установил обновление Windows на «только загрузку» на нашей тестовой машине, а затем однажды ночью, когда мы чувствуем себя храбрыми, мы говорим Windows, чтобы она продолжала и устанавливала, перезагружалась, а затем запускала наши регрессионные тесты.
Производственная машина настроена так же - только загрузка, не устанавливайте патчи. Поэтому, если наши тесты на тестовой машине проходят успешно, мы просыпаемся в 5 утра на следующий день и говорим производственной машине также установить исправления, даем ей перезагрузиться, а затем выполняем несколько простых тестов, чтобы убедиться, что приложение все еще работает. Обычно мы делаем это не чаще одного раза в неделю, так как мы не любим просыпаться в 5 утра, но, конечно, если описание патча звучит необычно ужасно, мы поспешим.
Исправление баз данных не должно отличаться от исправления чего-либо. Протестируйте, а затем разверните.
Очевидно, что для этого сначала требуется установка исправлений в тестовую систему, но если эти базы данных настолько критичны, как считают их руководители высшего звена в вашей организации, я уверен, что они уже развернули тестовые системы и готовы к тестированию. ;)
Мне всегда интересно, когда люди отказываются исправлять системы, потому что они являются «только внутренними» и, следовательно, безопасными. Я предполагаю, что у вас нет компьютера в вашей локальной сети, который имеет доступ к Интернету, и нет возможности когда-либо сделать что-то с частью программного обеспечения, которое вызовет повреждение данных, сбой сервера в исходной версии программного обеспечения без исправлений.
Ой. Что ж, вы определенно хотите исправить их, поскольку SQL Slammer и другие работают ЗА брандмауэром, так что ... В любом случае, «в тот день» я бы вручную исправлял их из SP, которые время от времени выходят после тестирования на резервном сервере . В настоящее время я просто позволяю «Microsoft Update» обнаруживать любые исправления, связанные с SQL Server. Кажется, работает нормально.