Discussion :

[masson_r]

Bonjour,

Je rencontre actuellement un problème lors de chargement de données en mode DROP/INSERT.

Toutes les nuits, une table est effacée pour être de nouveau alimentée dans la foulée.

Problème 1 : La donnée est indisponible le temps du chargement.
Problème 2 : En cas de problème de chargement, la table reste vide et le service est interrompu.

Pour pallier à ce problème, je cherche à mettre en place une solution à base d'ALIAS ou de SYNONYM. Comment cela, on travaille au niveau applicatif uniquement sur l'ALIAS (ou le SYNONYM).

Côté base, l'ALIAS pointe vers la table de travail... avant le rechargement de la table, l'ALIAS passe sur une table de backup.
Tout le temps du traitement, l'applicatif interroge la table de backup (uniquement en lecture).
A la fin du traitement, on repasse l'ALIAS sur la table de travail et on remet à jour la table de backup en attendant la prochaine mise à jour de données.

Problème, quand je lance

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

CREATE ALIAS A_MYTABLE FOR MYTABLE;

Tout va bien, mais je ne peux plus faire de modification de l'ALIAS du type :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

CREATE OR REPLACE ALIAS A_MYTABLE FOR MYTABLE_BACKUP;

Dans ce cas, j'ai cette erreur :
An unexpected token "CREATE OR REPLACE ALIAS" was found following "BEGIN-OF-STATEMENT". Expected tokens may include: "".. SQLCODE=-104, SQLSTATE=42601, DRIVER=4.3.111


Comment faites-vous pour gérer ce type de problème? Utilisez-vous des ALIAS, ou des SYNONYM ou une autre stratégie?

Merci d'avance

[Macfurp]

Bonjour,

de quelle version de DB2 LUW ou Z/Os s'agit-il ?

Y a t-il des packages ou procédures stockées qui sont attachés à l'ALIAS ou aux tables ?

[escartefigue]

Bonjour,

Je rencontre actuellement un problème lors de chargement de données en mode DROP/INSERT.

Toutes les nuits, une table est effacée pour être de nouveau alimentée dans la foulée.

Problème 1 : La donnée est indisponible le temps du chargement.
Problème 2 : En cas de problème de chargement, la table reste vide et le service est interrompu.

Merci d'avance

Bonjour,

Le drop détruit le contenant et le contenu, si le but est de vider la table,
il est beaucoup plus simple de faire une load replace avec un fichier vide en entrée

Par ailleurs
- un drop/create bloque non seulement la table mais aussi toutes les autres tables de la database
les autres applis seront donc bloquées pendant l'opération, meme si elles accèdent à d'autres tables de la DB
- le drop supprimera aussi toutes les images copy de la SYSIBM.SYSCOPY
- drop/create necessite des droits sysadm que n'a pas forcément l'utilisateur ou le robot d'exploitation lançant le traitement

Bref un load dummy me semble nettement préférable

Je ne comprends pas la remarque "La donnée est indisponible le temps du chargement", s'il s'agit d'insert comme tu l'indiques, la donnée est disponible dès que le traitement est commité, voire même avant avec un verouillage "UR". Si besoin, tu peux mettre un pas de commit plus rapproché.

Enfin, les alias n'ont rien a voir avec ton problème

[bernard59139]

bonjour

2 autres piste à analyser.

1. Pour vider une table, voir si TRUNCATE peut être utilisé.
2. les CLONE table sont une piste à analyser

a+

[escartefigue]

bonjour

2 autres piste à analyser.

1. Pour vider une table, voir si TRUNCATE peut être utilisé.
2. les CLONE table sont une piste à analyser

a+

Il me semble qu'on ne peut pas inactiver le loging avec truncate, d'où grosse charge de log

[masson_r]

Effectivement, le TRUNCATE semble adapté à une suppression rapide.

Pour le CLONE, je ne connais pas. Je vais regarder, mais la piste semble intéressante

A suivre...

bonjour

2 autres piste à analyser.

1. Pour vider une table, voir si TRUNCATE peut être utilisé.
2. les CLONE table sont une piste à analyser

a+

[escartefigue]

Outre la différence au niveau de la charge de log db2 par rapport à un load dummy avec "log no"
il y a aussi une différence au niveau des privilèges : truncate requiert des droits de type delete alors qu'un load requiert des droits DBADM

[masson_r]

Une personne pourrait-il m'en dire un peu plus sur le "Load Dummy"?

J'ai vu ce terme revenir plusieurs fois, mais je ne connais pas.

Outre la différence au niveau de la charge de log db2 par rapport à un load dummy avec "log no"
il y a aussi une différence au niveau des privilèges : truncate requiert des droits de type delete alors qu'un load requiert des droits DBADM

