Linux Error 29: Illegal Seek

Transcripción

1 Newsletter Febrero 2013 Contenido Página: Por Ing. Manuel Carrillo Linux Error 29: Illegal Seek 1 Linux Error 29: Illegal Seek 3 Oracle 11g: Mejores planes de ejecución con baselines 7 Topologías de Oracle Coherence - Parte 2 5a. Ave Zona14,Edificio Euro Plaza Torre II, Nivel 12 Editores Generales Teléfono: (502) Fax: (502) info@datum.com.gt Deiby Mauricio Gómez Pagina 1/10 Uno de los recursos principales de la capa de Oracle NET es sin duda el listener, Alejandro Lau sin embargo puede que se presente el siguiente escenario en un ambiente Oracle Debbie Morán 11gR2. Autores Contribuyentes Manuel Carrillo Juan Luis Rodríguez Deiby Gómez oracle@node1 $ lsnrctl start LSNRCTL for Linux: Version Production on 13-SEP :33:54 Copyright (c) 1991, 2011, Oracle. All rights reserved. Starting /u01/app/11.2.0/grid/bin/tnslsnr: please wait... TNS-12537: TNS: Connection closed TNS-12560: TNS: Protocol adapter error TNS-00507: Connection closed Linux Error: 29: Illegal seek Por los errores mostrados, el problema pareciera estar en el archivo de configuración de red de la máquina en donde se está tratando de iniciar el servicio del listener. Página 1

2 Cuando revisamos, la entrada o referencia a localhost ( localhost.localdomain localhost) ha desaparecido por alguna razón. Después que dicha entrada es agregada a /etc/hosts, el listener puede iniciar de manera correcta. oracle@node1 $ lsnrctl start LSNRCTL for Linux: Version Production on 13-SEP :38:27 Copyright (c) 1991, 2011, Oracle. All rights reserved. Starting /u01/app/11.2.0/grid/bin/tnslsnr: please wait... TNSLSNR for Linux: Version Production System parameter file is /u01/app/11.2.0/grid/network/admin/listener.ora Log messages written to /u01/app/oracle/diag/tnslsnr/nodo3/listener/alert/log.xml Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=LISTENER))) Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER))) STATUS of the LISTENER Alias LISTENER Version TNSLSNR for Linux: Version Production Start Date 13-SEP :38:31 Uptime 0 days 0 hr. 0 min. 1 sec Trace Level off Security ON: Local OS Authentication SNMP OFF Listener Parameter File /u01/app/11.2.0/grid/network/admin/listener.ora Listener Log File /u01/app/oracle/diag/tnslsnr/nodo3/listener/alert/log.xml Listening Endpoints Summary... (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=LISTENER))) The listener supports no services The command completed successfully. Tip técnico del día: En más de una ocasión nos hemos encontrado en la situación de querer saber si el valor en un campo tipo VARCHAR2 es numérico. En Oracle se puede usar la siguiente función para resolver este problema: translate(nombre_campo,'t ','T') La función translate simplemente comprueba cómo quedaría el campo si le quitásemos todos los dígitos y los espacios. Si el resultado es null, entonces es un número. La T simplemente se usa como carácter auxiliar. Por ejemplo: SQL> select id from prueba where translate(id,'t ','T') is null; ID Por Ing. Deiby Gómez dgomez@datum.com.gt Página 2

3 Oracle 11g: Mejores planes de ejecución con baselines Por Ing. Juan Luis Rodríguez Alguna vez ha encontrado consultas que inesperadamente comienzan a mostrar bajo desempeño? Una revisión podría revelar que se debe a nuevas estadísticas que el optimizador ha recolectado para las tablas e índices referenciados en la consulta. Y completamente desanimado por esta situación, Ha tomado la decisión de detener la recolección de estadísticas? Esta acción mantiene mejor los planes de ejecución para las mismas consultas, pero hace que otras cosas empeoren. El performance de otras consultas, e incluso las mismas consultas con diferente predicado (cláusula WHERE), se deteriora debido a planes de ejecución no óptimos generados por estadísticas desactualizadas. Cualquier acción que se tome puede acarrear algún riesgo, por lo tanto, Cómo se puede mitigar el riesgo y asegurar que los planes de ejecución generados sean óptimos, sin necesidad de cambios significativos (como usar hints)? Para ello puede usar stored outlines para congelar el plan de ejecución, pero esto evita que el optimizador genere planes de ejecución potencialmente beneficiosos. En Oracle 11g, usando la nueva característica SQL plan management se puede examinar cómo los planes de ejecución cambian todo el tiempo, la base de datos verifica los nuevos planes antes de usarlos, y gradualmente involucra los mejores planes de una manera controlada. SQL PLAN MANAGEMENT Cuando se habilita SQL plan management, el optimizador almacena los planes de ejecución en un repositorio especial: SQL management base. Algunos planes de ejecución en este repositorio pueden ser marcados como aceptados. Cuando se "reparsea" la instrucción SQL, el optimizador considera sólo los planes aceptados. Este conjunto de planes aceptados para la instrucción SQL constituye el SQL plan baseline, o baseline de manera abreviada. Figura 1. SQL Plan Baseline y SQL Plan History Página 3

