update sur une clé primaire [zOS] [Résolu]

[michael08]

Bonjour,

Je m'occupe d'un programme qui fait des delete et des insert sur une table. On m'a demandé de chercher pourquoi on ne fait pas simplement des update.

J'ai répondu naïvement qu'on ne peut pas faire d'update sur un champ de la clé primaire.
Sauf que j'ai eu l'air bête quand, en effectuant un update en test par spufi sur un champ de la clé primaire, ça a fonctionné.

J'ai regardé la ddl :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
CREATE TABLE QUAL.TABLET                                            
       (REF                            DECIMAL(9 , 0)             
                                                         NOT NULL  
       WITH DEFAULT                                                          
      ,COD                            CHARACTER(2)   FOR SBCS DATA 
                                                        NOT NULL       
       ,NOM                            CHARACTER(19)  FOR SBCS DATA
                                                         NOT NULL     
       ,PART                            SMALLINT       NOT NULL     
       REF                                                
       PRIMARY KEY                                                      
       (REF                                                         
       ,COD                                                         
       )                                                                
      )

La définition de l'index correspondant à la clé primaire:

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
CREATE TYPE 2 UNIQUE INDEX QUAL.TABLEIU             
       ON QUAL.TABLET                              
 
       (REF                         ASC           
       ,COD                        ASC  )        
       USING STOGROUP TABLESG                        
             PRIQTY 1000                             
             SECQTY 0                                
             ERASE NO                                
       FREEPAGE 0                                    
       PCTFREE 15                                    
       BUFFERPOOL BP32                               
       CLOSE YES

On voit qu'apparemment il ne s'agit pas d'un index clusterisé.

L'index clusterisé:

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
CREATE TYPE 2 INDEX QUAL.TABLECL             
       ON QUAL.TABLET                       
 
       (PART                         ASC  ) 
       CLUSTER                                
       (PARTITION 1    ENDING AT (1)          
                       USING STOGROUP TABLESG
                             PRIQTY 1000      
                             SECQTY 0         
                             ERASE NO         
                       FREEPAGE 0             
                       PCTFREE 15             
       ,PARTITION 2    ENDING AT (2)  
                USING STOGROUP TABLESG
                      PRIQTY 1000     
                      SECQTY 0        
                      ERASE NO        
                FREEPAGE 0            
                PCTFREE 15            
,PARTITION 3    ENDING AT (3)         
                USING STOGROUP TABLESG
                      PRIQTY 1000     
                      SECQTY 0        
                      ERASE NO        
                FREEPAGE 0            
                PCTFREE 15            
)               
BUFFERPOOL BP32 
CLOSE NO;

Et là je me dis que je comprends pourquoi le programme fait des delete-insert plutôt que des update. En effet dans les champs mis à jour, il y a le numéro de partition.
Je me dis alors que la règle c'est peut être qu'on ne peut pas faire de mise à jour sur un élément de l'index cluster.
Sauf que quand j'essaye de faire un update par spufi sur le numpar, ça marche!

Du coup je me demande quels sont les champs qui sont impossible de mettre à jour par DB2?

Avez vous une idée?

Merci d'avance!

[fsmrel]

DB2 refuse de modifier la valeur de la clé primaire (ou plus généralement d’une clé candidate) d’une table T1 seulement quand cette clé est référencée par une clé étrangère d’une table T2 (ou T1 elle-même) et que cette clé étrangère a la même valeur que celle de la clé primaire que l’on veut modifier. C’est un a priori « philosophique » (sic) énoncé dans le document IBM Database 2 Referential Integrity Usage Guide - GG24-3312-0 : June 1988, page 48 :

The reason for this restriction is philosophical

Yes sir!

Manifestement vous n'êtes pas dans cette situation.


N.B. A la page 50 du document :

One cannot update the primary key value for a row that has a dependent row, because DB2 only supports the RESTRICT option of the UPDATE RULE. However, the value of a primary key may be changed using the UPDATE statement as long as it is not a parent row.

[michael08]

Envoyé par fsmrel

DB2 refuse de modifier la valeur de la clé primaire (ou plus généralement d’une clé candidate) d’une table T1 seulement quand cette clé est référencée par une clé étrangère d’une table T2 (ou T1 elle-même) et que cette clé étrangère a la même valeur que celle de la clé primaire que l’on veut modifier. C’est un a priori « philosophique » (sic) énoncé dans le document IBM Database 2 Referential Integrity Usage Guide - GG24-3312-0 : June 1988, page 48 :

