oracle golden gate что это

Золотые ворота: как реплицировать терабайт в час, или Опыт использования CDC на GoldenGate в ВТБ

Анализировать данные в реальном времени можно разными способами. В ВТБ мы используем технологию Change Data Capture (CDC), реализованную в инструменте Golden Gate Oracle: для нас очень важна скорость, при этом хотелось бы уменьшить объем передаваемых данных и снизить нагрузку на источник. И хотя основная сфера применения этого инструмента — репликации из Oracle и MS SQL, за несколько лет работы с CDC у нас накопилось несколько интересных кейсов, наподобие миграции данных между платформами или разными типами СУБД. Под катом мы поделимся нашим опытом работы с Golden Gate.

Зачем нам понадобилась CDC (Change Data Capture)

Повседневное применение банковских карт давно стало привычным, и люди, как правило, не задумываются, что каждое использование платежного терминала — это оперативная передача в банк определенной информации. Объемы данных растут, при этом обрабатывать их хотелось бы как можно быстрее, в том числе чтобы отправлять спецпредложения в реальном времени, ведь, как говорится, хороша ложка к обеду. И совсем не так хороши для обработки данных на лету традиционные инструменты ETL (extract, transform, load — извлечение, преобразование, загрузка). Вот одно из слабых звеньев: когда данные забираются из таблиц системы источника, необходимо выбрать только новые строки или строки с изменениями. Такой подход дополнительно нагружает систему-источник и увеличивает объем передаваемых данных.

CDC же в режиме реального времени захватывает изменения из журналов базы данных. Так источник нагружается гораздо меньше, да и объем передаваемых данных сокращается. С этой технологией мы снизили потребность в вычислительных ресурсах для систем с большим объемом транзакционных изменений: ведь для захвата данных даже для самых высоконагруженных банковских систем достаточно 1–2 ядер процессора на источнике. А если бы мы внедряли ETL, то потребовалось бы докупать процессорные емкости, чтобы вычитывать данные в параллели.

В ВТБ мы уже несколько лет используем технологии Oracle GoldenGate — инструмент CDC от Oracle. С его помощью мы наполняем оперативное хранилище данных и разносим функции информационных систем на «теплые» и «горячие» зоны. 90% применения OGG в ИТ-ландшафте банка — загрузка данных из Oracle и MS SQL, но, кроме репликации, он отлично справляется с другими задачами. Давайте рассмотрим несколько примеров из нашей практики.

Кейс 1. Подготовка оперативной отчетности онлайн

Мы познакомились с GoldenGate в 2013 году. Тогда на нашем комплексе карточного процессинга одновременно обрабатывались транзакции и готовились отчеты. OLTP-нагрузка смешивалась с DWH/DSS-нагрузкой, и большие тяжелые выборки «вымывали» кэш из памяти базы данных. В результате быстрым транзакциям приходилось обращаться к жесткому диску, скорость работы критичных бизнес-сервисов падала. Чтобы разгрузить ядро процессинга, мы вынесли все разработанные нами процедуры и отчеты на «теплую» реплику на Oracle Exadata.
Как реплицировать данные с помощью GoldenGate, мы подробно рассказывали здесь. В двух словах: для высоконагруженных систем, где есть микширование разных типов нагрузки, мы разносим по разным серверам OLTP и DWH/DSS, а для синхронизации между ними используем GoldenGate. Эта схема выделения «теплой» реплики пригодилась нам во многих других кейсах. Например, тот же подход применили в нашей системе противодействия мошенничеству — всю подготовку отчетности выносим на интегрированные системы Oracle Exadata, данные реплицируем на них с помощью GoldenGate.

Систем без сбоев не бывает. Например, если разработчик изменит данные на приемнике, то может возникнуть ошибка применения данных, и процессы GoldenGate остановятся. Чтобы исключить рассинхронизацию данных, в качестве независимого арбитра мы используем Oracle GoldenGate Veridata. Этот инструмент не просто верифицирует данные между источниками и приемниками — главное, что Veridata устраняет возникшие расхождения. Важно, что когда мы имеем дело с репликацией, Veridata гарантирует точное сравнение данных и выявление потерянных записей. Мы получаем полный отчет с результатами сравнения, который можно предъявить недоверчивым коллегам.

Кейс 2. Консолидированная отчетность и staging в оперативном хранилище

Отдельный кейс связан со строительством оперативного хранилища. Сложность состоит в том, что, помимо оперативной отчетности, у нас готовятся данные для корпоративного хранилища (staging). Бывает, что надо сформировать оперативную отчетность на основании данных, которые собираются из ряда различных систем. И удобнее всего делать это на уровне оперативного хранилища. Для получения данных на большой скорости и с минимальной нагрузкой на ресурсы мы в очередной раз применили GoldenGate.

