2. ROWID-Partitionsmethode Parallelverarbeitungsfall (DBMS_PARALLEL_EXECUTE)

Werfen wir einen Blick auf den Fall der parallelen Verarbeitung der ROWID-Partitionierungsmethode mit Oracle DBMS_PARALLEL_EXECUTE.

Dies ist eine Fortsetzung des vorherigen Artikels.

1. Übersicht über Parallelität in DML-Aufgaben (DBMS_PARALLEL_EXECUTE)

2. Parallelverarbeitungsfall des ROWID-Divisionsverfahrens

2.1. Erstellen Sie ROWID-partitionierte parallele Verarbeitungsaufträge

CREATE_TASK( ), um die Aufgabe zu erstellen.

-- 1단계: 작업생성
BEGIN
  ​​DBMS_PARALLEL_EXECUTE.CREATE_TASK(TASK_NAME => 'DPE_TEST(BY ROWID)');
END;
/

Das Ergebnis der Auftragserstellung kann wie folgt überprüft werden.

-- 작업 생성 확인
SELECT * FROM USER_PARALLEL_EXECUTE_TASKS;
1단계: 작업 생성 확인
Schritt 1: Bestätigen Sie die Aufgabenerstellung

Aus dem obigen Ergebnis kann bestätigt werden, dass die Aufgabe erstellt wurde und der STATUS ERSTELLT ist.

Als Referenz hat der STATUS einer Aufgabe die Werte CHUNKED, CHUNKING, CHUNKING_FAILED, CRASHED, CREATED, FINISHED, FINISHED_WITH_ERROR, PROCESSING, und jede Bedeutung ist wie folgt.

  • CHUNKED: Chunk erstellt, noch keiner Aufgabe zugewiesen
  • CHUNKING: Chunks erstellen
  • CHUNKING_FAILED: Beim Erstellen des Chunks ist ein Fehler aufgetreten
  • CRASHED: Während der Aufgabenausführung ist ein Datenbankabsturz oder Jobprozessabsturz aufgetreten, und der Fehler wurde nicht aufgezeichnet und beendet.
  • REATED: Task erstellt (noch kein Chunk erstellt)
  • FINISHED: Alle Chunks ohne Fehler abgeschlossen
  • FINISHED_WITH_ERROR: Alle Chunks abgeschlossen, aber einige Fehler sind aufgetreten
  • PROCESSING: Tosk hat mit der Ausführung begonnen, einige der Chunks sind in Bearbeitung oder abgeschlossen

* Bezug: http://docs.oracle.com/cd/E11882_01/appdev.112/e40758/d_parallel_ex.htm#ARPLS67333

2.2. Geteilte Arbeitseinheit

CREATE_CHUNKS_BY_ROWID( ,

,
, , ), um die Arbeitseinheit aufzuteilen.

ist ein BOOLEAN-Typ, wenn TRUE bedeutet Zeilenanzahl und FALSE bedeutet Blockanzahl.

Führen Sie die folgenden Schritte aus, um Chunks zu erstellen, die die Zeilenanzahl der Tabelle Z_DPE_TEST_TAB in 10.000 Zeilen aufteilen.

-- 2단계: 작업 단위 분할
BEGIN
  DBMS_PARALLEL_EXECUTE.CREATE_CHUNKS_BY_ROWID(TASK_NAME   => 'DPE_TEST(BY ROWID)',
                                               TABLE_OWNER => USER,
                                               TABLE_NAME  => 'Z_DPE_TEST_TAB',
                                               BY_ROW      => TRUE,
                                               CHUNK_SIZE  => 10000);
END;
/

Lassen Sie uns den Teilungsstatus der Arbeitseinheit überprüfen.

-- 작업 분할 상태 확인
SELECT *
  ​​FROM USER_PARALLEL_EXECUTE_CHUNKS
 ​WHERE TASK_NAME = 'DPE_TEST(BY ROWID)';
2단계: 작업 분할 상태 확인
Schritt 2: Überprüfen Sie den Aufgabenteilungsstatus

