Constraint Probleme bei der Drop Nicht null auf iseries IBM AS400

Question

Bitte helfen Sie mir mit diesem, ich

ALTER TABLE MY_TABLE DATA CAPTURE NONE; 
ALTER TABLE MY_TABLE ALTER MY_COLUMN DROP NOT NULL; 

ausführen, aber dann habe ich den gefolgten Fehler:

SQL State: 57007

Vendor Code: -910

Message: [SQL0910] The MY_TABLE object type * FILE MY_SCHEMA has a pending change.

Cause . . . . . : The MY_TABLE object has a pending change made under commitment control is preventing this operation. You may have produced one of the following circumstances:

• This application process has performed an operation on this object under commitment control. The transaction is not committed. The application process is now trying to change the same object using the commitment control level of * NONE.

• A different process application has performed an operation on this object under commitment control. The transaction is not committed.

• This application process has performed an operation on this object under commitment control using a different definition of commitment. The transaction is not committed.

• This application process has performed an operation on this object under commitment control. The transaction is not committed.

You can not change the table until commit or roll back the changes.

Retrieval. Do one of the following and retry the request:

• If your application process issued the uncommitted operation, run a COMMIT or ROLLBACK before attempting any other operation on this object, or issue the statement from a program using a commitment control level other than * NONE.

• If the application process that issued the uncommitted operation on this object is not to your application, then that application process must perform a COMMIT or ROLLBACK.

• If the application process issued the uncommitted operation using a different definition of commitment, issue a COMMIT or ROLLBACK to the definition of commitment.

• Issue COMMIT or ROLLBACK before attempting an ALTER TABLE statement on this subject.

Bitte helfen Sie mir !!

Answer 1

Die Bedingung gibt an, dass vorherige Arbeiten im Rahmen der Commitment-Kontrolle anhängig waren; Entweder wartet es auf normales COMMIT oder ROLLBACK, oder die vorherige Verarbeitung wurde unterbrochen und der Job wurde beendet, ohne die Commit-Definition bereinigen zu können. Es hätte vorherige Meldungen gegeben, die im Jobprotokoll protokolliert wurden, um mehr über die Bedingung zu informieren, als was sqlcode = -910 und msg SQL0910 anzeigen können; Das gespoolte Joblog hätte höchstwahrscheinlich die vorherige Nachricht CPF325E mit der Aktivierungsgruppe und der logischen Arbeitseinheit ergeben, der eine Nachricht CPF70A6 mit einem Ursachencode vorangestellt ist. Ohne das gespoolte Jobprotokoll und die Überprüfung für solche zuvor protokollierten Nachrichten ist es unwahrscheinlich, dass die Herkunft gelernt wird. Es gibt jedoch die Option, die Arbeit mit Commitment Def [initions] (WRKCMTDFN) [mit der Option zum Durchsuchen aller Jobs] zu verwenden und, wie bereits erwähnt, das Journal dahingehend zu überprüfen, welche Transaktionen angefordert, aber nie ausgeführt wurden.

Wenn Herkunft durch einen unterbrochenen Prozess, der nicht mehr vorhanden ist, wird die IPL ein Tagebuch führen/commit/Datenbank Erholung Phasen in der SCPF joblog [, für die die IPL Zeitjob die joblog nach dem Systemabschnitt gespult hat der IPL abgeschlossen; Das Betrachten des aktiven SCPF-Jobprotokolls ist nicht hilfreich] und das Messaging wird in QSYSOPR und/oder QHST protokolliert [siehe DSPLOG QHST für beide, zusätzlich zum gespoolten QPJOBLOG vom SCPF-Job für das IPL nach dem Problem].

Wenn das Problem nach einem IPL bestehen bleiben sollte, dann den Reclaim Storage (RCLSTG) für * ALL [optional etwas anderes weglassen; Obwohl DBXREF am besten weggelassen werden sollte, für das eine verlorene DB-Änderung später als ein Fehler bei der Neuerstellung oder anderweitiger Ausführung von Arbeiten an der Datenbankdatei, für die frühere Fehler/Wiederherstellungsaktivitäten aufgetreten sind, offensichtlich ist SELECT (* ALL) Anfrage, könnte eine zweite Anfrage nur RCLSTG SELECT (* DBXREF) sein.

Hinweis: Es wurden Vergangenheit Mängel gewesen, wodurch Arbeit nicht unter COMMIT-Steuerung ausgeführt verlassen hat fälschlicherweise eine Datei in Recovery mit einem Hinweis darauf, dass vor der Arbeit unter COMMIT-Steuerung durchgeführt wurde; Der Effekt ist ein wenig anders, als eine andere Nachrichtenkennung, so dass in beiden Fällen die anstehende Arbeit vor anderen Änderungsaktivitäten geschützt ist. Unterbrochene Arbeiten außerhalb der unter Isolation laufenden Arbeiten dürfen gelöscht werden, beispielsweise mit Delete File (DLTF) oder DROP TABLE - Fehler, die während der Anfrage protokolliert werden, werden von der Datenbank ignoriert, aber achten Sie darauf, das Messaging auf mögliche Zustände zu überprüfen Problem, das noch nicht aufgetreten ist, z. B. dass das Element nicht gelöscht wurde, was bedeutet, dass ein Ersatz für die Datei unabhängig von create, restore oder add member fehlschlägt. Solche Schwierigkeiten werden wahrscheinlich nur durch Kontaktaufnahme mit einem Dienstanbieter gelöst.