4 Con SQL plan management, se pueden examinar todos los planes de ejecución disponibles en el historial de ejecuciones de una instrucción SQL, compararlos para ver su eficiencia, promover un plan de ejecución específico a estado aceptado, e incluso hacer permanente un plan de ejecución. CAPTURA DE PLANES DE EJECUCIÓN Y USO DE BASELINES SQL plan management captura los planes de ejecución usados por las instrucciones SQL, pero por defecto la captura está desactivada. Para ejemplificar la captura de baselines, ejecutaremos algunas instrucciones SQL en el esquema de ejemplo SH que se provee en Oracle 11g. En particular, usaremos la tabla SALES. Primero, se debe habilitar la captura de baselines en la sesión: SQL> alter session set optimizer_capture_sql_plan_baselines = true; Session altered. Ahora, todas las instrucciones SQL ejecutadas en la sesión serán capturadas en SQL management base, junto con sus planes de ejecución: -- Primera ejecución en ambiente default SQL> select count(*) from sales where quantity_sold > 1; COUNT(*) Cambiando el optimizer_mode SQL> alter session set optimizer_mode=first_rows; Session altered. -- Segunda ejecución con optimizer_mode cambiado SQL> select count(*) from sales where quantity_sold > 1; COUNT(*) Obtener estadísticas SQL> begin dbms_stats.gather_table_stats ( ownname => 'SH', tabname => 'SALES', cascade => TRUE, no_invalidate => FALSE, method_opt => 'FOR ALL INDEXED COLUMNS SIZE AUTO', granularity => 'GLOBAL AND PARTITION', estimate_percent => 10, Página 4

5 / degree => 4 ); end; PL/SQL procedure successfully completed. -- Tercera ejecución, después de estadísticas SQL> select count(*) from sales where quantity_sold > 1; COUNT(*) Uso del SQL plan baseline SQL> explain plan for select count(*) from sales where quantity_sold > 1; Explained. SQL> select * from table(dbms_xplan.display(null, null, 'basic')); PLAN_TABLE_OUTPUT Plan hash value: Id Operation Name SELECT STATEMENT 1 PARTITION RANGE ALL 2 TABLE ACCESS BY LOCAL INDEX ROWID SALES 3 BITMAP CONVERSION TO ROWIDS 4 BITMAP INDEX FULL SCAN SALES_PROMO_BIX Ahora se deshabilitan baselines y se obtiene el plan de ejecución SQL> alter session set optimizer_capture_sql_plan_baselines = false; Session altered. SQL> explain plan for select count(*) from sales where quantity_sold > 1; Explained. SQL> select * from table(dbms_xplan.display(null, null, 'basic')); PLAN_TABLE_OUTPUT Plan hash value: Página 5

6 Id Operation Name SELECT STATEMENT 1 SORT AGGREGATE 2 PARTITION RANGE ALL 3 TABLE ACCESS FULL SALES rows selected. En las dos últimas ejecuciones se puede ver cómo cambia el plan de ejecución al desactivar las baselines. Inicialmente, el optimizador elige BITMAP INDEX FULL SCAN en el índice SALES_TIME_BIX. Después que se desactivan los baselines, el plan de ejecución cambia a TABLE ACCESS FULL para la tabla SALES. CONCLUSIONES El uso de stored outlines también hace un plan de ejecución estable, pero esto implica rigidez. El optimizador identifica que hay un outline para una instrucción SQL y detiene la generación de nuevos planes de ejecución. Con baselines, por otro lado, nunca se detiene el optimizador en la generación de un nuevo plan de ejecución. La característica SQL plan management permite almacenar planes de ejecución validados o bien conocidos en la forma de baselines, los cuales son muy útiles al diagnosticar repentinas degradaciones de desempeño. Debido a que los baselines (y el correspondiente plan de ejecución) son almacenados en un repositorio, se pueden hacer comparaciones y decidir el uso eficiente de los planes de ejecución. Puede encontrar más información sobre SQL Plan Management en Página 6

