Version imprimable
Bonjour,
Je souhaiterais avoir des info sur la commande DB2 LOAD pour pouvoir loader un fichier sequentiel, dans une table, qui contient une partie des enregistrements de cette table mais modifiés. Ceci dans le but de faire une mise à jour.
PS: je n'ai pas accès aux commandes INSERT,DELETE et UPDATE
Je suis sur un environnement DB sur serveur Mainframe Z/OS
Merci pour votre aide
Salut,
Si tu n'as pas un accès minimum DBADM (administrateur DB), tu n'auras pas accès à la commande LOAD.
Ce qui semble être le cas, vu que tu n'as pas les autorisations pour insert update delete.
:?
Je sais mais du coté client, il est préférable de lui demandé un LOAD plutôt que plusieurs INSERT, DELETE, SELECT ... C'est pourquoi je pose la question ci dessus ...
Il faut également un privilège RACF (ou TSS) SYSCTRL ou SYSADM.
Tu as un fichier séquentiel : la SYSREC contenant tes enregistrements
Tu as un fichier Syspunch décrivant le fichier SYSREC: de position 1 à position 8, c'est le champ1, de position 9 à 16, le champ 2, etc...
Attention, le LOAD meme en mode RESUME YES ne fait pas d'update ni de DELETE. Il insère uniquement de la donnée.
http://publib.boulder.ibm.com/infoce...bjnbmstr19.htm
Dans DB2 for z/OS le LOAD est l'équivalent de ce qu'on nomme dans d'autres SGBD un IMPORT ...
LOAD et IMPORT existent tous les deux dans DB2. Mais si ils font sensiblement la même chose, il y a néanmoins des différences marquantes.Citation:
Dans DB2 for z/OS le LOAD est l'équivalent de ce qu'on nomme dans d'autres SGBD un IMPORT ...
- L'import charge/update la table ET écrit dans le log de DB2, en cas de restore de la DB, les modifications sont restaurées aussi pendant le ROLLFORWARD.
- D'ou l'interêt dans un import d'ajout des COMMIT (par ex: 200 , suivant la taille et le nombre des logfiles).
-LOAD charge/update la table mais n'écrit pas dans les logfiles.
-LOAD laisse la table en BACKUP PENDING et bloque le tablespace en mode lecture uniquement jusqu'a la prise de Backup (de la DB où du tablespace).
Dans les deux cas, un RUNSTAT est toujours une bonne idée.
:pc:
Bonjour,
Quelques précisions :
- import / export sont des utilitaires propres à DB2 Linux Unix Windows. On peut tout de même utiliser export à partir d'un client remote pour aller chercher les données sur DB2 z/OS. Pour l'import, c'est peut-être possible aussi. Leur utilisation sur z/OS est à ma connaissance marginale.
- l'équivalent dans db2 z/OS est : l'unload ou le dsntiaul pour l'export. Le load en shrlevel change pour l'import, le load tout court pour le load luw.
- le load z/OS bloque en lecture / écriture le tablespace à moins qu'il ne soit partitionné et qu'il ne contienne pas d'index non partitionné. Il peut soit être en log yes ( il n'y a pas d'état copy pending ensuite ) soit en log no, il faut alors faire un copy soit online cad en même temps que le load ( il faut alors faire un quiesce à la suite ).
- si tu dois faire des insertions à partir d'un client remote et modifier des données existantes, le load z/OS n'est pas la bonne option. En fonction de la volumétrie des données à charger / modifier, tu peux soit considérer l'écriture d'une procédure stockée s'il y'a de la logique applicative ou si tu peux traiter en paquet tes données, soit des accès odbc / jdbc ( tu peux aussi faire des batch SQL en jDBC ), soit transférer ton fichier et le traiter via un pgm cobol.
D'une manière générale, le choix est fonction de la volumétrie des données à charger et de la disponibilité exigée pour la table.
Je te conseille de te rapprocher des DBA z/OS, pour que tu saches ce que tu as le droit de faire.
Alex.
Sauf si j'ai mal lu :D :D :D mais il est question ici de DB2 for z/OS.Citation:
Envoyé par ALHER
Dans cet environnement la commande IMPORT (on parle d'utilitaire plutôt) n'existe pas ...
Autant pour moi, il y a trop longtemp que je n'ai plus vu un DB2 sur Z/OS autrement qu'a travers un control center en remote.Citation:
Sauf si j'ai mal lu mais il est question ici de DB2 for z/OS.
Dans cet environnement la commande IMPORT (on parle d'utilitaire plutôt) n'existe pas ...
Ceci dit, cela reste valable pour les plateformes UNIX et Windows.
D'où l'intérêt, lorsqu'on parle de DB2, de toujours bien préciser la plateforme ...Citation:
Envoyé par ALHER