Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
DECLARE
Definiert einen neuen Cursor. Mit einem Cursor können Sie aus dem Ergebnissatz einer größeren Abfrage einige Zeilen gleichzeitig abrufen.
Wenn die erste Zeile eines Cursors abgerufen wird, wird der gesamte Ergebnissatz auf dem Führungsknoten im Arbeitsspeicher oder auf der Festplatte umgesetzt, wenn nötig. Aufgrund der potenziellen negativen Auswirkungen der Verwendung von Cursors mit großen Ergebnissätzen wird empfohlen, alternative Ansätze anzuwenden, wann immer möglich. Weitere Informationen finden Sie unter Überlegungen in Bezug auf die Leistung bei Verwendung von Cursors.
Sie müssen einen Cursor innerhalb eines Transaktionsblocks deklarieren. Pro Sitzung kann jeweils nur ein Cursor offen sein.
Weitere Informationen finden Sie unter FETCH, CLOSE.
Syntax
DECLARE cursor_name CURSOR FOR query
Parameter
- cursor_name
-
Der Name des neuen Cursors.
- query
-
Eine SELECT Anweisung, die den Cursor füllt.
DECLARECURSORHinweise zur Verwendung
Wenn Ihre Client-Anwendung eine ODBC Verbindung verwendet und Ihre Abfrage eine Ergebnismenge erzeugt, die zu groß ist, um in den Arbeitsspeicher zu passen, können Sie die Ergebnismenge mithilfe eines Cursors in Ihre Client-Anwendung streamen. Wenn Sie einen Cursor verwenden, wird der gesamte Ergebnissatz auf dem Führungsknoten umgesetzt. Anschließend kann Ihr Client die Ergebnisse inkrementell abrufen.
Anmerkung
Um Cursor ODBC für Microsoft Windows zu aktivieren, aktivieren Sie die Option Declare/Fetch verwenden in dem, was ODBC DSN Sie für Amazon Redshift verwenden. Wir empfehlen, die ODBC Cachegröße bei Clustern mit mehreren Knoten über das Feld Cachegröße im ODBC DSN Optionsdialogfeld auf 4.000 oder mehr festzulegen, um Roundtrips zu minimieren. Legen Sie die Größe des Zwischenspeichers für Einzelknoten-Cluster auf 1.000 fest.
Aufgrund der potenziellen negativen Auswirkungen der Verwendung von Cursors wird empfohlen, alternative Ansätze anzuwenden, wann immer möglich. Weitere Informationen finden Sie unter Überlegungen in Bezug auf die Leistung bei Verwendung von Cursors.
Amazon-Redshift-Cursors werden mit den folgenden Einschränkungen unterstützt:
-
Pro Sitzung kann jeweils nur ein Cursor offen sein.
-
Cursor müssen innerhalb einer Transaktion (BEGIN...END) verwendet werden.
-
Die maximal zulässige kumulative Größe für Ergebnissätze für alle Cursors wird auf der Basis des Typs des Clusterknotens eingeschränkt. Wenn Sie größere Ergebnissätze benötigen, können Sie die Größe in eine XL- oder 8XL-Knotenkonfiguration ändern.
Weitere Informationen finden Sie unter Einschränkungen für Cursors.
Einschränkungen für Cursors
Wenn die erste Zeile eines Cursors abgerufen wird, wird der gesamte Ergebnissatz auf dem Führungsknoten umgesetzt. Wenn der Ergebnissatz zu groß für den Arbeitsspeicher ist, wird er bei Bedarf auf die Festplatte geschrieben. Um die Integrität des Führungsknotens zu schützen, setzt Amazon Redshift Einschränkungen für die Größe aller Cursor-Ergebnissätze auf der Basis des Typs des Clusterknotens durch.
In der folgenden Tabelle wird die maximal zulässige Gesamtgröße von Ergebnissätzen für die einzelnen Cluster-Knotentypen gezeigt. Die maximale Größe von Ergebnissätzen ist in Megabyte angegeben.
Knotentyp | Maximal zulässige Größe des Ergebnissatzes pro Cluster (MB) |
---|---|
DC2 Large mehrere Knoten |
192.000 |
DC2 Large einzelner Knoten |
8 000 |
DC28XL mehrere Knoten |
3.200.000 |
RA316XL mehrere Knoten |
14.400.000 |
RA34XL mehrere Knoten |
3.200.000 |
RA3XLPLUSmehrere Knoten |
1 000 000 |
RA3XLPLUSeinzelner Knoten |
64.000 |
RA3LARGEmehrere Knoten |
240.000 |
RA3LARGEeinzelner Knoten |
8 000 |
Amazon Redshift Serverless |
150.000 |
Um die aktive Cursor-Konfiguration für ein Cluster anzuzeigen, führen Sie eine Abfrage für die Systemtabelle STV_CURSOR_CONFIGURATION als Superuser aus. Um den Status aktiver Cursors anzuzeigen, führen Sie eine Abfrage für die Systemtabelle STV_ACTIVE_CURSORS aus. Nur die Zeilen für die eigenen Cursors eines Benutzers werden diesem angezeigt. Superuser können jedoch alle Cursors anzeigen.
Überlegungen in Bezug auf die Leistung bei Verwendung von Cursors
Da Cursors den gesamten Ergebnissatz auf dem Führungsknoten umsetzen, bevor Ergebnisse an den Client zurückgegeben werden, kann sich die Verwendung von Cursors bei sehr großen Ergebnissätzen negativ auf die Leistung auswirken. Es wird nachdrücklich empfohlen, Cursors nicht bei sehr großen Ergebnissätzen zu verwenden. In einigen Fällen, z. B. wenn Ihre Anwendung eine ODBC Verbindung verwendet, sind Cursor möglicherweise die einzig praktikable Lösung. Es wird empfohlen, die folgenden Alternativen zu verwenden, wenn möglich:
-
Verwenden Sie UNLOAD, um große Tabellen zu exportieren. Bei der Verwendung arbeiten die Rechenknoten parallelUNLOAD, um die Daten direkt in Datendateien auf Amazon Simple Storage Service zu übertragen. Weitere Informationen finden Sie unter Entladen von Daten in Amazon Redshift.
-
Stellen Sie den Parameter für JDBC die Abrufgröße in Ihrer Client-Anwendung ein. Wenn Sie eine JDBC Verbindung verwenden und auf clientseitige out-of-memory Fehler stoßen, können Sie Ihrem Client ermöglichen, Ergebnismengen in kleineren Batches abzurufen, indem Sie den JDBC Parameter fetch size festlegen. Weitere Informationen finden Sie unter Einstellung des Parameters für die JDBC Abrufgröße.
DECLARECURSORBeispiele
Im folgenden Beispiel wird ein Cursor deklariert, der so benannt istLOLLAPALOOZA, dass er Verkaufsinformationen für das Lollapalooza-Ereignis auswählt, und ruft dann mithilfe des Cursors Zeilen aus der Ergebnismenge ab:
-- Begin a transaction begin; -- Declare a cursor declare lollapalooza cursor for select eventname, starttime, pricepaid/qtysold as costperticket, qtysold from sales, event where sales.eventid = event.eventid and eventname='Lollapalooza'; -- Fetch the first 5 rows in the cursor lollapalooza: fetch forward 5 from lollapalooza; eventname | starttime | costperticket | qtysold --------------+---------------------+---------------+--------- Lollapalooza | 2008-05-01 19:00:00 | 92.00000000 | 3 Lollapalooza | 2008-11-15 15:00:00 | 222.00000000 | 2 Lollapalooza | 2008-04-17 15:00:00 | 239.00000000 | 3 Lollapalooza | 2008-04-17 15:00:00 | 239.00000000 | 4 Lollapalooza | 2008-04-17 15:00:00 | 239.00000000 | 1 (5 rows) -- Fetch the next row: fetch next from lollapalooza; eventname | starttime | costperticket | qtysold --------------+---------------------+---------------+--------- Lollapalooza | 2008-10-06 14:00:00 | 114.00000000 | 2 -- Close the cursor and end the transaction: close lollapalooza; commit;
Im folgenden Beispiel wird eine Schleife über einen Refcursor mit allen Ergebnissen aus einer Tabelle durchgeführt:
CREATE TABLE tbl_1 (a int, b int); INSERT INTO tbl_1 values (1, 2),(3, 4); CREATE OR REPLACE PROCEDURE sp_cursor_loop() AS $$ DECLARE target record; curs1 cursor for select * from tbl_1; BEGIN OPEN curs1; LOOP fetch curs1 into target; exit when not found; RAISE INFO 'a %', target.a; END LOOP; CLOSE curs1; END; $$ LANGUAGE plpgsql; CALL sp_cursor_loop(); SELECT message from svl_stored_proc_messages where querytxt like 'CALL sp_cursor_loop()%'; message ---------- a 1 a 3