IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Administration Oracle Discussion :

Augmentation ressource base en 8


Sujet :

Administration Oracle

  1. #1
    Membre du Club
    Inscrit en
    Octobre 2009
    Messages
    47
    Détails du profil
    Informations forums :
    Inscription : Octobre 2009
    Messages : 47
    Points : 48
    Points
    48
    Par défaut Augmentation ressource base en 8
    Bonjour,

    J'ai un serveur applicatif sous solaris 9 qui contient une base oracle 8.1.7.
    Cette base est configurée avec 6 Go de SGA.
    J'ai vu que la mémoire disponible sous 20 Go totale est encore de 8 Go et le serveur ne swap pas.

    Je souhaiterais augmenter les ressources mémoires de ma base de 2 ou 3 Go mais j'ai suivi un cursus (récent) sous Oracle 10 et je ne suis pas familier avec la 8. Par exemple je ne retrouve pas les paramètres de PGA.

    Quel serait selon vous les paramètres mémoires à augmenter en priorité pour optimiser ma base ? SGA ou autres pramètres.
    L'applicatif est un CRM (consultations, modifications en journée 75 users) et en traitement batch (facturation de 3000 factures, mises à jour comptes clients, calcul financier) la nuit.

    Pour info, les valeurs actuelles
    SGA
    Pool Partagé : 5722 Mo
    Cache de tampon : 364 Mo
    Large Pool : 0 Mo
    Java Pool : 19 Mo

    J'ai le paramètre sort_area_size à 128 Ko ce qui me semble ridicule mais bon comme je l'ai dis je ne connais pas la 8.

    Merci de votre aide.

  2. #2
    Membre averti Avatar de voran
    Profil pro
    Inscrit en
    Janvier 2005
    Messages
    242
    Détails du profil
    Informations personnelles :
    Localisation : France, Maine et Loire (Pays de la Loire)

    Informations forums :
    Inscription : Janvier 2005
    Messages : 242
    Points : 346
    Points
    346
    Par défaut
    Le buffer cache semble ridiculement petit par rapport à la shared pool size.
    A moins qu'il ne s'agisse de la shared pool qui dispose d'une taille exagéré.

    Le paramètre sort_area_size peut en effet être optimisé, mais attention, il s'agit de la taille allouée pour chaque session d'un processus serveur. Donc, au moins 128Ko * 75 en journée. Et encore faut diagnostiquer des attentes disques dû a des opérations de tri (order by, group by ...)

    De toute façon, avant de toucher à quoi que ce soit il faut définir où cela pêche et pourquoi.
    Vous devrez utiliser les vues systèmes ou bien l'ancêtre de statspack, à savoir : UTLBSTAT/UTLESTAT

    Quel type de problème rencontrez vous sur cette base ?

  3. #3
    Membre du Club
    Inscrit en
    Octobre 2009
    Messages
    47
    Détails du profil
    Informations forums :
    Inscription : Octobre 2009
    Messages : 47
    Points : 48
    Points
    48
    Par défaut Répartition share Pool et buffer cache ?
    Bonjour,

    Nous n'avons pas spécialement de problèmes.
    Sinon que nous disposons de beaucoup de mémoires que nous pourrions allouées à cette instance pour améliorer les traitements de nuit.
    Pour le buffer cache, effectivement il y un problème, merci de me le signaler : Cela sera donc la première action a effectuer. Si nous restons sur un dimensionnement totale de la SGA à 6 Go, y a t-il une règle pour répartir la mémoire entre le buffer cache et la share pool ? Etant formé en 10, je positionne le paramètre sga_target et je ne suis pas familier de ce genre de de paramétrage.
    Tout conseil sera le bienvenue.
    Merci

  4. #4
    Membre régulier
    Profil pro
    Inscrit en
    Février 2005
    Messages
    283
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2005
    Messages : 283
    Points : 122
    Points
    122
    Par défaut
    Bonjour,

    Avant de vouloir faire de l'optimisation, il faut détecter les contentions.

    Vouloir augmenter le buffer cache oui si le 'hit ratio' est vraiment faible et encore tout dépend du contexte de l'application.

    Je pense que la première chose à faire serait d'installer statspack et de programmer une prise d'info ttes les demi-heures.

    Ensuite il sera temps de décider de la marche à suivre.

    Concernant le paramètre sga_target il n'existe pas en 8i, il apparait en 9i puis en 10g avec sga_max_size.

    Il serait interessant de voir le nombre max de cnx simultannées afin de statuer sur les zones de tri.

    Bon c'est vrai que 128Ko ce n'est pas énorme mais est ce que le tablespace temporaire est vraiment sollicité ? Si ce n'est pas le cas la zone de tri est suffisament dimensionnée.

    Cdt,
    Alain

  5. #5
    Membre du Club
    Inscrit en
    Octobre 2009
    Messages
    47
    Détails du profil
    Informations forums :
    Inscription : Octobre 2009
    Messages : 47
    Points : 48
    Points
    48
    Par défaut
    merci pour vos réponses.
    Cela me donne des pistes pour continuer.

  6. #6
    Expert éminent
    Avatar de pachot
    Homme Profil pro
    Developer Advocate YugabyteDB
    Inscrit en
    Novembre 2007
    Messages
    1 821
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : Suisse

    Informations professionnelles :
    Activité : Developer Advocate YugabyteDB
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Novembre 2007
    Messages : 1 821
    Points : 6 443
    Points
    6 443
    Billets dans le blog
    1
    Par défaut
    Bonjour,
    Citation Envoyé par sellfe Voir le message
    Sinon que nous disposons de beaucoup de mémoires que nous pourrions allouées à cette instance pour améliorer les traitements de nuit.
    Concernant un traitement de type batch, sauf s'il est designé de manière exotique, on peut s'attendre à ce que:
    - il y ait peu de données relues frequemment, à l'exception de tables de référence
    - par contre on peut s'attendre a bénéficier d'une grosee SGA sur les tris et hash joins

    Donc sort_area_size est un bon candidat:
    - un peu plus que 128k de toute facon au niveau de l'instance. Pourquoi pas 1M ou 5M
    - et le setter pour la session batch à une valeur plus grande (en centaine de MB)

    Sinon, effectivement buffer cache est petit et shared pool est énorme. Il n'y a pas 5GB de reqête SQL et de procedures PL/SQL dans ton appli, je suppose !

    Cordialement,
    Franck.
    Franck Pachot - Developer Advocate Yugabyte 🚀 Base de Données distribuée, open source, compatible PostgreSQL
    🗣 twitter: @FranckPachot - 📝 blog: blog.pachot.net - 🎧 podcast en français : https://anchor.fm/franckpachot

  7. #7
    Membre averti
    Profil pro
    Inscrit en
    Mars 2007
    Messages
    750
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2007
    Messages : 750
    Points : 341
    Points
    341
    Par défaut
    je me demande si en 8i les vues v$_SHARED_POOL_ADVICE et V$DB_CACHE_ADVICE existent.
    Si oui, tu peux les utiliser à titre indicatif pour trouver la taille optimal e de tes différentes zones mémoires.

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. ID de ressources basées sur d'autres ID de ressources
    Par Pascal_33 dans le forum Visual Studio
    Réponses: 0
    Dernier message: 05/01/2011, 11h46
  2. Réponses: 9
    Dernier message: 08/12/2006, 10h36
  3. [MSSQL 2000] Ma base augmente sans "raison"
    Par thehush dans le forum MS SQL Server
    Réponses: 1
    Dernier message: 22/09/2006, 14h01
  4. [ADMIN] Augmentation du PROCESSES = base figée
    Par ni0urk dans le forum Oracle
    Réponses: 2
    Dernier message: 13/12/2005, 16h36
  5. Augmentation de la taille de la base
    Par jfphan dans le forum MS SQL Server
    Réponses: 2
    Dernier message: 24/02/2004, 10h54

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo