Ik krijg
ORA-30926: kan geen stabiele set rijen krijgen in de brontabellen
in de volgende zoekopdracht:
MERGE INTO table_1 a
USING
(SELECT a.ROWID row_id, 'Y'
FROM table_1 a ,table_2 b ,table_3 c
WHERE a.mbr = c.mbr
AND b.head = c.head
AND b.type_of_action <> '6') src
ON ( a.ROWID = src.row_id )
WHEN MATCHED THEN UPDATE SET in_correct = 'Y';
Ik heb table_1uitgevoerd, het bevat gegevens en ik heb ook de inside-query (src) uitgevoerd die ook gegevens bevat.
Waarom zou deze fout optreden en hoe kan deze worden opgelost?
Antwoord 1, autoriteit 100%
Dit wordt meestal veroorzaakt door duplicaten in de zoekopdracht die is opgegeven in de clausule USING. Dit betekent waarschijnlijk dat TABLE_A een bovenliggende tabel is en dat dezelfde ROWID meerdere keren wordt geretourneerd.
U zou het probleem snel kunnen oplossen door een DISTINCT in uw zoekopdracht te gebruiken (in feite, als ‘Y’ een constante waarde is, hoeft u deze niet eens in de zoekopdracht in te voeren).
Ervan uitgaande dat uw zoekopdracht correct is (ken uw tabellen niet), zou u zoiets als dit kunnen doen:
MERGE INTO table_1 a
USING
(SELECT distinct ta.ROWID row_id
FROM table_1 a ,table_2 b ,table_3 c
WHERE a.mbr = c.mbr
AND b.head = c.head
AND b.type_of_action <> '6') src
ON ( a.ROWID = src.row_id )
WHEN MATCHED THEN UPDATE SET in_correct = 'Y';
Antwoord 2, autoriteit 20%
U probeert waarschijnlijk dezelfde rij van de doeltabel meerdere keren bij te werken. Ik kwam net hetzelfde probleem tegen in een samenvoegverklaring die ik heb ontwikkeld. Zorg ervoor dat uw update hetzelfde record niet meer dan één keer raakt tijdens het uitvoeren van de samenvoeging.
Antwoord 3, autoriteit 3%
Hoe los ik ORA-30926-fouten op? (Doc-ID 471956.1)
1) Identificeer de falende verklaring
wijzig sessieset-gebeurtenissen ‘30926 traceernaam foutenstack niveau 3’;
of
wijzig systeemset-gebeurtenissen ‘30926 traceernaamfoutstack off’;
en let op .trc-bestanden in UDUMP wanneer dit gebeurt.
2) Nadat u de SQL-instructie hebt gevonden, controleert u of deze correct is (misschien met behulp van explain plan of tkprof om het uitvoeringsplan van de query te controleren) en analyseert of berekent u statistieken over de betreffende tabellen als dit niet recentelijk is gedaan. Indexen opnieuw opbouwen (of laten vallen/opnieuw maken) kan ook helpen.
3.1) Is de SQL-instructie een MERGE?
evalueer de gegevens die worden geretourneerd door de clausule USING om ervoor te zorgen dat er geen dubbele waarden in de join staan. Wijzig de merge-instructie om een deterministische where-clausule op te nemen
3.2) Is dit een UPDATE-statement via een view?
Als dat het geval is, probeer dan het weergaveresultaat in een tabel te vullen en probeer de tabel rechtstreeks bij te werken.
3.3) Is er een trigger op de tafel? Probeer het uit te schakelen om te zien of het nog steeds niet lukt.
3.4) Bevat de instructie een weergave die niet kan worden samengevoegd in een ‘IN-Subquery’? Dit kan ertoe leiden dat dubbele rijen worden geretourneerd als de query een “FOR UPDATE”-clausule heeft. Zie bug 2681037
3.5) Heeft de tabel ongebruikte kolommen? Als u deze laat vallen, kan de fout worden voorkomen.
4) Als het wijzigen van de SQL de fout niet verhelpt, kan het probleem bij de tabel liggen, vooral als er rijen aaneengeschakeld zijn.
4.1) Voer de instructie ‘ANALYZE TABLE VALIDATE STRUCTURE CASCADE’ uit op alle tabellen die in de SQL worden gebruikt om te zien of de tabel of de indexen beschadigd zijn.
4.2) Controleer en verwijder alle GEKOPPELDE of gemigreerde RIJEN op de tafel. Er zijn manieren om dit te minimaliseren, zoals de juiste instelling van PCTFREE.
Gebruik opmerking 12200.1 – Rijen koppelen en migreren
4.3) Als de tabel bovendien Index Georganiseerd is, zie:
Opmerking 102932.1 – Geketende rijen bewaken op IOT’s
Antwoord 4, autoriteit 2%
Had de fout vandaag op een 12c en geen van de bestaande antwoorden paste (geen duplicaten, geen niet-deterministische uitdrukkingen in de WHERE-clausule). Mijn geval had te maken met die andere mogelijke oorzaak van de fout, volgens de berichttekst van Oracle (nadruk hieronder):
ORA-30926: kan geen stabiele set rijen in de brontabellen krijgen
Oorzaak: een stabiele set rijen kon niet worden verkregen vanwege grote dml-activiteitof een niet-deterministische where-clausule.
De samenvoeging was onderdeel van een grotere batch en werd uitgevoerd op een live database met veel gelijktijdige gebruikers. Het was niet nodig om de verklaring te wijzigen. Ik heb de transactie net vóór de samenvoeging vastgelegd, daarna de samenvoeging afzonderlijk uitgevoerd en opnieuw vastgelegd. Dus de oplossing werd gevonden in de voorgestelde actie van het bericht:
Actie: verwijder alle niet-deterministische where-clausules en geef de dml opnieuw uit.
Antwoord 5
Een verdere verduidelijking van het gebruik van DISTINCT om fout ORA-30926 op te lossen in het algemene geval:
U moet ervoor zorgen dat de gegevensset die is gespecificeerd door de clausule USING() geen dubbele waarden heeft van de join-kolommen, dwz de kolommen in de ON()-clausule.
In het voorbeeld van OP waar de clausule USING alleen een sleutel selecteert, was het voldoende om DISTINCT toe te voegen aan de clausule USING. In het algemene geval kan de clausule USING echter een combinatie van sleutelkolommen selecteren om op te passen en attribuutkolommen die moeten worden gebruikt in de clausule UPDATE … SET. In het algemene geval zal het toevoegen van DISTINCT aan de USING-clausule daarom nog steeds verschillende updaterijen voor dezelfde sleutels toestaan, in welk geval u nog steeds de ORA-30926-fout krijgt.
Dit is een uitwerking van het antwoord van DCookie en punt 3.1 in het antwoord van Tagar, wat vanuit mijn ervaring misschien niet meteen duidelijk is.
Antwoord 6
SQL Error: ORA-30926: unable to get a stable set of rows in the source tables
30926. 00000 - "unable to get a stable set of rows in the source tables"
*Cause: A stable set of rows could not be got because of large dml
activity or a non-deterministic where clause.
*Action: Remove any non-deterministic where clauses and reissue the dml.
Deze fout is bij mij opgetreden vanwege dubbele records (16K)
Ik geprobeerd met unique, het werkte.
maar nogmaals toen ik probeerde samen te voegen zonder uniek hetzelfde probleem deed zich voor
Tweede keer dat het moest worden vastgelegd
na samenvoegen als commit niet is gedaan, wordt dezelfde fout getoond.
Zonder uniek, zal Query werken als een commit wordt gegeven na elke samenvoegbewerking.
Antwoord 7
Ik kon dit na enkele uren niet oplossen. Uiteindelijk heb ik gewoon een selectie gemaakt met de twee tabellen samengevoegd, een uittreksel gemaakt en individuele SQL-update-instructies gemaakt voor de 500 rijen in de tabel. Lelijk, maar beter dan urenlang proberen om een zoekopdracht te laten werken.