The reason for this restriction is philosophical

Yes sir!

Manifestement vous n'êtes pas dans cette situation.


N.B. A la page 50 du document :

One cannot update the primary key value for a row that has a dependent row, because DB2 only supports the RESTRICT option of the UPDATE RULE. However, the value of a primary key may be changed using the UPDATE statement as long as it is not a parent row.

Ok. J'aurais pourtant juré avoir eu un problème lié à un update d'une clé qui n'était pourtant pas une clé érangère d'une autre table.

Merci beaucoup pour ta réponse!

[punkoff]

peut-être pour les clefs auto-incrémentée ?

[Luc Orient]

Envoyé par michael08

...
Et là je me dis que je comprends pourquoi le programme fait des delete-insert plutôt que des update. En effet dans les champs mis à jour, il y a le numéro de partition.
Je me dis alors que la règle c'est peut être qu'on ne peut pas faire de mise à jour sur un élément de l'index cluster.
Sauf que quand j'essaye de faire un update par spufi sur le numpar, ça marche!

Jusqu'à la V7 incluse la mise à jour d'une colonne d'un index de partition avait une réputation exécrable en terme de concurrence.

Par exemple ( trouvé sur un blog grâce à Google ) :

Before Version 8, DB2 had to quiesce all the partitions affected by a row’s movement when a column in the partition key was changed.. If the key was altered and a row was moved from partition 3 to partition 7, all the partitions between 3 and 7 inclusively for the table space and partition index would have to be drained along with any non partitioned indexes on that table. Not very cool concurrency is important and you would prefer to avoid and timeouts.. As stated, this problem was resolved by DB2 Version 8.

La version 8 a résolu ce problème.

Peut-être que votre programme a gardé trace de cette contrainte du passé ...

[michael08]

Envoyé par Luc Orient

Jusqu'à la V7 incluse la mise à jour d'une colonne d'un index de partition avait une réputation exécrable en terme de concurrence.

Par exemple ( trouvé sur un blog grâce à Google ) :



La version 8 a résolu ce problème.

Peut-être que votre programme a gardé trace de cette contrainte du passé ...

Merci beaucoup pour la piste! En fait apparemment il y a une DSNZPARM qu'il faut configurer et le paramètre PARTKEYU valorisé à YES permet de réaliser un update sur un champ participant au calcul du numéro de participation.
Par contre je me demande comment DB2 reconnait les champs qui participent au numéro de partition ne connaissant pas la règle.
je me demande même comment il reconnait le champ partition?

[Luc Orient]

Envoyé par michael08

Merci beaucoup pour la piste! En fait apparemment il y a une DSNZPARM qu'il faut configurer et le paramètre PARTKEYU valorisé à YES permet de réaliser un update sur un champ participant au calcul du numéro de participation.

Effectivement (extrait de la doc IBM) :

The PARTKEYU subsystem parameter controls whether values that are in columns that participate in partitioning keys can be updated.

Acceptable values: YES, NO, or SAME
Default: YES
Update: option 18 on panel DSNTIPB
DSNZPxxx: DSN6SPRM PARTKEYU

YES
Values in columns that participate in partitioning keys can be updated.
This is the default.
NO
Values in columns that participate in partitioning keys cannot be updated.
SAME
Values in columns that participate in partitioning keys can be updated if and only if the update leaves the row belonging to the same partition.
Specifying NO or SAME will not improve concurrency. DB2® does not take exclusive control of the objects to perform the update.

Attempts to inappropriately update the value in a partitioning key column result in the failure of the SQL statement with a -904 resource-unavailable SQL code. The accompanying DSNT501I message identifies the unavailable resource as code type X'3000' and a reason code of 00C900C7.

The PARTKEYU parameter is deprecated in DB2 Version 9.1.

Ce paramètre est indiqué comme "deprecated" par IBM, c'est à dire qu'il devrait disparaitre dans une prochaine version de DB2. En effet, depuis la V8 la mise à jour d'une colonne d'un index de partition ne devrait plus poser de problème en terme de concurrence.

Par contre je me demande comment DB2 reconnait les champs qui participent au numéro de partition ne connaissant pas la règle.
je me demande même comment il reconnait le champ partition?

L'information est bien sûr stockée dans le catalogue associé au SGBD.