Для сравнения поясним, как мы находили дельту изменений в некоторых наших системах раньше. Если система сама не позволяла выделять дельту или меняла данные задним числом, то таблица из источника в 10 ТБ сравнивалась с таблицей 10 ТБ на приемнике за предыдущий день. Эти 10 ТБ надо было сначала захватить на источнике, и нагрузка ложилась не только на систему-источник, ЦПУ, память, но и на сети передачи данных, а также на систему, занимающуюся сравнением. И все это ради того, чтобы найти дельту новых данных в 0,01%!

GoldenGate не создает практически никакой нагрузки на источник: CDC просто читает журналы и выдает готовую дельту. Это позволяет серьезно сэкономить на инфраструктуре. При этом не имеет значения, кто является приемником — традиционное хранилище на базе продуктов Oracle, MSSQL, Teradata или просто Hadoop.

Отметим, что в этом кейсе в качестве источника и приемника применялись базы данных Oracle. Решение показало свою эффективность, так что сейчас мы подключаем все новые системы к общему оперативному хранилищу данных, и теперь это не только Oracle. Еще один плюс GoldenGate в том, что он подходит для загрузки данных из большинства используемых баз данных в ИТ-ландшафте банка.

Кейс 3. Персональные предложения клиентам в реальном времени

Мы уже упоминали о потоковой аналитике, то есть о предложениях клиентам в реальном времени — Real-Time Offering (RTO). Старшие товарищи говорят, что успех в банковском бизнесе напрямую зависит от того, как хорошо вы знаете своего клиента и насколько актуальное предложение можете ему сделать. Другими словами, вероятность того, что клиент воспользуется предложением банка, обратно пропорциональна скорости реакции банка на потребности клиента.

Как это работает? Например, история транзакций показывает, что клиент каждую пятницу закупается в винном магазине. Геопозиционирование засекает его в торговом центре, где есть магазин этой сети, и мы через мобильное приложение направляем ему персональное предложение на скидку в магазин деликатесов в том же ТЦ. Для банка такой кейс наиболее интересен, он позволяет создавать ко-бренды и совместные предложения. Клиентами могут быть физические лица и организации.

Здесь есть офлайн- и онлайн-части. В первой клиентов предварительно сегментируют, используя данные всех систем. Аналитики и data-сайентисты изучают поведение, исторические данные и создают так называемые ловушки. Главное — поймать значимое событие, которое может быть отслежено по транзакции эквайера, мобильному приложению или другим доступным источникам. И уже это событие обрабатывается средствами потоковой аналитики, а решение принимается в моменте на основании заготовленных ловушек.

Задача CDC GoldenGate — обеспечить поток данных о событиях в реальном времени из систем-источников на аналитическую платформу. Кроме того, в состав лицензии GoldenGate for Big Data входит Oracle Stream Analytics. С его помощью data-сайентисты могут самостоятельно обрабатывать поток данных на Spark Streaming, разрабатывая приложение в визуальной среде.

Кейс 4. Оперативное противодействие новым видам мошенничества

Антифрод-системы достаточно закрыты, и это правильно: чем меньше людей посвящено в детали, тем выше безопасность. Они отлично справляются с обработкой стандартных кейсов, но иногда возникают ситуации, которые в стандартные скрипты не вписываются. Поэтому важно дополнять эти модели нестандартными сценариями. Мы постоянно разрабатываем новые модели, базирующиеся на корреляции событий различных систем: карточных и валютных операций, местоположения, операций платежных систем, действий в мобильных приложениях, мониторинга социальных сетей. Для изменения модели приходится следовать принятым процессам: business request, постановка задач, прохождение заявки через все внутренние этапы реализации.
В прошлом году мы протестировали заливку данных с использованием Oracle GoldenGate for Big Data из наиболее загруженных традиционных систем, где было очень много мелких транзакций, и из нашей системы антифрода в основной кластер на Oracle Big Data Appliance. И Hadoop, и GoldenGate справились с объемом передаваемых данных — нас это несколько удивило.

Источник

Аналитические системы

Обратная связь

Веб-форма не найдена.

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

Обеспечение высокой доступности для критических систем

Oracle GoldenGate может быть сконфигурировано, чтобы использоваться в следующих сценариях:

Интеграция данных всего предприятия в реальном времени

