Резервное копирование базы данных / Процесс Восстановления
Другое событие NullPointerException возникает, когда объявляется массив объектов, а затем сразу же пытается разыменовать его внутри.
String[] phrases = new String[10];
String keyPhrase = "Bird";
for(String phrase : phrases) {
System.out.println(phrase.equals(keyPhrase));
}
Этот конкретный NPE можно избежать, если порядок сравнения отменяется ; а именно, использовать .equals для гарантированного непустого объекта.
Все элементы внутри массива инициализируются их общим начальным значением ; для любого типа массива объектов, это означает, что все элементы null.
Вы должны инициализировать элементы в массиве перед доступом или разыменованием их.
String[] phrases = new String[] {"The bird", "A bird", "My bird", "Bird"};
String keyPhrase = "Bird";
for(String phrase : phrases) {
System.out.println(phrase.equals(keyPhrase));
}
3 ответа
Я использовал подобный шаг для хранения dev/test/QA баз данных 'ступившими нулем' на ночной основе для разработчиков и людей QA для использования.
Документация является ключом - если Вы хотите удалить то, что Scott Hanselman называет 'фактором шины' (т.е. опасность, что создатель системы будет поражен шиной, и все начинает сосать).
Тем не менее для нормальных резервных копий базы данных и планов аварийного восстановления, я нашел тому SQL Server работу Планы технического обслуживания вполне прилично. Пока Вы включаете: 1) Достойная документация 2) Стандартное тестирование.
Я обрисовал в общих чертах некоторые способы пойти о выполнении этого (для любого привлеченного к этому вопросу, ища пример того, как пойти о создании плана аварийного восстановления):
Резервные лучшие практики SQL Server (бесплатное учебное руководство/Видео)
Ключевая роль Вашего вопроса является способностью к решению для резервного копирования, которое будет управляться не-DBA. Любой собственный ответ SQL Server как резервные сценарии не собирается удовлетворять те потребности, потому что резервные сценарии требуют знания T-SQL.
Из-за этого Вы хотите смотреть на сторонние решения как те, Mitch Wheat упомянул. Я работаю на Quest (производители LiteSpeed) поэтому, конечно, я неравнодушен к тот одному - легко показать non-DBAs. Прежде чем я покинул свою последнюю компанию, у меня была десятиминутная сессия, чтобы показать системным администраторам и разработчикам, как консоль LiteSpeed, обработанная, и это было этим. Они не звонили с тех пор.
Другой подход использует то же программное обеспечение для резервного копирования, которое использует остальная часть Вашего магазина. TSM, Veritas, Backup Exec и Microsoft DPM, у всех есть агенты SQL Server, которые позволяют Вашим администраторам Windows справиться с процессом резервного копирования с различными степенями простоты в употреблении. Если Вы действительно хотите, чтобы не-DBA управлял им, это - вероятно, самый очень легкий способ сделать это, хотя Вы жертвуете большой производительностью, которую определенные для SQL резервные инструменты дают Вам.
Я делаю точно то же самое и имею различные проблемы, полу регулярно даже с этим процессом.
Как Вы обрабатываете интервал между копированием файла с Сервера к Серверу B и восстановлением транзакционного резервного копирования на Сервере B.
Время от времени резервное копирование транзакции больше, чем нормальный и занимает более длительное время для копирования. Задание восстановления затем получает ошибку операционной системы, что файл используется.
Это не такое грандиозное предприятие, так как файл автоматически применяется в следующий раз вокруг однако, было бы более хорошо иметь более изящное решение в целом и то, которое конкретно устраняет эту проблему.