Discussion :

[martin_alexandre_fr]

Bonjour,

Je reprends une base de données de statistiques sous Oracle 10g.
Cette base a beaucoup de mal à fonctionner et est très lente.
Actuellement j'ai le file system qui a mal.

J'essaye de voir comment optimiser les tablespaces.

Actuellement sous oradata, j'ai ceci :

du -h *
9,8M control01.ctl
9,8M control02.ctl
9,8M control03.ctl
8,0G DATA.dbf
8,0G INDX.dbf
4,1M redo01.log
4,1M redo02.log
4,1M redo03.log
183M sysaux01.dbf
273M system01.dbf
76K temp01.dbf
9,9G undotbs01.dbf
13G users01.dbf

La base contient des tables de plusieurs millions d'enregistrements et notamment une qui doit contenir 100 000 enregistrements par jour * 365 (un an de données d'historique).

Afin que cela fonctionne, je dois revoir l'ensemble de la configuration de la base (initora, ...).

Au niveau des tablespaces, vaut il mieux avoir plusieurs ddbf ou un seul ?
Est qu'il est intéressant de passer en BIGFILE dans mon cas de figure ?


Autres symptomes :
- un dump de cette base prend une journée,
- la suppression d'une colonne dans la plus grosse table prend facile 1h...


Merci,

Alex


PS : soyez indulgent, je débute.

[a.presles]

Bonjour,

Quel sont les system disques a ta disposition.
- Baie SAN avec beaucoup de disque en raid 5 (ou variante).
- disque locaux avec systeme de fichier evolué (VXFS ou autre system avec volume groupe et logical volume)

-disque locaux simple

quel sécurité a tu besoin au niveau de la perte d'un disques (sa fini toujours par arriver un jour ou l'autre).

faut-il favorisé la simplisité de maintenance, la sécurité ou la performance.

Mon choix en général.

j'ai une baie rapide et sécurisé donc pour me simplifier la vie.Je fais confiance a la baie pour tout. je met tout comme dans ta config. Je met simplement les sauvegardes, les archivelogs, une copy des log et des controlfiles dans un autre filesystem sur un autre disque groupe.

a l'epoque ou je n'avais pas de baie

je séparais les DATA, les index, les log et une copy du controlfile et log sur plusieur disques, si suffisement de disques je separe aussi les data est les index en plusieurs disque (mettre les filesystems dans des logical volume sur des disque groupe pour simplifie la maintenance). Heuresement cette époque et révolue pour moi. je peu faire autre chose que gérer de l'espace disque.

Il y a aussi ASM qui permet de faire une sorte de baie du pauvre qui apporte performance et sécurité au prix d'un peu plus de compléxite de gestion qu'une baie. On n'accéde pas directement au fichiers il faut apprendre a utilisé ASM.

Je n'ai utilisé ASM que pour faire tourner un RAC se qui me semble sa vrai utilité de nos jours.

[martin_alexandre_fr]

En fait j'ai un simple serveur avec un disque....

Quel est l'interet d'avoir plusieurs datafile dans un tablespace ?

As-tu une idee des ameliorations de base que je pourrais apporter pour optimiser mon système ?

Je présise que je ne peux pas changer l'architecture disque.

alex

[13thFloor]

Bonjour,
avant d'apporter des améliorations, il faudra savoir ce qui ne va pas.
Utilise awr : sous SQL*Plus (/ as sysdba) lance @?/rdbms/admin/awrrpt et choisi une période d'activité significative.
Analyse ensuite le rapport généré (ou copie-colle-le sur http://www.statspackanalyzer.com/analyze090630.asp qui te fournira quelques indications).
Regardes également le comportement du système : utilisation cpu et swap, activité IO...
Les accès aux données sont-ils mono-lignes ou multi-lignes ?
Si mono-lignes, il manque peut être des index.
En fonction de la RAM du serveur, tu peux mettre en cache les données les plus accédées.
Le rapport AWR te fournira ces indications et notamment :
- les principales attentes
- les temps d'accès aux datafiles
- les requêtes les plus consommatrices (cpu et IO)
- les contentions

Le bigfile est limité à un seul (gros) fichier (50Go) par tablespace : pas top top.
Tout étant sur un seul disque, il y a fort à parier que ça contentionne sévère sur le disque (% wait io important ) puisque tout s'y fait en simultané : lecture/écriture des données, écriture des redo, écriture/lecture des undo etc.

24h pour exporter environ 20G de data (users + data) me semble très élevé.

[a.presles]

donc pas de possiblité d'améloiré l'achitecture il faut donc limité au maximum les IO. Donc créer des index qui correspondent a l'utilisation normale de ta base.
voir quelles sont les requetes dans AWR.
Mais tu aura de toute façon de la contention disque.
Pour ton export il sera peu être plus rapide si tu export ta base sur un poste client comme ca tu lit sur le serveur et ecris sur le client ou simplement cree ton export sur un disque réseau.
pour le drop d'une colonne (ca doit pas être courant comme opération) ca sera toujours long. Aprés cette opération il est bon de faire de la réorganisation.
- un petit shrink de ta table améliorera tes perf mais le shrink va être trés long.
- Ou fait un move de la table avec rebuild des indexes (ces opération de maintenance sont a programmer dans une plage de maintenance sans connexion des users)