Лучший способ/технология для реализации общего процесса архивирования

Мы стремимся удалить старые данные из хранилища Oracle.

Чтобы дать очень упрощенный обзор, было предложено разработать процесс с использованием хранимых процедур PL SQL, который с заданными параметрами исходной/целевой таблицы и т. д. использует представление Oracle ALL_TAB_COLUMNS для построения целевой таблицы, отражающей исходную таблицу.

Если целевая таблица существует из предыдущего запуска, предлагаемое решение включает сравнение текущей схемы исходной таблицы с целевой (архивной) таблицей и, при обнаружении различий, синхронизацию таблиц. Я уверен, что ограничения в предлагаемой функциональности существуют, но хотя спецификация в этой области выглядит довольно амбициозной, я сомневаюсь, что они собираются переписывать утилиту Red Gate SQL Compare на PL-SQL.

Думаю, у меня есть два вопроса.

1) Действительно ли PL/SQL подходит для такой задачи? Для меня хранимые процедуры используются для быстрого ввода и вывода данных, а сложная логика принадлежит тому, что я бы назвал более полнофункциональным клиентским языком, таким как C# или какой-либо другой язык .NET. Я ожидаю 10 000 строк, одну хранимую процедуру с плохим отступом, и я съеживаюсь от необходимости просматривать ее. Я знаю, что Oracle SP/Pkgs не обязательно должны быть такими, но по какой-то причине наши разработчики, как правило, менее модульны при использовании PL\SQL, чем при написании на .NET. Буду рад вашим рекомендациям и аргументам в пользу вашего выбора.

2) Существуют ли утилиты Oracle (думаю, у нас 10g), которые можно использовать для целей архивирования? У кого-нибудь есть какие-нибудь советы?

Я проголосую за любой неповторяющийся достойный комментарий.

Спасибо.


.net oracle plsql archiving
person Chad    schedule 24.09.2009    source источник

Ответы (5)


arrow_upward
1
arrow_downward

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

person APC    schedule 25.09.2009

arrow_upward
4
arrow_downward

PL/SQL предназначен НЕ только для операций с данными "быстрого ввода и вывода". Там очень существенные приложения, построенные на нем. В PL/SQL для такого рода задач нет ничего плохого. Тем не менее, если вы ожидаете плохо написанной 10-килобайтной процедуры на PL/SQL, не используйте ее. Позвольте вашим программистам делать то, что у них получается лучше всего.

person DCookie    schedule 24.09.2009

arrow_upward
3
arrow_downward

Во-первых, это звучит как задача для PL-SQL. Проблема немодульного кода может быть решена, и использование PL-SQL даст вам лучшие результаты и упростит написание.

Что касается самой концепции, любое решение, которое вы сделаете, будет иметь проблему, если схема будет обновлена ​​- синхронизация не удастся или, что еще хуже, не будет, и данные будут повреждены.

Как насчет сервера репликации, на котором вы добавляете «удаление старых записей» с основного сервера и выполняете вставку/обновление только на автономном сервере? Это позволит вам как иметь все данные, так и уменьшить размер живого.

person Amirshk    schedule 24.09.2009

arrow_upward
3
arrow_downward

Как бы вы ни «сделали это», это нужно будет сделать вручную.

Удаление данных в СУБД чревато опасностью. Потому что обычно вы не можете просто заархивировать одну таблицу. Вам также необходимо заархивировать все зависимые таблицы.

Тогда есть проблема изменения схемы. Не столько поддерживать синхронизацию вашего архива с вашей развивающейся схемой, сколько синхронизировать ваши инструменты с устаревшими схемами. Это не значит, что вы можете указать своим текущим приложениям «старые данные» и ожидать, что они обязательно будут работать. Достаточно сложно поддерживать актуальность ваших приложений с текущими данными, не говоря уже о том, чтобы они разумно вели себя со старыми данными.

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

Но после этого у вас будет намного больше контроля над тем, что и как данные экспортируются и объединяются.

Написать его на PL/SQL разумно просто потому, что это операция с базой данных. Зачем вытаскивать все данные с сервера только для того, чтобы запихнуть их обратно. Материал PL/SQL, вероятно, будет иметь лучшую общую производительность, когда все это будет сказано и сделано.

Что касается обеспечения модульности, отступа и т.д., ну для этого и были изобретены бейсбольные биты.

person Will Hartung    schedule 24.09.2009

arrow_upward
0
arrow_downward

Может быть, я не правильно читаю требования, но не будет ли простой

create <dest_table> as select * from <source_table>;

достаточно? с падением сначала на dest_table, если он уже существует?

person Venr    schedule 24.09.2009
comment
Вы не можете удалить целевую таблицу, если она уже существует, потому что она будет содержать все исторические, архивные данные, которые слишком стары для хранилища данных, но слишком хороши, чтобы их выбрасывать. - person Chad; 25.09.2009