Es kann bestätigt werden, dass der STATUS jedes Chunks zum Zeitpunkt der Teilung UNASSIGNED ist. Als Referenz hat der STATUS des Chunks die Werte UNASSIGNED, ASSIGNED, PROCESSED und PROCESSED_WITH_ERROR, und jede Bedeutung ist wie folgt.

  • UNASSIGNED: Chunk erstellt, noch keiner Aufgabe zugewiesen
  • ASSIGNED: Chunk ist der Aufgabe zugewiesen und wird ausgeführt
  • PROCESSED: Der Vorgang wurde ohne Fehler abgeschlossen
  • PROCESSED_WITH_ERROR: Die Operation wurde abgeschlossen, aber während der Ausführung ist ein Fehler aufgetreten

* Bezug: http://docs.oracle.com/cd/E11882_01/appdev.112/e40758/d_parallel_ex.htm#ARPLS67333

2.3. Job ausgeführt

RUN_TASK( , , , ), um die Aufgabe auszuführen.

LANGUAGE_FLAG bedeutet hier die Standardversion für Oracle zur Verarbeitung von SQL_STMT, und DBMS_SQL.NATIVE kann als Standard verwendet werden.

Als Referenz ist der Inhalt des Oracle-Dokuments wie folgt:

  • V6 (oder 0) gibt das Verhalten von Version 6 an
  • NATIVE (oder 1) gibt das normale Verhalten für die Datenbank an, mit der das Programm verbunden ist
  • V7 (oder 2) gibt das Verhalten der Oracle-Datenbankversion 7 an

PARALLEL_LEVEL bedeutet die Anzahl der gleichzeitig auszuführenden Jobs, d. h. den Parallelitätsgrad (DOP), und kann gleich oder kleiner als die Anzahl der Chunks sein, die Arbeitseinheiten sind. Im gleichen Fall verarbeitet ein Job einen Chunk, und in einem kleinen Fall verarbeitet ein Job mehrere Chunks.

-- 동시 실행현황 확인: 작업 실행전
SELECT AUDSID, COUNT(*)
  FROM Z_DPE_TEST_TAB
 GROUP BY AUDSID
 ORDER BY AUDSID;
3단계: 동시 실행현황 확인(작업 실행전)
Schritt 3: Überprüfen Sie den Status der gleichzeitigen Ausführung (vor der Aufgabenausführung)

Wenn Sie den COUNT für jede AUDSID überprüfen, bevor Sie die Aufgabe ausführen, können Sie sehen, dass alle Daten auf Null gesetzt sind und noch nicht ausgeführt wurden.

Lassen Sie uns nun den Job ausführen.

-- 3단계: 작업 실행
DECLARE
  L_SQL_STMT VARCHAR2(32767);
BEGIN
  L_SQL_STMT := 'UPDATE  Z_DPE_TEST_TAB
                    SET  VAL = ROUND(DBMS_RANDOM.VALUE(1,10000))
                        ,AUDSID = SYS_CONTEXT(''USERENV'',''SESSIONID'')
                  WHERE  ROWID BETWEEN :START_ID AND :END_ID';

  DBMS_PARALLEL_EXECUTE.RUN_TASK(TASK_NAME      => 'DPE_TEST(BY ROWID)',
                                 SQL_STMT       => L_SQL_STMT,
                                 LANGUAGE_FLAG  => DBMS_SQL.NATIVE,
                                 PARALLEL_LEVEL => 10);
END;
/

Ausgeführtes SQL gibt den Ausführungsbereich mit zwei Bindungsvariablen an: START_ID und :END_ID. Wenn dieser Variablenname anders verwendet wird, tritt ein Fehler auf, also achten Sie darauf, diesen Namen zu verwenden.

Das hier ausgeführte SQL wird geschrieben, um zu prüfen, welche Sitzung die aktuelle Zeile aktualisiert hat, indem ein zufälliger Wert in der VAL-Spalte aktualisiert und der aktuelle SESSIONID-Wert in der AUDSID-Spalte zum Testen aktualisiert wird.

Als Referenz hat die Spalte AUDSID die gleiche Bedeutung wie V$SESSION.AUDSID. Wenn jeder Chunk-Unit-Vorgang lange dauert, kann die Sitzungsüberwachung durch Abfragen von V$SESSION mit AUDSID durchgeführt werden.

