No deje que la piscina Streams lo engañe

A veces, la sabiduría convencional no es tan convencional o común. Como ejemplo, los DBA pueden creer que el grupo STREAMS está reservado estrictamente para procesos de flujos. Ese no es el caso, ya que otras utilidades de Oracle, como Data Pump y GoldenGate, usan ese grupo. Por supuesto, optar por utilizar la gestión dinámica asignará automáticamente la memoria requerida cuando se realice una demanda, sin embargo, esa memoria debe provenir de alguna parte. Oracle 'robará' lo que necesita del caché del búfer y no será reemplazado de inmediato. Veamos un ejemplo que prueba esto, usando Data Pump.

La 'víctima' será una base de datos de Oracle 12.1.0.2 configurada con streams_pool_size establecido en 0 (dado que Streams no está configurado, la expectativa es que no se utilizará el grupo) y Administración automática de memoria compartida configurada (los parámetros sga_target y sga_max_size son establecido en valores distintos de cero):

SQL> --SQL> -- El grupo de flujos NO es solo para SQL> -- StreamsSQL> --SQL> -- La bomba de datos y GoldenGate usan SQL> -- itSQL> --SQL> -- No establecer un tamaño para streamsSQL> -- pool puede causar problemas cuando es SQL> -- usado por primera vez SQL> --SQL> --SQL> -- Mirando los parámetros de la base de datosSQL> -- verifique los parámetros sgaSQL> -- para dimensionarSQL> --SQL> mostrar parámetro sgaNOMBRE TIPO VALOR------------------------------------------- -------- --- ------------------------------lock_sga booleano FALSEpre_page_sga booleano TRUEsga_max_size entero grande 600Msga_target entero grande 600Munified_audit_sga_queue_size entero 1048576

Al comprobar la vista V$SGA_DYNAMIC_COMPONENTS para componentes con tamaños actuales distintos de cero, se devuelven los siguientes resultados:

SQL> SQL> formato de componente de columna a29SQL> establecer linesize 300 numwidth 12SQL> SQL> seleccionar componente, 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;COMPONENTE TAMAÑO_ACTUAL MIN_SIZE MAX_SIZE USER_SPEC_SZ OPER_COUNT LAST_OPER_TYP LAST_OPER LAST_OPER GRANULE_SIZE----------------------------- -------- ---- ------------ ------------ ------------ ---------- -- ------------- --------- --------- ------------piscina compartida 176160768 146800640 176160768 0 6 CRECIMIENTO DIFERIDO 15-OCT-19 4194304grupo grande 8388608 8388608 125829120 0 1 REDUCCIÓN DIFERIDO 15-OCT-19 4194304java grupo 4194304 4194304 4194304 0 0 ESTÁTICA 4194304Caché de búfer PREDETERMINADO 411041792 301989888 419430400 0 8 REDUCCIÓN DIFERIDA 15-OCT-19 4194304Grupo de E/S compartido 20971520 0 20971520 0 1 CRECIMIENTO INMEDIATO 15-OCT-19 4194304SQL> 

 Verificando que streams_pool_size esté establecido en 0:
 
SQL> SQL> --SQL> -- Verifique que el grupo de secuencias esté establecido en SQL> -- 0SQL> --SQL> muestre el parámetro streamsNOMBRE TIPO VALOR---------------- ----------- ----------- ------------------- -----------streams_pool_size entero grande 0SQL> 
 

 Se ejecuta una exportación de bomba de datos y, posteriormente, se comprueba el tamaño de los componentes de la memoria dinámica:
 
SQL> SQL> --SQL> -- Ejecute una tarea de exportación de bomba de datosSQL> -- y vea qué sucede con la columna streamsSQL> -- pool sizeSQL> --SQL> !expdp parfile=expdp_test.parSQL> SQL> formato de componente a29SQL> establecer linesize 300 numwidth 12SQL> SQL> seleccionar componente, 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_USER_MAX_SIZE Z OPER_COUNT LAST_OPER_TYP LAST_OPER LAST_OPER GRANULE_SIZE----------------------------- ------------ ---- -------- ------------ ------------ ------------ ------ ------- --------- --------- ------------pool compartido 197132288 146800640 197132288 0 11 CRECIMIENTO INMEDIATO 15-OCT- 19 4194304piscina grande 8388608 8388608 125829120 0 1 REDUCCIÓN DIFERIDA 15-OCT-19 4194304java pool 4194304 4194304 4194304 0 0 STATIC 4194304streams pool 8388608 0 8388608 0 2 GROW IMMEDIATE 15-OCT-19 4194304DEFAULT buffer cache 381681664 301989888 419430400 0 15 SHRINK IMMEDIATE 15-OCT-19 4194304Shared IO Pool 20971520 0 20971520 0 1 CRECER INMEDIATO 15-OCT-19 41943046 filas seleccionadas.SQL> 
 

 Tenga en cuenta que el tamaño de caché del búfer DEFAULT se redujo a 381681664 desde una configuración inicial de 411041792, en parte para ayudar a "financiar" el grupo de Streams. Probando esa idea, streams_pool_size se establece en 8M (el valor que Oracle estableció dinámicamente) y, para que las pruebas sean lo más iguales posible, la base de datos se cierra y se inicia:
 
