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