Réglages pour meilleures performances [Résolu]

[seb500]

Bonjour,

J'utilise un programme java qui accède à une base Oracle via jdbc. Mon but est d'insérer 7 millions de records dans ma base le plus vite possible. Pour à peu près les 60 premiers milliers d'insertions cela va très vite (10'000 insertions en 20 sec) puis cela ralentit violemment ensuite. A savoir que mon programme java exécute un update et un select de temps en temps en plus des inserts.

Ma première question est qu'est-ce que je peux faire pour aller plus vite quitte à ce qu'Oracle utilise ttes les capacités de la machine? Est-ce que vous avez des combines?

Deuxièmement et juste pour info, est-ce qu'il serait possible que Oracle stock en mémoire les premiers milliers de requêtes ou est-ce que l'énorme ralentissement serait juste du à l'augmentation du nombre de records dans la base?

Merci d'avance!

[sofiane1111]

Si j'ai bien compris, le traitement que ton programme java fait n'est pas uniquement un chargement de record, il test avant de charger .Donc c'est une sorte de mise à niveau de ta base par rapport à une autre base selon une certain politique

Si c’est le cas il faut donnée un maximum de détails sur ce traitement pour conclure si il y a une possibilité pour l'optimisé.

[Marc Musette]

et redo logs ? ils ont quelles tailles ? ils sont sur quels disques ? es-tu en mode archivelog ? si oui, sur quels disques ? les mêmes que les redo ? et le datafile auquel appartient la table ?

tu fais un commit tous les combien ?

aussi pourquoi charger autant de records via une connexion javajdbc ? pourquoi pas sqlloader en direct mode ? quels sont tes select exécutés lors du chargement ? pourquoi ne pas utiliser du BULK processing via le pl/sql

et puis surtout , tu veux que cela soit réalisé en combien de temps ? et en combien de temps cela est-il réalisé aujourd'hui ???

[seb500]

Merci de vos réactions rapides!

C'est vrai que j'ai été un peu vague sur le fonctionnement de mon applic. En gros elle reçoit en input un fichier qu'elle analyse et insert les données dans la base oracle. Selon sur quoi elle tombe elle peut aussi aller modifier des records existants. Il y a vraiment une étape d'analyse et c'est donc pour cette raison que je ne charge pas la base d'une autre facon.

En ce qui concerne les redo log, ils ont une taille d'enregistrement de 72 et je n'ai aucune idée sur quel disque ils sont... Comment tu vois ca?
Je ne suis pas en mode archivelog.
Pour les commits, mon programme java lançait un commit tous les 20'000 insertions. Puis je l'ai enlevé pour voir et cela ne changeait rien sur le temps d'exécution... Est-ce qu'il y a moyen de mettre un auto-commit dans Oracle Enterprise manager? Est-ce que ca vaudra le coup?

Pour te donner un ordre d'idée du temps nécessaire, pour un million d'insertion ca m'a pris environ 24 heures et j'en ai 7 millions à insérer... En sachant que plus ca avance et plus ca ralentit ca doit bien prendre plus que 7 jours... Je sais que ce n'est pas du coté de java que ca traine car en utilisant une base Access cela va nettement plus vite et j'arrive à environ 1000 insertions en 4 secondes et sans aucun ralentissement à mesure que la base se remplit... Le but serait de réduire le temps nécessaire à un ou deux jours max si c'est possible...

N'hésitez pas si vous avez d'autres questions...

[McM]

Vérifie si c'est pas ta table d'insertion qui fait des extends.
Quelle est sa caractéristique (taille, initial, next).
Pas de trigger dessus ?

[McM]

Pour les redo :

Code :

SELECT * FROM dba_data_files

Pour 7M d'enreg, mieux vaut mettre des commit intermédiaires.

[orafrance]

sans les waits générés pendant la session ça va être compliqué de savoir d'où ça vient

[seb500]

