Я получил запрос на предоставление доступа к базе данных на 100 миллиардов записей в Oracle. К сожалению, оптимизация с использованием репликации невозможна, поэтому я думаю, что самым простым решением является создание новой базы данных Oracle и копирование всех данных, причем делать это один раз в день.
Какой сервер Oracle справится с этим хорошо? Есть ли что-то конкретное, о чем мне нужно позаботиться в этом отношении?
Недостаточно подробностей, чтобы дать качественный ответ, но я думаю, что «сервер» будет «серверами».
Если у вас есть 100000000000 записей по 100 байтов каждая, это 9 536 743 МБ в день без каких-либо случайных операций ввода-вывода для индексации и т. Д. Разделите это на количество секунд в день, и вы получите 110 МБ в секунду. Даже это предполагает равномерное распределение и полные 24 часа. Это примерно теоретический максимум для GigE.
Другими словами, вы собираетесь максимально увеличить «нормальную» пропускную способность и дисковый ввод-вывод даже с этими простыми предположениями.
Что-то мне подсказывает, что вы действительно хотите продумать этот дизайн.
Я думаю, что для такой работы стоит позвонить в Oracle ..
Я бы купил следующее;
HP DL795 G6 с 8 x 6-ядерными Opteron, памятью 64 ГБ +, 64-битным RedHat, двумя сетевыми картами Ethernet 10 Гбит / с, 2 контроллерами HP P800 SAS, подключенными локально к восьми MSA70, каждый из которых заполнен 25 дисками SAS 6 ГБ по 146 ГБ 2,5 дюйма 15 оборотов в минуту.
Я люблю исправлять проблемы с производительностью оборудования :)
Если это не поможет, вам придется пойти на что-то НАМНОГО дороже и / или разбить эту вещь.
Похоже, exadata v2 более чем легко справится со своей задачей. Видеть http://www.oracle.com/us/corporate/press/033684 и http://faisalgh.blogspot.com/2009/10/embarrassingly-fast-exadata-v2.html
Datapump. Распараллелить.
Если не репликация, как насчет резервной базы данных? Вы делаете копию один раз, а затем применяете изменения асинхронно, поэтому в случае сбоя резервного сервера основной ничего не чувствует. Вы получаете его только для чтения, но этого может быть достаточно.
Узнайте больше о данных - все они / какие-либо обновлены или только добавлены? Старайтесь избегать копирования записей, которые не изменились, если условие достаточно простое и записи не рассредоточены ...
Просто идеи ...
Когда вы выполняете массовую обработку, речь идет о байтах, а НЕ о количестве строк. Вы просто толкаете байты.
Этот вопрос немного расплывчатый. Я предполагаю, что вам нужно переместить данные из одной БД в другую, верно?
Это то, что я бы сделал (не зная фактического размера вашей базы данных и прочего)
создать базу данных и ссылку. СОЗДАЙТЕ ТАБЛИЦУ, КАК БЕЗ ВХОДА по ссылке, и посмотрите, сколько времени это займет. если этого достаточно. вы сделали. Как правило, это самый быстрый способ переместить данные. убедитесь, что не используете БЕЗ РЕГИСТРАЦИИ, иначе это будет медленнее. если таблица, которую вы читаете, секционирована, запросите ее с параметром parallel, если нет (ничего не сделает, если вы ее используете, если она не секционирована).
Переносное табличное пространство. Поищи в Гугле. ваша таблица должна быть схемой, полностью содержащейся в табличном пространстве. Вам также потребуется доступ к sysdba (это должен сделать пользователь oracle). для этого требуется сценарий оболочки и больше кода, чем вариант 1.
насос данных
В этой последовательности. Материализованные представления требуют больших объемов данных и полностью обновляются. Создание таблицы НАМНОГО быстрее. используйте вариант №3 только в том случае, если вы не можете удовлетворить требования переносимого табличного пространства.
Я загружал большие объемы данных в день. в терабайтном диапазоне.