Я работаю над очень большой базой данных (250+ гигабайт) с более чем 225 миллионами записей. С базой данных трудно работать просто из-за ее размера. Эта база данных будет использоваться только для чтения.
Мы ищем более быстрое оборудование, но в любом случае я пытаюсь найти наиболее эффективный способ работы с базой данных. Эта база данных должна обновляться каждую ночь из главной базы данных, а время простоя должно быть сведено к минимуму. Главная база данных поддерживается третьей стороной.
Я пытаюсь найти лучший способ эффективного обновления базы данных каждую ночь, но мне не очень везет. Я рассматривал дифференциальные и транзакционные резервные копии журнала, но для того, чтобы применить любой из них, сначала нужно восстановить полную резервную копию базы данных. В моем случае это полностью сводит на нет смысл дифференциальной резервной копии, поскольку она не сэкономит мне время [простоя]. Я мог бы также делать полную резервную копию главной базы данных каждую ночь, а затем просто восстанавливать полную резервную копию, и это было бы быстрее.
Я надеялся найти решение, при котором я мог бы сделать полную резервную копию один раз (или, может быть, раз в месяц), а затем с этого момента просто применять какой-то тип инкрементальных резервных копий (основанных на исходной полной резервной копии), которые надстраиваются друг над другом. Это свело бы время простоя к минимуму, поскольку после того, как будет сделана первая полная резервная копия, я бы применял инкрементальные резервные копии только каждую ночь. Я бы просто перестраивал индекс после каждой «инкрементальной» резервной копии для скорости. Мне не удалось найти действительно работающее решение, подобное этому.
Я пробовал сделать полное восстановление WITH STANDBY на тестовой базе данных, и таким образом я мог запросить данные, а затем позже все еще применять журнал транзакций и только журнал транзакций. Это был несколько ограниченный успех, так как я не могу делать такие вещи, как добавление индекса, поскольку технически это запись в базу данных. Однако это очень близко к тому, что я ищу, так как сами данные будут только для чтения. Есть ли какое-либо решение, предназначенное для работы таким образом? Я бы предпочел избегать делать это с опцией STANDBY, поскольку она не предназначена для использования таким образом.
Я только сейчас погружаюсь и провожу много исследований в области резервного копирования и производительности баз данных, постоянно читаю MSDN, однако, похоже, это решение не вариант. Я подумал, что спрошу в крайнем случае — наверняка здесь есть те, кто управляет большими базами данных, где было бы непрактично делать восстановление каждую ночь.
Есть предложения? Я также открыт для предложений/ссылок на страницы по производительности, так как я никогда не работал с базой данных такого размера.
Боюсь, что единственным ответом может оказаться репликация.
решение1
Доставка журналов удовлетворяет нашу потребность в сохранении основной (300 ГБ) базы данных доступной с журналами, отправленными в резервную копию на другом сервере. Журналы транзакций применяются каждые 15 минут. Наша отчетность использует резервную копию.