#sql #database #shrink
Вопрос:
Я хотел бы понять, каковы недостатки следующего сценария:
Предположим, у меня есть база данных «A», которая используется для получения данных откуда-то (скажем, CSV-файл), а затем эти данные передаются в какую-то другую базу данных «B». Все они (CSV, A, B) размещены на одной машине, с одним диском для использования. Теоретически на моем диске всего 10 ГБ свободного места.
Предположим, что CSV имеет 5 ГБ, и те же данные используют 5 ГБ в базе данных «A» (я не использую сжатие). Это означает, что когда файл CSV находится на диске и «A» загружен, весь диск объемом 10 ГБ заполнен. Когда я захочу перенести данные из «A» в «B», я удалю CSV, чтобы 5 ГБ было пусто, а затем я заполню «B», чтобы снова весь диск был заполнен.
Предположим, у меня есть новый CSV-файл и мне нужно сохранить данные в «В», я хотел бы уменьшить размер «А», но сохранить всю структуру «А», а также права и т. Д.. Очевидная возможность состоит в том, чтобы использовать усечение, а затем сжатие, но опять же, мне нужна только структура «А» и пустые таблицы. Сжатие занимает много времени для обработки, приводит к фрагментации, и из-за этого индексы со временем растут.
Можно ли было бы иметь пустую (без данных, но уже с таблицами, процедурами, правами и т. Д.) резервную версию «А», Которую я бы использовал таким образом, чтобы удалить весь «А» и восстановить его из резервной копии, а не усекать все таблицы в «А» и сжимать его?
Каковы недостатки этого мышления? Может ли резервная копия содержать все права и подключения, которые были связаны с исходной базой данных «А»?
Комментарии:
1. Да, вы можете восстановить базу данных шаблонов из резервной копии. Но зачем создавать эту проблему, возясь с 10 ГБ пространства? Я держу в руках свой телефон на 128 ГБ, я могу купить терабайтный накопитель практически за бесценок. Просто купите диск побольше и потратьте свое время на реальные проблемы!
2. Это теоретический вопрос, так что я могу сделать простые примеры вычислений, на самом деле в моей базе данных более 8 ТБ места, и усечение сокращение сэкономит примерно 2 ТБ после каждой итерации. Мой клиент в данный момент не хочет выделять больше места. Также из-за реального размера проблемы, я думаю, что удаление и восстановление сэкономят гораздо больше времени.
3. Еще одна мысль, которую следует учитывать — 8 ТБ может показаться не так много, но в корпоративном приложении это на самом деле много — не только то, что это SSD, но реализация еще 2 ТБ на самом деле не означает 2 ТБ в целом, поскольку у вас есть несколько сред, с которыми это связано, а также многие другие ограничения, которые есть на самом предприятии.
4. Восстановление резервной копии пустой базы данных по умолчанию-это нормально, если вам это нужно, резервная копия содержит все свойства, метаданные, разрешения и т. Д., Поэтому это жизнеспособный вариант «сброса».
5. Повлияет ли восстановление каким-либо образом на другие решения, подключенные к этой базе данных? Я имею в виду не время, в течение которого база данных будет удалена и восстановлена, а скорее после ее восстановления — сохраняет ли восстановленная база данных ту же информацию о подключении, правах доступа и т. Д.?