Терабайт — не предел. Восстановление данных сверхбольшого объема на примере испорченной базы Microsoft SQL Server

[AbnormalHead]

Ну так и машина для восстановления использовалась не самая быстрая.
Замена процессора на xenon на 6-8 ядер позволила бы увеличить количество архиваторов без заметной потери производительности.
Увеличение памяти гиг до 32 и выше позволило бы обойтись без сбрасывания промежуточных sql скриптов на диск перед скармливанием их архиваторам. Достаточно сделать виртуальный RAM-диск, чтобы не менять программу.

И тогда бы мы приблизились к пределу в 6дней 8 часов.

[StasTs]

Это вообще достаточно забавная тема :) Во многих энтерпрайз приложениях база растет со временем. Так как это происходит постепенно, то размер так сильно не чувствуется. Но потом приходит время апргейда или сбой продукта или перенос на новое железо/версию базы и при этом иногда требуется пересоздать индексы. Вот тут и получается затык. Причем если с обычными индексами это время может часов, то с полнотекстовыми это может занимать дни или больше на больших базах. А это актуально, например телекоммуникационной компании с примерно 10м пользователей, база имейлов в саппорт растет около 2-4м сообщений в год (около 50-100гиг данных в год) которые надо полнотекстово индексировать.

[datacompboy]

А почему было просто не писать в bzip2 архивы через libpbz2? Одноврменно и многопоточность для ускорения записи, и не надо генерировать временный файл предварительно…

[mbozhenko]

Идея хорошая, но на тот момент мы взяли то, что «лежало ближе» — и получилась схема с временными файлами.
В следующий раз рассмотрим и этот вариант, спасибо.

[datacompboy]

Вот он, windows-подход :)
Куда уж ближе — берётся pbzip2, запускается, ему на вход кормится поток write'ами, он складывает результат в пакованный файл.
Просто использовать следует не zip а «поточный» архиватор.

К слову, даже в винде можно взять банальный rar:

    -si[name]
            Read data from stdin (standard input), when creating
            an archive. Optional 'name' parameter allows to specify
            a file name of compressed stdin data in the created
            archive. If this parameter is missing, the name will be
            set to 'stdin'. This switch cannot be used with -v.

            Example:

            type Tree.Far | rar a -siTree.Far tree.rar

            will compress 'type Tree.Far' output as 'Tree.Far' file.

И не нужны ни временные файлы, ни возня с библиотеками. Просто запустить процесс. Причем даже не надо будет разбираться с WinAPI, возьмите вот готовый: www.delphidabbler.com/software/consoleapp/main?mid=3.2

[mbozhenko]

На выбор метода также повлияло желание сделать удобнее обратный экспорт восстановленных данных из скриптов в базу. Поэтому zip, поэтому просто запакованные файлы.

[datacompboy]

ну и чем плох rar? он может писать и zip'ы (если брать winrar.exe а не rar.exe), внутри зипа будет именно один файл доступный для восстановления с нужным именем… Это просто запакованные файлы.

[codecity]

bzip2 вроде работает медленнее чем zip (хотя и жмет лучше). Выше написали более простой способ с виртуальным RAM-диском.

[datacompboy]

Во-1х, вы упёрлись не в CPU а в Disk IO. Во-2х, есть ключи -1..-9 для регулирования скорости.
Используя RAM диск вы опять создаёте лишние проблемы, плодя ненужные сущности.

[SlavaLukash]

Насколько восстановленные данные получились актуальными?
Допустим у нас есть две таблицы FioTable (ID, FIO) и EMailTable(ID, ID_FIO, Email). Связь один ко многим.
Ваша утилита восстановит все данные из таблицы EMailTable, но не восстановит часть данных из FioTable.
Какой прок от данных в EMailTable в таком случае?

[mbozhenko]

Не могу в точности ответить на этот вопрос — я не вникал в суть восстановленных данных и смысловые связи между таблицами.
Несомненно, часть данных была потеряна. Но для клиента утеря некоторой части данных была более приемлема чем недоступность всех данных в базе в принципе.