Дублирование набора столбцов из одной таблицы в другую таблицу

Question

Мое требование - прочитать некоторый набор столбцов из таблицы. Исходная таблица имеет много - около 20-30 числовых столбцов, и я хотел бы прочитать только набор этих столбцов из исходной таблицы и продолжать добавлять значения этих столбцов в таблицу назначения. Моя БД находится на Oracle, а язык программирования - JDBC / Java.

Исходная таблица очень динамична - часто происходят вставки и удаления Это. Принимая во внимание, что в таблице назначения, я хотел бы сохранить данные по крайней мере 30 дней. Моя настройка описана ниже: База данных Oracle. Количество строк в исходной таблице = 20 миллионов строк с 30 столбцами Количество строк в таблице назначения = 300 миллионов строк с 2-3 столбцами

Все столбцы числовые.

Я имею в виду не делать открытое соединение JDBC и передавать данные, который может быть довольно медленным, глядя на размер таблиц. Я пытаюсь взять дамп выбранных столбцов исходной таблицы, используя некоторые sql like -

SQL> spool on
SQL> select c1,c5,c6 from SRC_Table;
SQL> spool off

А позже используйте SQLLoader для загрузки данных в базу данных назначения.

Исходная таблица хранит данные временных рядов, и данные удаляются / удаляются из исходной таблицы в течение 2 дней. Это часть среды OLTP. Таблица назначения имеет больший срок хранения - здесь можно хранить 30 дней данных, и это является частью среды OLAP. Таким образом, представление исходной таблицы, где представление выбирает только набор столбцов из исходной таблицы, в этой среде не работает. Любые предложения или комментарии по поводу этого подхода приветствуются.

EDIT Мои таблицы разделены. Самый простой способ копирования данных - обмен сетями разделов между таблицами

*ALTER TABLE <table_name>
EXCHANGE PARTITION <partition_name>
WITH TABLE <new_table_name>
<including | excluding> INDEXES
<with | without> VALIDATION
EXCEPTIONS INTO <schema.table_name>;*

но поскольку в моих исходных и целевых таблицах разные столбцы, я думаю, что раздел обмена не будет работать.

Answer 1

Шамик, хорошо, вы загружаете базу данных OLAP с данными OLTP.

Какова допустимая задержка? Нужны ли вашему OLAP сегодняшние данные до того, как люди придут в офис завтра утром, или это ближе к реальному времени?

Сказать, что вкладыши "частые", ничего не значит. Некоторые из нас привыкли к тысячам тксн / сек - для других 1 / сек - это много.

И вы говорите, что данных много. Та же идея Я читал пост людей, где у них ОГРОМНЫЕ таблицы с парой миллионов записей. у меня есть таблица с сотнями миллиардов записей. ТАК снова. Реальное число очень полезно.

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

Oracle предоставляет множество различных вариантов получения данных из OLTP в OLAP. Вместо того, чтобы изобретать велосипед, используйте что-то уже написанное. Oracle Streams был BORN , чтобы выполнить эту точную работу. Вы можете свернуть свои потоки с помощью Oracle AQ. Вставленные строки можно захватывать без триггера, используя уведомление об изменении базы данных или сбор данных об изменении.

Это чрезвычайно распространенная проблема, поэтому я перечислил 4 технологии, предназначенные для ее решения.

Расширенные очереди Streams Изменить захват данных Уведомление об изменении базы данных

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

Answer 2

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

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

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

Я готов предположить, что корень проблемы в том, что доступ к той информации, которую вы хотите получить из исходной таблицы, слишком медленный. Это говорит о том, что вы можете исправить это с помощью лучшей индексации. Кроме того, ваша исходная таблица, вероятно, слишком широка.

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

Answer 3

На тангенциальной ноте вы можете посмотреть на разбиение Oracle здесь и здесь .

Секционирование позволяет разбивать таблицы и индексы на более мелкие, более управляемые компоненты и является ключевым требованием для любой большой базы данных с высокими требованиями к производительности и высокой доступности. Oracle Database 11g предлагает широкий выбор методов разделения, включая интервал, ссылку, список и диапазон, в дополнение к составным разделам двух методов, таких как дата заказа (диапазон) и регион (список) или регион (список) и тип клиента (список) .

• Быстрее производительность - уменьшает время запроса с минут до секунд
• Увеличивает доступность - 24 к 7 доступ к критической информации
• Повышение управляемости - управление меньшими порциями данных
• Включает управление жизненным циклом информации - экономичное использование хранилища

Разделение таблицы на ежедневные разделы упростит архивирование, как описано здесь