Wenn Sie während der Ausführung das folgende SQL ausführen, können Sie überprüfen, wie viele Zeilen in wie vielen Sitzungen aktualisiert werden.

-- 동시 실행현황 확인: 작업 실행중
SELECT AUDSID, COUNT(*)
  FROM Z_DPE_TEST_TAB
 GROUP BY AUDSID
 ORDER BY AUDSID;
3단계: 동시 실행현황 확인(작업 실행중)
Schritt 3: Status der gleichzeitigen Ausführung prüfen (Aufgabenausführung)

Lassen Sie uns den Fortschritt jedes Chunks überprüfen, in den die Arbeit aufgeteilt ist, nicht die Sitzungseinheit.

-- 작업의 Chunk별 진행상황/완료 확인
SELECT *
  FROM USER_PARALLEL_EXECUTE_CHUNKS
WHERE TASK_NAME = 'DPE_TEST(BY ROWID)';
3단계: 작업의 Chunk별 진행상황/완료 확인
Schritt 3: Überprüfen Sie den Fortschritt/die Fertigstellung jedes Teils der Aufgabe

Aus dem obigen Ergebnis können Sie ersehen, dass STATUS in PROCESSED geändert wird und START_TS (Startzeit) und END_TS (Endzeit) verwaltet werden.

Um den Fortschritt nach Chunk-Status zu überprüfen, führen Sie die folgende SQL aus.

-- Chunk의 상태별 진행상황
SELECT STATUS, COUNT(*)
  FROM USER_PARALLEL_EXECUTE_CHUNKS
 WHERE TASK_NAME = 'DPE_TEST(BY ROWID)'
GROUP BY STATUS;
3단계: Chunk의 상태별 진행상황 확인
Schritt 3: Überprüfen Sie den Chunk-Fortschritt nach Status

Aus dem obigen Ergebnis kann bestätigt werden, dass 172 Chunks im PROCESSED-Status abgeschlossen wurden. Da das Bild aufgenommen wurde, nachdem der Auftrag abgeschlossen war, wurde nur ein Status aufgezeichnet. Wenn der Vorgang lange dauert, können Sie die Anzahl der Chunks für jeden Status überprüfen.

2.4. Aufgabenabschluss bestätigen und löschen

DROP_TASK( ), um den Auftrag zu löschen.

Als Referenz: Wenn Sie ihn nicht löschen, tritt der Fehler ORA-29497: Doppelter Aufgabenname (DUPLICATE_TASK_NAME) auf, wenn später eine Aufgabe mit demselben TASK_NAME erstellt wird.

-- 작업 완료 확인
SELECT *
  FROM USER_PARALLEL_EXECUTE_TASKS;
작업 완료 확인
Bestätigen Sie den Abschluss der Aufgabe

Aus dem obigen Ergebnis kann bestätigt werden, dass der STATUS der Aufgabe mit FINISHED abgeschlossen wurde.

-- 4단계: 작업 완료 확인 및 작업 삭제
BEGIN
  DBMS_PARALLEL_EXECUTE.DROP_TASK(TASK_NAME => 'DPE_TEST(BY ROWID)');
END;
/
4 단계: 작업 완료 확인 및 작업 삭제
Schritt 4: Auftragsabschluss prüfen und Auftrag löschen

Wenn Sie die Ansicht USER_PARALLEL_EXECUTE_TASKS erneut überprüfen, nachdem Sie DROP_TASK ausgeführt haben, können Sie sehen, dass die Aufgabe gelöscht wurde.


Bisher haben wir uns einen einfachen Fall der parallelen Verarbeitung der ROWID-Partitionierungsmethode angesehen.

Als nächstes schauen wir uns an, wie einheitlich die durch ROWID geteilten Arbeitseinheiten sind, ob es keine Auslassungen gibt und wie die Korrelation zwischen der Anzahl der Chunks und der Anzahl der Jobs (Parallelität) ist.

2 Antworten

  1. Avatar-Foto newyemac sagt:

    Ich habe es mit DBMS_PARALLEL_EXECUTE.CREATE_CHUNKS_BY_ROWID ausgeführt, aber wenn ich mir den Status der Aufgabe ansehe, sehe ich den Status NO_CHUNKS. Kennen Sie den Grund?

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert