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;
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
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)';
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
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;
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;
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)';
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;
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;
/
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.
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?
Die von mir getestete Umgebung war Oracle 11g R2 (11.2) und zu diesem Zeitpunkt gab es keinen NO_CHUNKS-Status.
Nach einer Google-Suche habe ich Folgendes gefunden:
———————————–
NO_CHUNKS: Für die mit der Aufgabe verknüpfte Tabelle wurden keine Chunks erstellt
———————————–
Blöcke werden durch ROWID unterteilt, aber wenn alle Blöcke innerhalb des Blocks keine Daten enthalten, scheint er sich im Status NO_CHUNKS zu befinden.
Das Testen ist schwierig, da ich Oracle in letzter Zeit nicht verwendet habe.
Bitte beachten Sie.
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?
Die von mir getestete Umgebung war Oracle 11g R2 (11.2) und zu diesem Zeitpunkt gab es keinen NO_CHUNKS-Status.
Nach einer Google-Suche habe ich Folgendes gefunden:
———————————–
NO_CHUNKS: Für die mit der Aufgabe verknüpfte Tabelle wurden keine Chunks erstellt
———————————–
* Quelle: Oracle 19c-Dokument
https://docs.oracle.com/en/database/oracle/oracle-database/19/arpls/DBMS_PARALLEL_EXECUTE.html#GUID-5581516D-AB22-4748-8476-C5BB38BE7E2F
Blöcke werden durch ROWID unterteilt, aber wenn alle Blöcke innerhalb des Blocks keine Daten enthalten, scheint er sich im Status NO_CHUNKS zu befinden.
Das Testen ist schwierig, da ich Oracle in letzter Zeit nicht verwendet habe.
Bitte beachten Sie.