SQL> SQL> --SQL> -- Establezca streams_pool_size en currentSQL> -- valueSQL> --SQL> -- Apague e inicie la base de datosSQL> --SQL> alter system set streams_pool_size=8M scope=spfile; Sistema alterado.SQL> SQL> apagado inmediatoBase de datos cerrada.Base de datos desmontada.Instancia de ORACLE cerrada.SQL> inicioInstancia de ORACLE iniciada.Área global total del sistema 629145600 bytesTamaño fijo 2927528 bytesTamaño variable 289408088 bytesBúferes de base de datos 331350016 bytesBúferes de rehacer 5459968 bytesBase de datos montada.Base de datos abierta.
 

 Los parámetros de memoria dinámica verificados para los valores iniciales:
 
SQL> SQL> --SQL> -- Comprobar el tamaño dinámico de los componentes SGASQL> --SQL> formato de componente de columna a29SQL> establecer linesize 300 numwidth 12SQL> SQL> seleccionar componente, 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-------------------- --------- ------------ ------------ ------------ ----- ------- ------------ ------------- --------- --------- ------------grupo compartido 155189248 146800640 155189248 0 2 CRECIMIENTO INMEDIATO 15-OCT-19 4194304grupo grande 125829120 125829120 125829120 0 0 STATIC 4194304grupo java 41944430 419 4 0 0 estática 4194304Streams Pool 8388608 8388608 8388608 83888608 0 static 4194304default buffer cache 327155712 3271555712 335544320 0 2 redondeo inmediato 15-oct-19 4194304sql> sql> /rm /u01/app/oracle/admin/orcl/dpdump/scott.*
 

 Vuelva a ejecutar el trabajo de bombeo de datos con la configuración del grupo de memoria ajustada:
 
SQL> SQL> --SQL> -- Ejecute una tarea de exportación de bomba de datosSQL> -- y vea qué sucede con la columna streamsSQL> -- pool sizeSQL> --SQL> !expdp parfile=expdp_test.parSQL> SQL> formato de componente a29SQL> establecer linesize 300 numwidth 12SQL> SQL> seleccionar componente, 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_USER_MAX_SIZE Z OPER_COUNT LAST_OPER_TYP LAST_OPER LAST_OPER GRANULE_SIZE----------------------------- ------------ ---- -------- ------------ ------------ ------------ ------ ------- --------- --------- ------------pool compartido 197132288 146800640 197132288 0 12 CRECIMIENTO INMEDIATO 15-OCT- 19 4194304piscina grande 8388608 8388608 125829120 0 1 REDUCCIÓN DIFERIDA 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 filas seleccionadas.SQL> 
 

 Tenga en cuenta que la memoria caché del búfer PREDETERMINADA se incrementó, no se redujo como en el ejemplo anterior. No se "robó" memoria de la memoria caché del búfer, por lo que el rendimiento no se vio afectado por el cambio dinámico de recursos. Un posible problema al establecer streams_pool_size en 0 puede ser la degradación del rendimiento en el momento en que se asigna el grupo de flujos porque la memoria caché del búfer se redujo al mismo tiempo que el grupo de flujos crecía. Esto puede ser especialmente notable en sistemas donde la carga de usuarios es bastante pesada para empezar.
 

 Como se mencionó anteriormente, GoldenGate también usa el grupo de flujos y, debido a la intensa actividad de confirmación en el momento en que se inicia un proceso de extracción, puede presentar una degradación del servicio posiblemente alarmante que dure hasta que el proceso de extracción finalice sus actividades de inicio. [Otros procesos generados por GoldenGate contribuyen a la ralentización, como la sincronización de un archivo de registro global para vaciar los datos confirmados en los registros de rehacer]. Un sistema sufrió tanto cuando se inició un proceso de extracción que los inicios de sesión del sistema operativo no pudieron completarse en el tiempo asignado. tiempo, lo que provocó que el software de monitoreo de terceros informara que las bases de datos que se ejecutaban en ese servidor ya no estaban disponibles. Establecer streams_pool_size en un valor distinto de cero contribuyó en gran medida a mejorar el rendimiento general cuando se iniciaron los procesos de extracción.
 

 El conocimiento común puede ser un arma de doble filo; por cada caso en el que el conocimiento común es cierto, puede haber uno o más casos en los que no lo es. La única solución real es probar tal "sabiduría" para verificar su precisión. Es mucho mejor afectar un sistema de prueba, desarrollo o "caja de arena" con tales investigaciones en lugar de tomar ese "conocimiento" como "evangelio" solo para descubrir que las suposiciones en las que se basó esa "sabiduría" estaban equivocadas. Saber es mejor que adivinar; un poco de tiempo dedicado a una investigación puede generar grandes beneficios cuando llega el momento de implementar un nuevo proceso que involucre a Oracle.
 
# # #
 

 Ver artículos de David Fitzjarrell