7 Topologías de Oracle Coherence - Parte 2 Por Ing. Deiby Gómez dgomez@datum.com.gt En la parte 1 de este artículo vimos la importancia de tener nuestras aplicaciones altamente disponibles, se realizaron algunas fórmulas para demostrar la disponibilidad de nuestro sistema. En esta segunda parte se tratarán las ventajas y desventajas de una de las topologías básicas de Oracle Coherence: Topología de replicación. Topología de replicación: La topología de replicación almacena cada objeto que se envía a un determinado servidor de Coherence, en todos los demás servidores, de manera que cada cliente pueda acceder cualquier objeto de manera local, logrando con esto una latencia completamente nula. En la siguiente imagen se observa que cada uno de los objetos (A,B,C,D) están replicados en cada uno de los servidores Coherence. Y que cada lectura (get) está siendo realizada de manera local: La latencia nula para un objeto se logra después de su segunda lectura. Cuando un objeto es enviado al cache de Coherence, se serializa y luego se escribe en los N servidores de Coherence existentes en el cluster. Cada servidor recibe el objeto serializado y así lo mantiene hasta que reciba una primera solicitud de lectura, entonces deserializa el objeto y lo mantiene así para las siguientes lecturas, es ahí cuando se alcanza la latencia nula. Entonces podríamos decir que la primera lectura de un objeto implica un costo pequeño: El costo de deserializar el objeto. Las escrituras en una topología de replicación no son tan eficientes como las lecturas, pues cada escritura implica N-1 escrituras adicionales, donde N es el número de servidores Coherence en el cluster. Estas escrituras son necesarias para que la información esté totalmente replicada, Página 7

8 Coherence no termina una escritura completamente hasta que no haya sido escrita en los demás servidores. En la siguiente imagen se observa que al escribir el objeto A en el servidor 1, éste se replica a los 3 servidores restantes: De esto podemos concluir que el rendimiento de las escrituras decaerá conforme se aumente el número de servidores Coherence en el cluster. Recuerde: El rendimiento de las lecturas es inversamente proporcional al número de servidores en el cluster. Sin embargo, el mantener replicados todos los objetos en todos los servidores favorece a la Disponibilidad. Recuerde: La disponibilidad es directamente proporcional al número de servidores en el cluster. Cuando un servidor falla, otro servidor que escribe un objeto replicará el objeto a todos los demás servidores excepto el que no está disponible. Cuando el servidor fallido vuelve a estar disponible, vuelve a ser parte de la replicación los objetos. En la siguiente imagen, el servidor 2 ha dejado de estar disponible. Por lo tanto, las escrituras del objeto A sólo se realizan a los servidores 3 y 4. Página 8

9 En esta topología también se tiene la limitante que la suma del tamaño de todos los objetos dentro de un servidor no debe sobrepasar el tamaño del servidor más pequeño, debido a que todos los datos deben ser mantenidos en todos los servidores. Por ejemplo, si se tienen los siguientes tamaños para nuestros 4 servidores: JVM1 = 3GB. JVM2 = 3GB. JVM3 = 1GB. JVM4 = 3GB. Cada servidor solo podrá soportar 1GB en objetos, aunque los servidores 1, 2 y 4 tengan capacidad de 3GB. Por lo tanto, si es más importante la disponibilidad de nuestros objetos, el límite de 1GB en nuestra configuración es aceptable. Sin embargo, si se requiere un límite mayor a 1GB, podríamos sacrificar un poco de Disponibilidad y extraer el servidor 3, dejando únicamente tres servidores (JVM1, JVM2 y JVM4). De esta topología podemos concluir lo siguiente: Las lecturas son locales, con latencia nula. Cada escritura requiere N-1 escrituras adicionales. Donde N es el número de servidores en nuestro cluster. La Disponibilidad es tan buena como el número de servidores en el cluster. El tamaño del cache se limita al tamaño del servidor más pequeño. La Disponibilidad es inversamente proporcional al rendimiento de las escrituras. Página 9