je sais pas si ma table d'insertion fait des extends, voila ses caractéristiques:
taille initiale: 64 KO
taille suivante: 0 KO
Augmenter la taille de 0%
Il y a un trigger dessus pour utiliser une séquence afin d'incrémenter ma clé primaire (puisqu'il n'y a pas d'auto-increment), c'est tout.

Des commits intermédiaires d'accord, mais tous les 10'000, 100'000, 1'000'000?

[pifor]

Envoyé par McM

Pour les redo :

Code :

SELECT * FROM dba_data_files

Non, DBA_DATA_FILES ne liste que les datafiles (les fichiers de données utilisés par les tablespaces non temporaires) et non les online redo logs.Pour lister les online redo logs, il faut utiliser V$LOGFILE et V$LOG.

[remi4444]

Envoyé par seb500

A savoir que mon programme java exécute un update et un select de temps en temps en plus des inserts.

Est-ce que par hasard le temps passé n'est pas dans ces quelques select et update ?

[McM]

Envoyé par seb500

je sais pas si ma table d'insertion fait des extends, voila ses caractéristiques:
taille initiale: 64 KO
taille suivante: 0 KO
Augmenter la taille de 0%
Il y a un trigger dessus pour utiliser une séquence afin d'incrémenter ma clé primaire (puisqu'il n'y a pas d'auto-increment), c'est tout.

Des commits intermédiaires d'accord, mais tous les 10'000, 100'000, 1'000'000?

Pour voir les extends :

Code :

1
2
3
4
5
SELECT SUM(bytes) / 1024 / 1024 AS Mo, COUNT(*) AS nb
FROM DBA_EXTENTS
WHERE tablespace_name = 'LETABLESPACE'
AND segment_type ='TABLE'
AND segment_name = 'LATABLEINSERTION'

Mais je suppose qu'avec des extends de 64 Ko, ca doit être monstreux.

[Marc Musette]

vérifie si le tablespace dans lequel la table est créée est bien LMT et ASSM

Code :

1
2
3
4
5
6
 
SELECT TABLESPACE_NAME FROM DBA_TABLES WHERE table_name = 'NOM_TABLE';
 
SELECT EXTENT_MANAGEMENT, SEGMENT_SPACE_MANAGEMENT 
FROM dba_tablespaces
WHERE TABLESPACE_NAME = 'NOM_TBS';

cette dernière requête devrait te renvoyer LOCAL, AUTO ce qui devrait exclure un problème d'allocation des extents

néanmoins, il semble opportun commele précisait orafrance de nous envoyer un trace de ta session lorsqu'elle exécute ta procédure

il y a trop de possibilités (pblm des redo trop petis sur même disque que TEMP par exemple, pblm de PGA, pblm d'UNDO qui ne grandit pas assez vite ...)

[pifor]

Pour vérifier la gestion des extents il faut utiliser DBA_TABLESPACES.EXTENT_MANAGEMENT:

EXTENT_MANAGEMENT VARCHAR2(10) Indicates whether the extents in the tablespace are dictionary managed (DICTIONARY) or locally managed (LOCAL)
SEGMENT_SPACE_MANAGEMENT VARCHAR2(6) Indicates whether the free and used segment space in the tablespace is managed using free lists (MANUAL) or bitmaps (AUTO)

[plabrevo]

Envoyé par seb500

Il y a un trigger dessus pour utiliser une séquence afin d'incrémenter ma clé primaire (puisqu'il n'y a pas d'auto-increment), c'est tout.

C'est tout mais malgre tout suffisant pour degrader les performances dans un ratio de 1 a 10.

Verifier que:
1) le trigger est absolument necessaire pour recuperer la valeur de cle
2) sinon, que la sequence a ete creee avec un CACHE significatif.

[seb500]

Envoyé par remi4444

Est-ce que par hasard le temps passé n'est pas dans ces quelques select et update ?

Oui effectivement, tout le temps quasiment passait dans un select qui m'avait échapé... La ca va beaucoup mieux, j'insère 1 million de lignes en environ 30 minutes alors qu'avec le select qui s'exécutait à chaque insertion il me fallait plus de 24 heures!!!!

En tout cas merci à tous pour votre coup de main!