Oracle GoldenGate в режиме реального времени собирает измененные данные и доставляет их в Хранилище Данных, отчетные системы и другие транзакционные системы с минимальным воздействием на производительность систем-источников. Доступ к информации в реальном времени дает лучшее понимание происходящих в компании бизнес-процессов.

Ключевые особенности и выгоды Oracle GoldenGate

Использование Oracle GoldenGate обеспечивает следующие возможности и преимущества:

Oracle GoldenGate помогает организациям сохранять существующие инвестиции в ИТ и улучшать операционную деятельность бизнес-подразделений за счет обеспечения постоянного доступа к критически важной информации в режиме реального времени.

Благодаря поддержке разнообразных интеграционных сценариев, Oracle GoldenGate обеспечивает надежную основу для решения актуальных задач информационного обмена в современных организациях.

Источник

1 Introduction to Oracle GoldenGate

Oracle GoldenGate is a software product that allows you to replicate, filter, and transform data from one database to another database.

Enterprise data is typically distributed across the enterprise in heterogeneous databases. To get data between different data sources, you can use Oracle GoldenGate to load, distribute, and filter transactions within your enterprise in real-time and enable migrations between different databases in near zero-downtime.

To do this, you need a means to effectively move data from one system to another in real-time and with zero-downtime. Oracle GoldenGate is Oracle’s solution to replicate and integrate data.

Oracle GoldenGate has the following key features:

Data movement is in real-time, reducing latency.

Only committed transactions are moved, enabling consistency and improving performance.

Different versions and releases of Oracle Database are supported along with a wide range of heterogeneous databases running on a variety of operating systems. You can replicate data from an Oracle Database to a different heterogeneous database.

Simple architecture and easy configuration.

High performance with minimal overhead on the underlying databases and infrastructure.

Oracle GoldenGate meets almost any data movement requirements you might have. Some of the most common use cases are described in this section.

You can use Oracle GoldenGate to meet the following business requirements:

Business Continuity and High Availability

Consider a scenario where you are working in a multinational bank that has its headquarters in London, UK. You work in one of the banks’ branches in Bangalore, India. This bank uses a specific account for its financial application that is used globally at all the branches. You have been asked by your manager to daily synchronize the transactions that have happened for this account in the database in the Bangalore branch with the centralized database situated at the UK. The volume of transactions is massive, and even the slightest delay can greatly impact the business. This same process is required at multiple destinations for every database in all the branches of the bank worldwide. This process has to be monitored continuously, preferably through some sort of GUI-based tool for the ease of management. Additionally, the bank has several other, non-critical applications used at all the branches. These applications are based on heterogeneous databases, such as MySQL, but the transactions done over these databases also must be loaded into an Oracle Database located at the headquarters. The replication technology used must support both Oracle and heterogeneous databases so that they can talk to each other. Oracle GoldenGate is an apt solution in such a scenario.

Initial Load and Database Migration

Initial load is a process of extracting data records from a source database and loading those records onto a target database. Initial load is a data migration process that is performed only once. Oracle GoldenGate allows you to perform initial load data migrations without taking your systems offline.

Data integration involves combining data from several disparate sources, which are stored using various technologies, and provide a unified view of the data. Oracle GoldenGate provides real-time data integration.

Источник

Опыт использования решения Oracle GoldenGate

Время просмотра: 6.2 мин.

Oracle GoldenGate – это не просто решение по репликации данных, а решение для создания real-time-приложений. GoldenGate обеспечивает сбор, маршрутизацию, преобразование и доставку транзакционных данных между гетерогенными средами в реальном времени c минимальной дополнительной нагрузкой. Данное решение можно использовать для построения сложной отчетности или как исходную систему для ETL (система выгрузки, загрузки и преобразования данных). При этом GoldenGate имеет широкие возможности интеграции c Oracle Data Integrator, расширяя функциональность последнего.

Другие статьи автора

Статьи по теме

Поделиться

Немного практики, или с чего все начиналось?

До момента запуска решения процесс обеспечения данными бизнес-аналитиков заказчика выглядел приблизительно так:

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

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

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

Ниже мы расскажем о принципах работы GoldenGate и нашем опыте его настройки.

Принцип работы GoldenGate

Рисунок 1. Схема работы GoldenGate

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

После запуска программного обеспечения на источнике стали собираться изменения из redo-log- или archive redo-log-файлов, пересылаться посредством так называемых передаточных trail-файлов на сервер-приемник и применяться в базе аналитической системы.

Вся прелесть GoldenGate заключается в том, что для получения данных он использует журналы повторного выполнения. Никаких запросов к базе, никаких триггеров и т.д. Нагрузка на источники минимальна! Для особо требовательных систем есть режим downstream, снижающий нагрузку на исходную систему практически до нуля.

