{"id":109,"date":"2012-08-18T12:17:25","date_gmt":"2012-08-18T10:17:25","guid":{"rendered":"http:\/\/clemente.pamplona.name\/dba\/?p=109"},"modified":"2012-10-20T20:05:08","modified_gmt":"2012-10-20T18:05:08","slug":"gestor-de-recursos-a-la-caza-del-bloqueo-i","status":"publish","type":"post","link":"http:\/\/clemente.pamplona.name\/dba\/gestor-de-recursos-a-la-caza-del-bloqueo-i\/","title":{"rendered":"Gestor de recursos. A la caza del bloqueo I"},"content":{"rendered":"

Hoy\u00a0 vamos a abordar los problemas de bloqueos desde otro punto de vista.<\/p>\n

A pesar de que los bloqueos sonun problema propio de\u00a0 la aplicaci\u00f3n y debe de ser desde esta donde se solucione el evitar sesiones bloqueantes, un c\u00f3digo de\u00a0 aplicacion defectuoso\u00a0 puede llegar a tirar abajo nuestra instancia , con lo que deberemos de acabar con este tipo de sesiones antes de que afecten a la disponibilidad del sistema.<\/p>\n

Oracle nos da la opcion de limitar el tiempo en el que un usuario est\u00e1 IDLE a la vez que\u00a0 bloquea otra sesion con el par\u00e1metro NEW_MAX_IDLE_BLOCKER.<\/p>\n

Esta es la primera de un grupo de entradas en las que utilizaremos el gestor de recursos de Oracle para llevar acabo workarrounds que nos solucionen este problema.<\/p>\n

Lo primero que haremos es crear un plan al que llamaremos \u00abNO_LOCKS\u00bb, para ello lo mas sencilllo es copiar el DEFAULT_PLAN desde el EM, si por el contrario queremos hacerlo desde linea de sqlplus tenemos que:<\/p>\n

    \n
  1. Crear una pending area (si lo hacemos desde sqlplus)<\/li>\n
  2. Crear el plan de recursos<\/li>\n
  3. Validar el pending area<\/li>\n
  4. Enviar\/presentar\u00a0 (submit) esta pending area<\/li>\n<\/ol>\n
    BEGIN\r\ndbms_resource_manager.clear_pending_area();\r\ndbms_resource_manager.create_pending_area();\r\ndbms_resource_manager.create_plan( plan => 'NO_LOCKS',\r\n\u00a0comment => 'Plan para eliminar bloqueos desde el gestor de recursos, copiado de DEFAULT_PLAN'\r\n);\r\ndbms_resource_manager.create_plan_directive(\r\n\u00a0\u00a0\u00a0 plan => 'NO_LOCKS',\r\n\u00a0\u00a0\u00a0 group_or_subplan => 'SYS_GROUP',\u00a0 \u00a0\r\n\u00a0\u00a0\u00a0 comment => 'Asignamos 75% de cpu al grupo SYS ',\r\n\u00a0\u00a0\u00a0 mgmt_p1 => 75\r\n);\r\ndbms_resource_manager.create_plan_directive(\r\n\u00a0\u00a0\u00a0 plan => 'NO_LOCKS',\r\n\u00a0\u00a0\u00a0 group_or_subplan => 'DEFAULT-CONSUMER_GROUP',\u00a0 \u00a0\r\n\u00a0\u00a0\u00a0 comment => 'Asignaremos el 90% de CPU al grupo de consumidores por defecto ',\r\n\u00a0\u00a0\u00a0 mgmt_p2 => 90\r\n);\r\ndbms_resource_manager.create_plan_directive(\r\n\u00a0\u00a0\u00a0 plan => 'NO_LOCKS',\r\n\u00a0\u00a0\u00a0 group_or_subplan => 'OTHER_GROUPS',\u00a0 \u00a0\r\n\u00a0\u00a0\u00a0 comment => 'Este grupo debe de aparecer ',\r\n\u00a0\u00a0\u00a0 mgmt_p2 => 5\r\n);\r\ndbms_resource_manager.create_plan_directive(\r\n\u00a0\u00a0\u00a0 plan => 'NO_LOCKS',\r\n\u00a0\u00a0\u00a0 group_or_subplan => 'ORA$DIAGNOSTICS',\u00a0 \u00a0\r\n\u00a0\u00a0\u00a0 comment => 'Asignamos 5% de cpu al grupo ORA$DIAGNOSTICS en el segundo nivel ',\r\n\u00a0\u00a0\u00a0 mgmt_p2 => 5\r\n\u00a0);\r\n\u00a0DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA();\r\nDBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();\r\nEND;<\/pre>\n
    Con esto tenemos\u00a0 un nuevo plan llamado \u00abNO_LOCKS\u00bb que es similar al DEFAULT_PLAN.<\/p>\n
    Lo que vamos ha hacer ahora es modificar el subplan que se aplica a todos los usuarios (DEEFAULT_CONSUMER_GROUP) para que no los deje bloquear recursos mas de 5 segundos.<\/p>\n
    BEGIN\r\ndbms_resource_manager.clear_pending_area();\r\ndbms_resource_manager.create_pending_area();\r\ndbms_resource_manager.update_plan_directive(\r\n\u00a0\u00a0\u00a0 plan => 'NO_LOCKS',\r\n\u00a0\u00a0\u00a0 group_or_subplan => 'DEFAULT_CONSUMER_GROUP',\u00a0 \u00a0\r\n\u00a0\u00a0\u00a0 new_comment => 'Subplan para bloqueadores, similar a DEFAULT_CONSUMER_GROUP pero\u00a0 limitado',\r\n\u00a0\u00a0\u00a0 new_max_idle_blocker_time=>5\r\n\u00a0\u00a0 \u00a0);\r\nDBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA;\r\nDBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA;\r\nEND;<\/pre>\n
    Si miramos los cambios desde el EM podremos ver como\u00a0\u00a0 esta el par\u00e1metro<\/p>\n
    \"Plan<\/a><\/p>\n
    Ahora solamente nos quedar\u00e1 activar el nuevo plan y probarlo<\/p>\n
    Esto lo comprobamos con<\/p>\n
    SQL>ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = 'NO_LOCKS';\r\n\r\nSQL> SELECT VALUE FROM V$PARAMETER\u00a0 WHERE name = 'resource_manager_plan';\r\n\r\nVALUE\r\n--------------------------------------------------------------------\r\nNO_LOCKS<\/pre>\n
    Ahora vamos ha hacer la prueba de que funciona<\/p>\n
    Veamos en que grupo de consumidores est\u00e1 el usuario HR<\/p>\n
    SQL> select initial_rsrc_consumer_group from dba_users where username='HR';\r\n\r\nINITIAL_RSRC_CONSUMER_GROUP\r\n------------------------------\r\nDEFAULT_CONSUMER_GROUP<\/pre>\n
     <\/p>\n
    Nos conectamos con el usuario HR y bloquearemos la tabla REGIONS<\/p>\n
    SQL> ALTER SESSION SET NLS_DATE_FORMAT = 'HH24:MI:SS';\r\nSession altered.\r\nSQL>\u00a0 select sysdate from dual;\r\nSYSDATE\r\n--------\r\n12:08:13\r\nSQL> select * from\u00a0 regions where\u00a0 REGION_ID=1 for update;\r\n\u00a0REGION_ID REGION_NAME\r\n---------- -------------------------\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 1 Europe\r\nSQL>\u00a0 select sysdate from dual;\r\nSYSDATE\r\n--------\r\n12:30:18<\/pre>\n
    En el segundo select sysdate vemos como,\u00a0 pesar de que la tabla esta bloqueada, y que han pasado 15 segundos el gestor de recursos no nos ha hechado.\u00bfhabremos hecho algo mal?<\/p>\n
    La respuesta es que no hemos hecho nada mal, lo que est\u00e1 ocurriendo es que la consulta que hemos ejecutado esta bloqueando algo, pero no esta bloqueando\u00a0 a nadie<\/em><\/strong> .<\/p>\n
    Que ocurre si intentamos ejecutar una consulta en otra sesion que\u00a0 se vea bloqueada por esta?<\/p>\n
    \"\"<\/a><\/p>\n
    En el momento en l que el gestor de recursos detecta que nuestra primera sesion esta bloqueando a otra empieza a contar los segundos que nuestra primera consulta esta \u00abidle\u00bb.Al llegar a los 5 segundos matar\u00e1 nuestra consulta bloqueante y liberar\u00e1 sus recursos.<\/p>\n
    Si tras esos 5 segundos\u00a0 volvemos a recargar la ventana del EM\u00a0 veremos que no hay bloqueos, y\u00a0 si nos vamos a la ventana donde hemos ejecutado nuestra consulta bloquante nos encontraremos con el error:<\/p>\n
    ORA-02396: ha excedido el tiempo m\u00e1ximo de inactividad, vuelva a conectarse<\/pre>\n
    Con lo que , de manera algo brusca y desde la base de datos hemos conseguido acabar con todos los bloqueos de usuario que est\u00e9n inactivas mas de 5 segundos.<\/p>\n
     <\/p>\n
    \n
    LLegados a este punto tenemos a TODOS los usuarios de la base de datos sin poder llevar a cabo un bloqueo de mas de 5 segundos en cualquier hora del d\u00eda.<\/p>\n
    Esto nos va a generar muchos problemas a la hora de los procesos batch e incluso en alguna transaccion pesada, con lo que lo mejor que podemos hacer el volverlo atr\u00e1s .<\/p>\n
    El \u00fanico valor de esta entrada es como ejercicio didactico, asi que, mas nos valdr\u00eda volver a activar en la base de datos el DEFAULT_PLAN o el INTERNAL_PLAN<\/span><\/p>\n
    En las siguientes entradas afinaremos este plan NO_LOCKS para limitarlo por esquemas y por franja horaria, haciendo de la limitaci\u00f3n NEW_MAX_IDLE_BLOCKER_TIME\u00a0 algo util.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"
    Hoy\u00a0 vamos a abordar los problemas de bloqueos desde otro punto de vista. A pesar de que los bloqueos sonun problema propio de\u00a0 la aplicaci\u00f3n y debe de ser desde esta donde se solucione el evitar sesiones bloqueantes, un c\u00f3digo … Sigue leyendo →<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[16,21,15,14],"class_list":["post-109","post","type-post","status-publish","format-standard","hentry","category-tunning","tag-bloqueos","tag-locks","tag-new_max_idle_blocker","tag-resource-manager"],"_links":{"self":[{"href":"http:\/\/clemente.pamplona.name\/dba\/wp-json\/wp\/v2\/posts\/109","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/clemente.pamplona.name\/dba\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/clemente.pamplona.name\/dba\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/clemente.pamplona.name\/dba\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/clemente.pamplona.name\/dba\/wp-json\/wp\/v2\/comments?post=109"}],"version-history":[{"count":31,"href":"http:\/\/clemente.pamplona.name\/dba\/wp-json\/wp\/v2\/posts\/109\/revisions"}],"predecessor-version":[{"id":132,"href":"http:\/\/clemente.pamplona.name\/dba\/wp-json\/wp\/v2\/posts\/109\/revisions\/132"}],"wp:attachment":[{"href":"http:\/\/clemente.pamplona.name\/dba\/wp-json\/wp\/v2\/media?parent=109"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/clemente.pamplona.name\/dba\/wp-json\/wp\/v2\/categories?post=109"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/clemente.pamplona.name\/dba\/wp-json\/wp\/v2\/tags?post=109"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}