Використовуєте Oracle Advanced Queuing? Міграція до TxEventQ забезпечить підвищену продуктивність та надійність. - javascript.org.ua

База даних Oracle має довгу історію роботи з чергами повідомлень, починаючи з введення Advanced Queuing в Oracle Database 8 ще в 1997 році. Можливості для обміну повідомленнями в Oracle Database розвивалися протягом років і тепер підтримують Транзакційні черги подій (Transactional Event Queues) і парадигму потокового обміну подіями з API для популярних мов програмування, таких як Java, Python, Javascript, C, .Net і PL/SQL. Kafka Java API були представлені через Kafka Java Client для Oracle Transactional Event Queues, а підтримка REST можлива через Oracle REST Data Services (ORDS). Рекомендується міграція з AQ на TxEventQ для користувачів, щоб скористатися підвищеною продуктивністю, надійністю та масштабованістю TxEventQ: високопродуктивні установки TxEventQ тестувалися на швидкості до 1 мільйона повідомлень на секунду на 8-вузловій Oracle RAC Database.

Ця стаття описує процес міграції з AQ за допомогою пакету DBMS_AQMIGTOOL для перетворення класичних черг в TxEventQ. Наприкінці статті ви повинні зрозуміти процес міграції, процедури в пакеті DBMS_AQMIGTOOL, а також обмеження, пов’язані з міграцією.

Огляд DBMS_AQMIGTOOL

Інтерфейс інструменту міграції надає наступні функції:

Міграція може бути виконана в режимах AUTOMATIC, INTERACTIVE, OFFLINE або ONLY_DEFINITION, кожен з яких має свої конкретні випадки використання та переваги.

DBMS_AQMIGTOOL.AUTOMATIC: Операції enqueuing (додавання в чергу) та dequeuing (вилучення з черги) дозволені під час міграції, а фонове завдання завершить міграцію після того, як черга буде порожня і не виявлені несумісні функції.

DBMS_AQMIGTOOL.INTERACTIVE (За замовчуванням): Операції enqueuing та dequeuing дозволені, і користувач повинен самостійно зафіксувати міграцію.

DBMS_AQMIGTOOL.OFFLINE: Під час міграції дозволені тільки операції dequeuing, що допомагає вивантажити чергу AQ.

DBMSAQMIGTOOL.ONLYDEFINITION: Створюється копія TxEventQ з конфігурації AQ, при цьому повідомлення не мігруються. Як AQ, так і TxEventQ залишаються в системі після завершення міграції з окремими потоками повідомлень. Цей варіант рекомендується користувачам, які бажають більш ручну або кастомізовану міграцію.

Користувачі можуть вирішити зафіксувати міграцію або відновити AQ через інтерфейс міграції.
Під час міграції можна відслідковувати повідомлення, що знаходяться в обробці, переглядаючи повідомлення, які не перебувають у стані PROCESSED для обох черг — AQ і TxEventQ.
Для всіх черг зберігається історія міграцій.
Користувачі можуть додатково очистити старі повідомлення AQ, якщо вони хочуть викинути ці дані після міграції.
Міграція з AQ підтримує як поетапні оновлення, так і реплікацію через Oracle GoldenGate (OGG).
Під час онлайн-міграції додаткам безпечно продовжувати операції enqueue/dequeue як зазвичай.

Робочий процес міграції

Перевірте сумісність міграції та ознайомтесь з обмеженнями та обхідними шляхами, описаними в кінці статті.
Почніть міграцію за допомогою процедури DBMSAQMIGTOOL.INITMIGRATION, яка створює проміжну TxEventQ шляхом копіювання конфігурації AQ, включаючи тип навантаження, правила, підписників, привілеї, сповіщення та інше. Адміністративні зміни черг (alter queue) обмежуються до завершення або скасування міграції.
Під час міграції повідомлення в чергах переходять в TxEventQ. Нові повідомлення надходять в TxEventQ, а запити на вилучення повідомлень (dequeue) спрямовуються в AQ до того часу, поки вона не буде очищена від повідомлень, після чого запити на вилучення переходять на TxEventQ. Статус міграції можна відслідковувати і будь-які помилки виправляти або скасовувати.
4.
Якщо черга AQ була очищена або очищена (purged), процедура DBMSAQMIGTOOL.COMMITMIGRATION видаляє AQ і перейменовує проміжну TxEventQ на ім’я AQ, що забезпечує сумісність з додатками.