Этапы использования GoldenGate

Отчетность

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

Несмотря на то что GoldenGate отлично реплицирует данные, когда структуры источника и приемника различаются, нужно учитывать, что это все же не ETL/ELT-инструмент, хотя на нем можно решать некоторые подобные задачи. И здесь нам на помощь пришла интеграция с полноценным и мощным ELT-инструментом все того же производителя – Oracle Data Integrator. Связка этих двух «монстров» позволила нам решить задачи по формированию любых форматов отчетности.

Итогом стало то, что бизнес получил обновляемую в режиме реального времени отчетно-ориентированную базу данных (с дополнительными индексами, секциями, денормализованными сущностями), которую можно использовать для быстрого выполнения запросов аналитиков и формирования отчетов.

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

Хранилище данных

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

Но как получать данные для хранилища, да еще в режиме реального времени? Триггеры отпадают сразу же. Включать штатное логирование изменений на источнике не всегда возможно, да и накладно это по ресурсам – это могут позволить не все системы.

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

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

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

Хранилище данных есть, онлайн-отчетность есть!

Данные времени выполнения

Но как быть, спросите вы, если представители заказчика хотят получать данные о времени выполнения определенных действий? В нашем случае это касалось, в частности, заявок на кредиты. Сотрудник заказчика работал с информацией по заявке на кредиты, момент работы фиксировался в одном из полей USER_ID, но информации о дате начала и окончании работы не было. Иногда поле USER_ID дополнялось полем «дата модификации» UPD_DT. Но данная ситуация приводила к тому, что нельзя было однозначно рассчитать KPI работы сотрудников и выявить причины зависания заявок на определенных шагах и/или этапах прохождения заявки.

Рисунок 2. Прием работы с заявкой

Кроме этого, заявки время от времени передавались другим сотрудникам. Значения полей USER_ID, UPD_DT менялось на нового сотрудника и дату изменения, без сохранения истории о предыдущем сотруднике. Казалось бы, дата изменения была, сотрудник тоже был указан, все можно получить. Дело в том, что между интервалами загрузки данных в BI может происходить несколько изменений, и тогда промежуточные изменения будут потеряны. Уменьшение интервалов загрузки тоже не помогало, так как заявка могла переходить от сотрудника к сотруднику несколько раз в течение нескольких секунд.

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

Вернемся к заявке… той, дополнительно полученной информацией было время работы сотрудника с заявкой, его напрямую можно было использовать при расчете KPI сотрудников и для выявления причин длительных интервалов в работе с заявкой. Не этого ли добивался бизнес? Уменьшения времени обслуживания и устранения неэффективных этапов…

Бывалые знатоки репликации вспомнят еще один инструмент от Oracle – Oracle Streams. Конечно, определенный функционал GoldenGate можно повторить на Oracle Streams, но Oracle перестал развивать этот продукт, сделав ставку на GoldenGate, перенеся наработки Streams в ядро GoldenGate.

Описанные выше показатели времени выполнения есть не только у заявок. У многих других сущностей также можно найти такие нюансы сохранения информации (работа выездной бригады по устранению неполадок, работа менеджера продаж по заявкам) опять-таки по причине того, что архитектура OLTP-системы не всегда подразумевает сохранение истории изменений.

Рисунок 3.Работа сотрудников с заявками через GoldenGate

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

С помощью решения GoldenGate мы смогли не только решить технологическую задачу онлайн-репликации, но и обеспечили реализацию крайне актуальной потребности для бизнеса – предоставили быстрый и мощный инструмент для обработки данных и дополнительной аналитики. Конкурирующих продуктов по производительности, особенно при работе с базами данных Oracle, у него практически нет.

Источник

Русские Блоги

Oracle GoldenGate I. Введение и установка

Эта статья воспроизводится:https://www.cnblogs.com/lanston/p/ogg_instrAndInstall.html#_label3

Oracle GoldenGate I. Введение и установка

Чтение навигации

1 Описание

1.1 Загрузка и документация

1.2 Описание ресурса

1.3 Описание компонента

Процесс Manager должен выполняться на исходной и целевой сторонах и запускаться до процессов извлечения и репликации. Без этого OGG не может выполнять другие операции. Он управляет и запускает процесс Oracle GoldenGate, запускает динамические процессы, выделяет порты для процесса GoldenGate и управляет файлами трассировки. Создание отчетов о событиях, ошибках и диагностике;

