Cela ressemble à une question stupide, mais je vois ce qui suit dans le Guide des concepts Oracle sur la gestion des transactions:
Une transaction se termine lorsque l'un des Après se produit:
Un utilisateur émet un commit ou une restauration Déclaration sans clause de sauvegarde.
Un utilisateur exécute une instruction DDL telle que Créer, déposer, renommer ou modifier. Si la La transaction actuelle contient tout DML déclarations, Oracle commencent par comme le transaction, puis exécute et commettre L'énoncé DDL en tant que nouveau, célibataire transaction de déclaration.
Un utilisateur débranchit de Oracle. Les La transaction actuelle est commise.
Un processus utilisateur se termine anormalement. La transaction actuelle est laminée retour.
suis-je pour interpréter le dernier point pour signifier que si je publie une requête qui a une erreur, la transaction sera renvoyée?
3 Réponses :
"Processus utilisateur" Dans ce contexte se réfère au processus exécutant sur la machine cliente qui crée la connexion à Oracle. En d'autres termes, si vous utilisez l'application A ( SQL * plus , TOAD, etc.) Pour vous connecter à Oracle, le processus utilisateur est SQL * plus , TOAD, etc. . Si ce processus utilisateur meurt pendant que vous étiez au milieu d'une transaction, cette transaction sera renvoyée. Cela se produira dès que PMON découvre que le client est mort, ce qui peut prendre un peu de temps, ce n'est pas toujours trivial pour que Oracle de distinguer l'échec d'un processus d'utilisateur à partir d'un processus d'utilisation qui ne publie tout simplement pas de commandes à le moment.
Je suis d'accord avec Justin, son aperçu est correct. Ajout d'informations supplémentaires: En tant que développeur d'applications, vous devez appeler explicitement une commande Rollback si des erreurs se produisent. Cela signifie que vous devez également envisager de regrouper des déclarations dans des blocs transactionnels, le cas échéant. Les blocs transactionnels et les retournements sont traités différemment par différentes technologies, cela vaut une certaine recherche pour vous assurer de bien comprendre.
Ceci est une question intéressante!
Lorsque Oracle rencontre une erreur, il annulera la déclaration actuelle Cela signifie que lorsqu'une déclaration (par exemple un PL / SQL La procédure appelée à partir de Java) renvoie une erreur, Oracle mettra la transaction dans le même état logique qu'avant l'appel. Ceci est extrêmement utile, vous n'avez pas à vous soucier des procédures à moitié exécutées (**). P> Ce fil sur Asktom couvre le même sujet : P> [La déclaration] soit entièrement survenue ou tout cela ne se produit pas et le
Way qui fonctionne est la base de données l'équivalent logique de: p>
blockQuote> Cette fonctionnalité, à mon avis, c'est pourquoi il est beaucoup plus facile d'écrire un code de base de données (*) dans PL / SQL que dans toute autre langue. p> (*) code qui interagit avec une DB Oracle, je suppose que les langues de procédure natives des autres SGBD ont des caractéristiques similaires. P> (**) Cela concerne uniquement la DML depuis DDL n'est pas transactionnel à Oracle. Soyez également prudent avec certains forfaits SADM qui mettent à jour le dictionnaire de données (telle que
dbms_stats code>), ils font souvent des changements de type DDL et des engagements comme des commentaires. Reportez-vous au Documentation en cas de doutes. SQL> CREATE TABLE T (a NUMBER);
Table created
SQL> CREATE OR REPLACE PROCEDURE p1 AS
2 BEGIN
3 -- this statement is successful
4 INSERT INTO t VALUES (2);
5 -- this statement will raise an error
6 raise_application_error(-20001, 'foo');
7 END p1;
8 /
Procedure created
SQL> INSERT INTO t VALUES (1);
1 row inserted
SQL> EXEC p1;
begin p1; end;
ORA-20001: foo
ORA-06512: at "VNZ.P1", line 5
ORA-06512: at line 2
SQL> SELECT * FROM t;
A
----------
1
Vous avez tort des déclarations et des blocs PL / SQL. Un bloc PL / SQL n'est pas une déclaration que l'insertion, la mise à jour ou la suppression sont. Si un bloc PL / SQL jette une erreur et qu'il n'y a pas de manipulation de points de sauvegarde comme votre morceau de code, vous devez vous inquiéter des procédures à moitié exécutées.
Christian, c'est faux. Si une exception est soulevée par un bloc de haut niveau PL / SQL, appelé par un client, il y a un retour au point avant l'invocation de ce bloc (en supposant qu'il n'y a pas eu de commit dans l'intervalle PL / SQL).
@Christian: J'ai mis à jour ma réponse, j'espère que cela clarifiera le concept que j'essayais d'expliquer.
@andrew Nous parlions de DML ici, pas de DDL. Je pense que c'était clair du contexte (transaction) mais je le préciserai dans ma réponse.
En fait, cela ressemble à une question très intéressante pour moi. Postgres Rollback On Erreur, et je l'ai souvent trouvé ennuyeux (et je me suis demandé si Oracle a fait quelque chose de similaire).
Dis-moi, pourquoi utilisez-vous des transactions si vous ne voulez pas de retourner sur les erreurs? C'est l'un des principaux objectifs des transactions.
@Oliver: Je ne veux pas nécessairement ou non. Je veux juste savoir comment ils travaillent.
@Oliver, c'est Oracle - vous utilisez toujours des transactions.
@JEFFREYKEMP: Strictement parlant que vous utilisez toujours des transactions dans une base de données relationnelle, ce n'est que de nombreuses interfaces autocommandes chaque affirmation.
@beldaz, c'était exactement mon point - il n'y a aucune option pour ne pas utiliser de transactions. Oliver semblait être de la malentendance que vous pouvez vous retirer.
dba.stackexchange.com / Questions / 84769 / ...