Discussion :

[tibal]

Bonsoir,

J'utilise BCP pour la migration d'ASE 12.5 vers 1SE 15.0.3, afin de pouvoir modifier la taille des blocks utilisée. Pour une base de 3 Go de Data, il faut environ 1h15 (et parfois plus) pour effectuer cette migration alors que cette même base migrée via Dump/Load (sans modifier la taille des blocks) met 2 fois moins de temps. Je souhaite connaitre les paramètres sur lesquels je peux jouer pour améliorer les performances de BCP, car la doc Sybase ne dit rien concernant les performances.
Pour info, lorsque je fais mon Load, il est effectué en BCP Fast.

Merci d'avance pour votre aide.

[Arnaud F.]

Bonsoir,

du peux que je sais, une des choses qui peut ralentir l'insertion via BCP c'est la présence d'index sur la table dans laquelle les données sont insérées.

Il est recommandé de n'avoir aucun index sur les tables "BCPisées" et de les rajouter par la suite

My 0,02€...

[tibal]

Bonjour Arnaud et merci pour ta réponse.

Je n'ai ni indexe, ni trigger sur mes tables lorsque j'effectue mon bcp. C'est d'ailleurs pour ça qu'il se fait en mode Fast.

[kagemaru]

salut,

Code :

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

même base migrée via Dump/Load (sans modifier la taille des blocks) met 2 fois moins de temps

donc par dump/load, cela met 30 mins ? Cela me semble un peu long non ? à moins que tu fasses ta migration sur ton pc ?

Le paramètre sur lequel tu peux peut-être jouer est le -b (batch size). Plus le batch size est important et moins l'activité de commit sera importante donc généralement, sur de gros volumes, ça sra plus rapide. ASE matérialise une transaction toutes les <batch size> lignes. Donc si ASE valide toutes les 10000 lignes (par défaut), il peut être interessant de le faire seulement tous les millions par ex. Mais attention à la saturation du journal.

Si tu est sous unix, tu peux également utiliser un canal nommé (pipe) pour effectuer le bcp-out et le bcp-in en simultané pour gagner du temps. Tout est expliqué ici : http://www.sybase.com/detail?id=1080140

Regarde également les régles de fast/slow bcp car depuis la 15.0.2, cela change un peu :

http://infocenter.sybase.com/help/in...502/X65215.htm

Si la table de destination est en mode de verrouillage DOL avec un index cluster et /ou avec des index nonclustered et non uniques, tu fais du fast bcp.

[tibal]

Salut Emmanuel, merci pour la réponse.

Non, la migration se fait entre 2 serveurs 2 CPU quad core multi-thread (soit 16 coeurs visibles) avec 72 Go de RAM, connectés à une baie SAN.

L'augmentation du batch size -b de 10 000 à 1 000 000 m'a généré des erreurs Segmentation fault. Je l'ai repassé à 100 000, pour voir. J'ai vu le document pour canal nommé, mais il indique un CR# 626571 qui n'est pas accessible. Je cherche aussi du coté du -A packet_size ainsi que du buffer pool large IO.

[kagemaru]

salut Tibal

par curiosité, quel hardware/os utilises-tu ? En effet le packet size peut aider également ainsi que les i/o étendues.

Il faut également que tu vérifies côté système d'exploitation si tout est ok (vmstat, iostat).

A+

[tibal]

L'OS est une RedHat 5.4 64bit sur des lames HP avec 2 CPU quadcore multithreadés (16 CPU vues par l'os) avec 72 Go de RAM.
Lors du BCP in, la charge machine est extrèment faible (top, vmstat, iostat, ...). Les serveurs sont pluggués à une baie SAN, où sont localisés les fichiers des bases concernées.

[tibal]

En fait,
Les paramètres que j'ai utilisé pour améliorer les performance du BCP in sont les bons, à savoir :
-b batchsize
-A packet_size
Les erreurs Segmentation fault sont dues à un bug en cours de correction par Sybase. Celle ci ne sera disponible que pour la 15.5, aux alentours de juillet.