Извлечение выполняется в источнике или может выполняться одновременно на обоих концах в соответствии с системными и бизнес-требованиями для извлечения и сбора данных об изменениях системы, его можно настроить для инициализации загрузки данных (загрузки статических данных непосредственно из источника данных) и в определенный момент После того, как сторона источника синхронизирует данные изменений со стороной сервера (извлекает собранные данные изменений из сетевых журналов или архивных журналов), она также может извлекать и захватывать DDL в системах, которые поддерживают изменения DDL;
При настройке для синхронизации данных процесс извлечения извлекает все операции DML и DDL (требуется дополнительная настройка), которые захватывают объекты, настроенные в файле конфигурации извлечения, и процесс извлечения записывает эти операции до тех пор, пока пользователь не отправит Или откат транзакции: при получении отката извлечение аннулирует эти записи, после получения операции (фиксации) запись процесса извлечения сохраняет эти операции в один или несколько файлов трасс и отправляет их в очередь. Целевой конец для обеспечения скорости передачи данных и согласованности данных.

Data Pumps является вторым типом конфигурации извлечения GoldenGate. Если Data Pump не используется, процесс извлечения должен отправить записанные данные операции на целевой трейл. Если Data Pump настроен, процесс извлечения извлекает захваченные данные и записывает их в трейл. Прочитайте след и отправьте след к целевому следу через сеть. Насос данных повышает доступность источника и цели извлечения и захвата данных. Основными преимуществами являются: 1. Защита от сбоя передачи сети и отказа цели; 2. Реализация сложной фильтрации данных И преобразование; 3. Может объединять несколько источников данных в пункт назначения; 4. Может синхронизировать один источник данных с несколькими пунктами назначения.

Процесс Replicat запускается на целевой стороне для чтения файла хвостовой части, восстановления DML и DDL и применения его к целевой базе данных. Replicat компилирует SQL один раз и повторно использует скомпилированный SQL, когда значения переменных различаются. Процесс Replicat может быть настроен для инициализации загрузки данных, как процесс извлечения (Загрузка статических данных непосредственно из источника данных) и синхронизация данных об изменениях источника и сервера через определенный момент времени (извлечение измененных данных из онлайн-журнала или архивного журнала);

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

Сборщик является фоновым процессом на целевой стороне.По умолчанию исходный процесс извлечения инициализирует соединение TCP / IP с процессом сборщика на целевой стороне, но, поскольку GoldenGate настраивается, может потребоваться настроить и инициализировать сборщик на целевой стороне. Синхронизируйте часовой пояс, но часовой пояс источника меньше, чем часовой пояс цели. Функция сборщика: 1. В соответствии с запросом процесса извлечения на стороне источника просканируйте и свяжите доступные порты с основным процессом mgr и назначьте его запрошенному процессу извлечения 2. Получите извлечение на стороне источника для извлечения следа и запишите его в файл следа на целевой стороне; Когда источник отправляет сетевой запрос, mgr автоматически запускает фоновый процесс сборщика, поэтому пользователи GoldeGate не могут с ним взаимодействовать. Сборщик может принять только одну информацию процесса извлечения (один к одному) одновременно и завершиться с прекращением извлечения.

2 Настройки переменных каталога и среды

Для эксперимента установите исходный конец в каталог / u01 / app / product / ogg_src на том же компьютере и установите конечный конец в каталог / u01 / app / product / ogg_trg в качестве примера;

Чтобы установить GoldenGate в Linux, настройте ORACLE_SID, ORACLE_HOME и LD_LIBRARY_PATH;

Примечание. Тип бита версии операционной системы, версии базы данных и версии Oracle GoldenGate должен быть одинаковым: все 32-разрядные или все 64-разрядные;

3 Установите GoldenGate

3.1 Установка GoldenGate у источника

Выберите соответствующую опцию GoldenGate в соответствии с версией базы данных;

Измените место установки программного обеспечения GoldenGate, установите его в каталог / u01 / app / product / ogg_src, проверьте правильность расположения установки базы данных и настройте порт;

Проверьте информацию об установке и запустите установку после подтверждения ее правильности;


На этом установка исходного кода завершена.

3.2 Установить GoldenGate на цель

Исходная команда OGG ggsci sggsci конфигурируется описанным выше методом псевдонима, целевая команда OGG ggsci tggsci и rlwrap позволяют ей поддерживать функцию обратной записи, так что команда OGG ggsci может использоваться в любой позиции;

В этой версии по умолчанию автоматически создаются подкаталоги, поэтому более ранние версии, возможно, придется создавать вручную с помощью команды create subdirs в командной строке GGSCI; убедитесь, что процесс mgr должен быть запущен после завершения установки;

4 Структура каталогов GoldenGate

5 Резюме

Источник