[escartefigue]

Il s'agit simplement de charger la table en mode replace avec en entrée un fichier vide ("dummy file")

On évitera en ce cas d'activer les stats lors du load bien sur

[escartefigue]

Voici un exemple de job de chargement pour un TS segmenté

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
 
//X67JOB   JOB (DB2LD),'LOAD REPLACE TEST',CLASS=S,MSGCLASS=T,           
//          REGION=4M,NOTIFY=&SYSUID,RESTART=*                            
//*--------------------------------------------------------------------*  
//DB2LOAD  EXEC PGM=DSNUTILB,REGION=0M,PARM='DB2T,LOADX67'              
//STEPLIB  DD DISP=SHR,DSN=SYSR.DB2RECT.SDSNLOAD                          
//CEEDUMP  DD SYSOUT=*                                                    
//DSNTRACE DD SYSOUT=*                                                    
//STPRIN01 DD SYSOUT=*                                                    
//SYSPRINT DD SYSOUT=*                                                    
//SYSTSPRT DD SYSOUT=*                                                    
//SYSUDUMP DD DUMMY                                                       
//UTPRINT  DD SYSOUT=*                                                    
//SORTWK01 DD UNIT=(WORKDA,P),SPACE=(CYL,(15,50))                         
//SORTWK02 DD UNIT=(WORKDA,P),SPACE=(CYL,(15,50))                         
//SORTWK03 DD UNIT=(WORKDA,P),SPACE=(CYL,(15,50))                         
//SORTWK04 DD UNIT=(WORKDA,P),SPACE=(CYL,(15,50))                         
//SORTWK05 DD UNIT=(WORKDA,P),SPACE=(CYL,(15,50))                         
//SORTOUT  DD UNIT=(WORKDA,P),SPACE=(CYL,(50,50))                         
//SYSUT1   DD UNIT=(WORKDA,P),SPACE=(CYL,(50,50))                         
//SYSERR   DD UNIT=(WORKDA,P),SPACE=(CYL,(50,50))                         
//SYSDISC  DD SYSOUT=*                                               
//SYSREC00 DD DUMMY 
//SYSIN    DD *                                                      
  LOAD DATA REPLACE INDDN SYSREC00 LOG NO 
  INTO TABLE TST2.TCIS012            
//         DD DISP=SHR,DSN=TEST.TCIS012.SYSPCH            
//

Pour un TS partitionné, on remplacera la sysin comme suit (dans cet exemple, on vide la partition 12)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
 
  LOAD DATA INDDN SYSREC00 LOG NO 
    INTO TABLE TST2.TCIS012  PART 12 REPLACE

[masson_r]

Il s'agit simplement de charger la table en mode replace avec en entrée un fichier vide ("dummy file")

On évitera en ce cas d'activer les stats lors du load bien sur

Pour les stats, je comprends

Par contre, dans le cadre d'un traitement ETL, ou est l’intérêt du fichier vide d'entrée? Je ne saisie pas trop le concept.

[escartefigue]

Le truc c'est que pour vider une table par load (ou plus précisément un tablespace ou une partition d'un tablespace), il faut un fichier vide en entrée.
Sur mainframe il n'est pas nécessaire de créer physiquement ce fichier vide, car on peut le déclarer en "dummy"
Avec un ETL, il faut ce fichier vide pour réaliser l'opération.

[masson_r]

Bon, je met un fichier vide en entrée de l'ETL pour vider la table. Ensuite, je vais pouvoir la remplir avec mes données (nous sommes dans un contexte annulé/remplace).
Du coup, comment accéder aux données le temps du chargement? (qui dans mon cas prennent quelques minutes)

Le truc c'est que pour vider une table par load (ou plus précisément un tablespace ou une partition d'un tablespace), il faut un fichier vide en entrée.
Sur mainframe il n'est pas nécessaire de créer physiquement ce fichier vide, car on peut le déclarer en "dummy"
Avec un ETL, il faut ce fichier vide pour réaliser l'opération.

[bernard59139]

Pas possible.
Il n'y a pas de "shrlevel change" avec "load replace".

[escartefigue]

Pas possible.
Il n'y a pas de "shrlevel change" avec "load replace".

Ce n'est pas possible et pas souhaitable, pendant l'exécution d'un utilitaire, il faut isoler les données pour éviter tout effet parasite genre deadlock. C'est pourquoi les utilitaires sont le plus souvent exécutés hors plage d'activité des services utilisateurs (de nuit ou le WE en général)

[masson_r]

OK, merci pour les réponses et la qualité des échanges