8 800 700-67-95
Перезвоните мне
Санкт-Петербург
+7 (812) 319-00-04
Москва
+7 495 109-60-25
Поддержка
+7 (812) 319-00-03
За что уволят админа базы данных? Часть 1
25 Июля 2014
ЗА ОТСУТСТВИЕ АДЕКВАТНОГО РЕЗЕРВНОГО КОПИРОВАНИЯ
Про необходимость резервного копирования знают все, поэтому мы говорим не об экстремальном случае отсутствия резервных копий вообще, а о различных проблемах на этом фронте.
В «совершенном мире» админ базы данных должен знать свои целевые показатели времени на восстановление и допустимой потере. Эти требования часто обозначаются как RTO (Recovery Time Objective) и RPO (Recovery Point Objective), то есть как быстро должно пройти восстановление, и до какой точки должны быть восстановлены данные. На основании в том числе и этих требования строится так называемый Disaster Recovery Plan (план восстановления), и как следствие – план резервного копирования.
Цель админа базы данных – стремится к тому, что размер потери данных был минимальным. Когда все, что у вас осталось – это последняя «хорошая» резервная копия, то она и определяет то, сколько данных пропадет.
Иметь надежные резервные копии означает также быть уверенным в том, что с них можно восстановиться, и знать, как это сделать. Здесь в игру вступает тестирование резервных копий. Как самый минимум, вы должны использовать команду BACKUP VERIFONLY, чтобы убедиться, что с резервной копии возможно восстановление.
В дополнение к этому, Роберт Дэвис, эксперт по SQL-серверам, рекомендует использовать опцию CHECKSUM со всеми резервными копиями. Эта опция позволяет сделать дополнительную проверку, чтобы определить – не повреждена ли база данных. С этой опцией происходит проверка самих данных на предмет их повреждения, и в то же время проверяется и сама резервная копия, чтобы убедиться, что она не повреждена.
Большое преимущество использования CHECKSUM в том, что если файл резервной копии поврежден – операция восстановления немедленно даст ошибку. Это важно для тех случаев, когда операция восстановления может занимать часы – на очень больших наборах данных. Узнать, что файл резервной копии поврежден – это конечно плохо, но еще хуже узнать об этом же спустя два часа восстановления.
По материалам сайтов idera.com и sqlsoldier.com
Про необходимость резервного копирования знают все, поэтому мы говорим не об экстремальном случае отсутствия резервных копий вообще, а о различных проблемах на этом фронте.В «совершенном мире» админ базы данных должен знать свои целевые показатели времени на восстановление и допустимой потере. Эти требования часто обозначаются как RTO (Recovery Time Objective) и RPO (Recovery Point Objective), то есть как быстро должно пройти восстановление, и до какой точки должны быть восстановлены данные. На основании в том числе и этих требования строится так называемый Disaster Recovery Plan (план восстановления), и как следствие – план резервного копирования.
Цель админа базы данных – стремится к тому, что размер потери данных был минимальным. Когда все, что у вас осталось – это последняя «хорошая» резервная копия, то она и определяет то, сколько данных пропадет.
Иметь надежные резервные копии означает также быть уверенным в том, что с них можно восстановиться, и знать, как это сделать. Здесь в игру вступает тестирование резервных копий. Как самый минимум, вы должны использовать команду BACKUP VERIFONLY, чтобы убедиться, что с резервной копии возможно восстановление.
В дополнение к этому, Роберт Дэвис, эксперт по SQL-серверам, рекомендует использовать опцию CHECKSUM со всеми резервными копиями. Эта опция позволяет сделать дополнительную проверку, чтобы определить – не повреждена ли база данных. С этой опцией происходит проверка самих данных на предмет их повреждения, и в то же время проверяется и сама резервная копия, чтобы убедиться, что она не повреждена.
Большое преимущество использования CHECKSUM в том, что если файл резервной копии поврежден – операция восстановления немедленно даст ошибку. Это важно для тех случаев, когда операция восстановления может занимать часы – на очень больших наборах данных. Узнать, что файл резервной копии поврежден – это конечно плохо, но еще хуже узнать об этом же спустя два часа восстановления.
По материалам сайтов idera.com и sqlsoldier.com
Популярные услуги
Получить консультацию специалиста