Parfois, la sagesse conventionnelle n'est pas si conventionnelle ou commune. À titre d'exemple, les DBA peuvent croire que le pool STREAMS est strictement réservé aux processus de flux. Ce n'est pas le cas car d'autres utilitaires Oracle, tels que Data Pump et GoldenGate, utilisent ce pool. Bien sûr, choisir d'utiliser la gestion dynamique allouera automatiquement la mémoire requise lorsqu'une demande est faite, mais cette mémoire doit provenir de quelque part. Oracle "volera" ce dont il a besoin dans le cache de tampon, et il ne sera pas remplacé immédiatement. Regardons un exemple prouvant cela, en utilisant Data Pump.
La 'victime' sera une base de données Oracle 12.1.0.2 configurée avec le streams_pool_size défini sur 0 (puisque Streams n'est pas configuré, on s'attend à ce que le pool ne soit pas utilisé) et la gestion automatique de la mémoire partagée configurée (les paramètres sga_target et sga_max_size sont défini sur des valeurs non nulles) :
SQL> --SQL> -- Le pool de flux n'est PAS uniquement forSQL> -- StreamsSQL> --SQL> -- Data pump et GoldenGate useSQL> -- itSQL> --SQL> -- Ne définit pas de taille pour le streamsSQL> -- le pool peut causer des problèmes lorsqu'il est SQL> -- première utilisationSQL> --SQL> --SQL> -- En regardant les paramètres de la base de donnéesSQL> -- vérifier les paramètres sgaSQL> -- pour le dimensionnementSQL> --SQL> afficher le paramètre sgaNAME TYPE VALEUR---------------------------------------- -------- --- ------------------------------lock_sga booléen FALSEpre_page_sga booléen TRUEsga_max_size grand entier 600Msga_target grand entier 600Munified_audit_sga_queue_size entier 1048576
En vérifiant la vue V$SGA_DYNAMIC_COMPONENTS pour les composants avec des tailles actuelles non nulles, les résultats suivants sont renvoyés :
SQL> SQL> format de composant de colonne a29SQL> set linesize 300 numwidth 12SQL> SQL> select component, current_size, min_size, max_size, user_specified_size user_spec_sz, 2 oper_count, last_oper_type, last_oper_mode, last_oper_time, granule_size 3 from v$sga_dynamic_components 4 where current_size> 0;COMPONENT CURRENT_SIZE MIN_SIZE MAX_SIZE USER_SPEC_SZ OPER_COUNT LAST_OPER_TYP LAST_OPER LAST_OPER GRANULE_SIZE---------------- ---- ------------ ------------ ------------ ---------- -------------- --------- --------- ------------piscine partagée 176160768 146800640 176160768 0 6 CROISSANCE DIFFÉRÉE 15-OCT-19 4194304grande piscine 8388608 8388608 125829120 0 1 RÉTRACTION DIFFÉRÉE 15-OCT-19 4194304java piscine 4194304 4194304 4194304 0 0 STATIQUE 4194304Cache tampon par défaut 411041792 301989888 419430400 0 8 SHRINK REPORTED 15-OCT-19 4194304Shared IO Pool 20971520 0 20971520 0 1 GROW IMMEDIATE 15-OCT-19 4194304SQL>
Vérification que streams_pool_size est défini sur 0 :
SQL> SQL> --SQL> -- Vérifier que le pool de flux est défini surSQL> -- 0SQL> --SQL> afficher le paramètre streamsNAME TYPE VALUE---------------- -------------------- ----------- ------------------- -----------streams_pool_size grand entier 0SQL>
Une exportation Data Pump est exécutée et, ensuite, la taille des composants de la mémoire dynamique est vérifiée :
SQL> SQL> --SQL> -- Exécutez une tâche d'exportation Data PumpSQL> -- et voyez ce qui arrive à la colonne streamsSQL> -- pool sizeSQL> --SQL> !expdp parfile=expdp_test.parSQL> SQL> format de composant a29SQL> définir la taille de ligne 300 numwidth 12SQL> SQL> sélectionner le composant, taille_actuelle, taille_min, taille_max, taille_spécifiée_utilisateur user_spec_sz, 2 oper_count, last_oper_type, last_oper_mode, last_oper_time, granule_size 3 à partir de v$sga_dynamic_components 4 où taille_courante> 0; COMPONENT CURRENT_SPIZE MIN_SIZE MAX_SIZE OPER_COUNT LAST_OPER_TYP LAST_OPER LAST_OPER GRANULE_SIZE---------------------------- ------------ ---- -------- ------------ ------------ ------------ ------ ------- --------- --------- ------------piscine partagée 197132288 146800640 197132288 0 11 GROW IMMEDIATE 15-OCT- 19 4194304grand bassin 8388608 8388608 125829120 0 1 RÉTRACTATION DIFFÉRÉE 15-oct-19 4194304java Pool 4194304 4194304 4194304 0 0 statique 4194304 Pool de distribution 8388608 0 8388608 0 2 Grow immédiatement 15-OCT-19 4194304Dault Buffer CACHE 381681664 3019898884194304104103030153. CROISSANCE IMMÉDIATE 15-OCT-19 41943046 lignes sélectionnées.SQL>
Notez que la taille du cache de tampon DEFAULT a été réduite à 381681664 à partir d'un paramètre initial de 411041792, en partie pour aider à "financer" le pool Streams. En testant cette idée, streams_pool_size est défini sur 8M (la valeur qu'Oracle lui a définie dynamiquement) et, pour rendre les tests aussi égaux que possible, la base de données est arrêtée et démarrée :
SQL> SQL> --SQL> -- Définissez streams_pool_size sur currentSQL> -- valueSQL> --SQL> -- Arrêtez et démarrez la base de donnéesSQL> --SQL> alter system set streams_pool_size=8M scope=spfile; Système modifié.SQL> SQL> arrêt immédiatBase de données fermée.Base de données démontée.Instance d'ORACLE arrêtée.SQL> démarrageInstance d'ORACLE démarrée. pré>Les paramètres de mémoire dynamique vérifiés pour les valeurs de départ :
SQL> SQL> --SQL> -- Vérifier le dimensionnement dynamique des composants SGASQL> --SQL> format de composant de colonne a29SQL> définir la taille de ligne 300 numwidth 12SQL> SQL> sélectionner le composant, taille_actuelle, taille_min, taille_max, taille_spécifiée_utilisateur user_spec_sz, 2 oper_count, last_oper_type, last_oper_mode, last_oper_time, granule_size 3 de v$sga_dynamic_components 4 où current_size> 0;COMPONENT CURRENT_SIZE MIN_SIZE MAX_SIZE USER_SPEC_SZ OPER_COUNT LAST_OPER_TYP LAST_OPER LAST_OPER GRANULE_SIZE-------------------- --------- ------------ ------------ ------------ ----- ------- ------------ ------------- --------- --------- ------------piscine partagée 155189248 146800640 155189248 0 2 CROISSANCE IMMÉDIATE 15-OCT-19 4194304grande piscine 125829120 125829120 125829120 0 0 STATIQUE 4194304piscine java 4194304 4194304 4194304 4 0 0 STATIC 4194304streams pool 8388608 8388608 8388608 8388608 0 STATIC 4194304DEFAULT buffer cache 327155712 327155712 335544320 0 2 SHRINK IMMEDIATE 15-OCT-19 41>94>3SQL0SQL4 dump/ /rm /u01/app/oracle/admin/orcl/dpdump/scott.*Exécutez à nouveau la tâche Data Pump avec les paramètres de pool de mémoire ajustés :
SQL> SQL> --SQL> -- Exécutez une tâche d'exportation Data PumpSQL> -- et voyez ce qui arrive à la colonne streamsSQL> -- pool sizeSQL> --SQL> !expdp parfile=expdp_test.parSQL> SQL> format de composant a29SQL> définir la taille de ligne 300 numwidth 12SQL> SQL> sélectionner le composant, taille_actuelle, taille_min, taille_max, taille_spécifiée_utilisateur user_spec_sz, 2 oper_count, last_oper_type, last_oper_mode, last_oper_time, granule_size 3 à partir de v$sga_dynamic_components 4 où taille_courante> 0; COMPONENT CURRENT_SPIZE MIN_SIZE MAX_SIZE OPER_COUNT LAST_OPER_TYP LAST_OPER LAST_OPER GRANULE_SIZE---------------------------- ------------ ---- -------- ------------ ------------ ------------ ------ ------- --------- --------- ------------piscine partagée 197132288 146800640 197132288 0 12 GROW IMMEDIATE 15-OCT- 19 4194304grand bassin 8388608 8388608 125829120 0 1 RÉTRACTATION DIFFÉRÉE 15-OCT-19 4194304java pool 4194304 4194304 4194304 0 0 STATIC 4194304streams pool 8388608 8388608 8388608 8388608 0 STATIC 4194304DEFAULT buffer cache 381681664 264241152 381681664 0 14 GROW DEFERRED 15-OCT-19 4194304Shared IO Pool 20971520 0 20971520 0 1 GROW IMMEDIATE 15-OCT- 19 41943046 lignes sélectionnées.SQL>Notez que le cache de tampon DEFAULT a été augmenté, et non diminué comme dans l'exemple précédent. Aucune mémoire n'a été "volée" dans le cache de la mémoire tampon, de sorte que les performances n'ont pas souffert du déplacement dynamique des ressources. Un problème possible avec la définition de streams_pool_size sur 0 peut être une dégradation des performances au moment où le pool de flux est alloué car le cache de tampon a subi une réduction en même temps que le pool de flux augmentait. Cela peut être particulièrement visible dans les systèmes où la charge utilisateur est plutôt lourde au départ.
Comme mentionné précédemment, GoldenGate utilise également le pool de flux et, en raison de la forte activité de validation au moment du démarrage d'un processus d'extraction, peut présenter une dégradation potentiellement alarmante du service qui dure jusqu'à ce que le processus d'extraction ait terminé ses activités de démarrage. [D'autres processus générés par GoldenGate contribuent au ralentissement, tels qu'une synchronisation globale des fichiers journaux pour vider les données validées dans les journaux redo.] Un système a tellement souffert lorsqu'un processus d'extraction a été lancé que les connexions au système d'exploitation n'ont pas pu se terminer dans le délai imparti. temps, obligeant un logiciel de surveillance tiers à signaler que les bases de données exécutées sur ce serveur n'étaient plus disponibles. La définition de streams_pool_size sur une valeur différente de zéro a grandement contribué à améliorer les performances globales lors du démarrage des processus d'extraction.
La connaissance commune peut être une épée à double tranchant; pour chaque cas où la connaissance commune est vraie, il peut y avoir un ou plusieurs cas où ce n'est pas le cas. La seule vraie solution est de tester cette « sagesse » pour vérifier son exactitude. Il est de loin préférable d'affecter un système de test, de développement ou de « bac à sable » avec de telles enquêtes plutôt que de prendre une telle « connaissance » comme « l'évangile » pour découvrir que les hypothèses sur lesquelles cette « sagesse » était basée étaient erronées. Savoir vaut mieux que deviner; un peu de temps consacré à une enquête peut rapporter d'énormes avantages lorsque vient le temps de mettre en œuvre un nouveau processus impliquant Oracle.
# # #
Voir les articles de David Fitzjarrell