У разі помилки, яка перешкоджає продовженню міграції, можна скасувати міграцію, а повідомлення, що знаходяться в обробці, будуть відновлені в AQ без втрати даних.

Перевірка сумісності

Процедура CHECKMIGRATIONTO_TXEVENTQ використовується для перевірки, чи підходить AQ для міграції в TxEventQ, і її слід виконати перед спробою міграції.

Наступний SQL-скрипт створює звіт про міграцію для черги AQ my_queue і виводить кількість подій у звіті про міграцію. Якщо всі функції підтримуються, звіт про міграцію буде порожнім.

declare  
 migration_report sys.TxEventQ_MigReport_Array := sys.TxEventQ_MigReport_Array();  
begin  
 DBMS_AQMIGTOOL.CHECK_MIGRATION_TO_TXEVENTQ('testuser', 'my_queue', migration_report);  
 dbms_output.put_line('Migration report unsupported events count: ' || migration_report.COUNT);  
end;  
/

Якщо виведення буде схоже на “Migration report unsupported events count: 0”, то можна безпечно почати міграцію.

Ініціація міграції

Процедура INIT_MIGRATION використовується для початку міграції з AQ до TxEventQ. Параметр migmode використовується для контролю типу міграції і за замовчуванням встановлений на DBMSAQMIGTOOL.INTERACTIVE, що дозволяє виконувати як enqueue, так і dequeue під час міграції. Повний опис параметрів mig_mode доступний у документації до процедури.

Наступний SQL-скрипт починає міграцію для черги AQ myqueue в схемі testuser. Після початку міграції буде створено проміжну TxEventQ з іменем myqueue_m, що містить копію існуючої конфігурації AQ.

begin  
 DBMS_AQMIGTOOL.INIT_MIGRATION(  
 cqschema => 'testuser',  
 cqname => 'my_queue'  
 );  
end;  
/

INITMIGRATION не блокує виконання і може бути виконано паралельно на кількох чергах. Якщо використовується режим міграції DBMSAQMIGTOOL.INTERACTIVE, то повідомлення можуть бути додані в чергу (enqueued) та вилучені (dequeued) під час міграції.

Перевірка статусу міграції

Під час міграції операція dequeue буде витягувати повідомлення з AQ, поки вона не буде порожня, після чого вона перейде до TxEventQ.

Наступна SQL-інструкція використовує процедуру CHECKMIGRATEDMESSAGES для виведення кількості залишкових повідомлень у стані READY в AQ і кількості повідомлень, які були мігровані в TxEventQ. Як тільки aqmsgcnt досягне нуля, черга AQ буде повністю очищена, і міграцію можна буде зафіксувати. Якщо спробувати зафіксувати міграцію до того, як AQ буде очищена від повідомлень у стані READY, виникне виключення.

declare  
 migrated_q_msg_cnt number := 0;  
 aq_msg_cnt number := 0;  
begin  
 DBMS_AQMIGTOOL.CHECK_MIGRATED_MESSAGES(  
 cqschema => 'testuser',  
 cqname => 'my_queue',  
 txeventq_migrated_message => migrated_q_msg_cnt,  
 cq_pending_messages => aq_msg_cnt  
 );  
 dbms_output.put_line('AQ ready state message count: ' || aq_msg_cnt);  
 dbms_output.put_line('Migrated TxEventQ message count: ' || migrated_q_msg_cnt);  
end;  
/

Вид можна перевірити за допомогою подання USERTXEVENTQMIGRATION_STATUS, яке показує статус міграцій, що виконуються для всіх черг, які належать поточному користувачеві.
Інформація про чергу, статус міграції та події помилок доступні в цьому поданні.

Завершення міграції

Якщо кількість повідомлень у стані READY в AQ досягла нуля, процедура COMMIT_MIGRATION використовується для завершення операції міграції.

Наступний SQL-скрипт завершить міграцію для черги myqueue в схемі testuser. Після завершення міграції, myqueue стає TxEventQ.

begin  
 DBMS_AQMIGTOOL.COMMIT_MIGRATION(  
 cqschema => 'testuser',  
 cqname => 'my_queue'  
 );  
end;  
/

Якщо ви хочете очистити всі повідомлення з AQ замість їх вилучення (dequeue), можна використати процедуру PURGEQUEUEMESSAGES, щоб порожнити чергу.

Наступний SQL-скрипт очищує повідомлення з черги my_queue в схемі testuser, що дозволяє завершити міграцію без вилучення повідомлень з AQ.

begin  
 DBMS_AQMIGTOOL.PURGE_QUEUE_MESSAGES(  
 cqschema => 'testuser',  
 cqname => 'my_queue'  
 );  
end;

Перевірка та обробка помилок міграції

Якщо під час міграції AQ виникає помилка або ви використовуєте функцію AQ, яка не підтримується в TxEventQ, процедура CHECK_STATUS може бути використана для запиту поточного статусу міграції та повідомлення про будь-які помилки.

Наступний SQL-скрипт перевіряє статус міграції черги my_queue. У разі несумісностей міграції може бути потрібно змінити додаток перед продовженням міграції.

declare  
 mig_STATUS VARCHAR2(128);  
 mig_comments VARCHAR2(1024);  
begin  
 DBMS_AQMIGTOOL.CHECK_STATUS(  
 cqschema => 'testuser',  
 cqname => 'my_queue',  
 status => mig_STATUS,  
 migration_comment => mig_comments  
 );  
 dbms_output.put_line('Migration Status: ' || mig_STATUS);  
 dbms_output.put_line('Migration comments: ' || mig_comments);  
end;  
/

Приклад виведення помилки через несумісні операції enqueue для TxEventQ:

Migration Status: Compatibility Error: Transformation in Enq Unsupported Feature  
Migration comments: Unsupported parameter in Enqueue

Скасування та відновлення міграції

Процедура CANCEL_MIGRATION використовується для скасування міграції, що виконується.
Використовуйте DBMS_AQMIGTOOL.RESTORE як режим скасування (за замовчуванням), щоб зберегти повідомлення під час скасування.

Наступний SQL-скрипт скасовує міграцію для AQ my_queue в схемі testuser:

begin  
 DBMS_AQMIGTOOL.CANCEL_MIGRATION(  
 cqschema => 'testuser',   
 cqname => 'my_queue',   
 cancelmode => DBMS_AQMIGTOOL.RESTORE  
 );  
end;  
/

Процедура RECOVER_MIGRATION може бути використана для відновлення міграції до найближчої безпечної точки, або до, або після виконання DBMSAQMIGTOOL.CANCELMIGRATION, DBMSAQMIGTOOL.COMMITMIGRATION чи DBMSAQMIGTOOL.INITMIGRATION.

Наступний SQL-скрипт відновлює міграцію до найближчої безпечної точки та виводить повідомлення про відновлення:

declare  
 recovery_message VARCHAR2(1024);  
begin  
 DBMS_AQMIGTOOL.RECOVER_MIGRATION(  
 cqschema => 'testuser',  
 cqname => 'my_queue',  
 recovery_message => recovery_message  
 );  
 dbms_output.put_line('Recovery message: ' || recovery_message);  
end;  
/

Обмеження та способи обходу

Наступні функції не підтримуються в TxEventQ, і їх слід усунути перед міграцією:

Затримка повторної спроби черги: встановіть retrydelay в нуль за допомогою DBMSAQADM.ALTER_QUEUE.
Транзакції повідомлень при enqueue/dequeue: перемістіть трансформацію на рівень додатка.
Багаточергові прослуховувачі: реалізуйте прослуховування лише однієї черги з переглядом dequeue.
Значення пріоритету поза діапазоном 0–9: відкоригуйте значення пріоритету до діапазону 0–9.

Наступні функції підтримують міграцію. Додатки, що використовують ці функції, повинні бути змінені перед міграцією:

Групування повідомлень.
Відхилення послідовності та відносні ідентифікатори повідомлень.
Списки отримувачів повідомлень.

Посилання

Перекладено з: Using Oracle Advanced Queuing? Migrate to TxEventQ for Increased Performance and Reliability.