Resolución de problemas de red de Oracle

Este artículo tiene un procedimiento que ayudará a diagnosticar y solucionar los problemas más común del SQLNET y de configuración del archivo TNSNAMES.ora. Este artículo tiene dos partes.

1. Prueba de comunicación entre el cliente y el LISTENER.

Para hacer una prueba con la comunicación entre el cliente y el LISTENER, utilizase el comando “tnsping”. Un error común que tnsping pruebas de conectividad a la instancia. En realidad, sólo pone a prueba la conectividad con el LISTENER.

Esta prueba puede demostrar que 

a)  El archivo “tnsnames.ora” tiene que tener el nombre del servidor y la puerta correctos, y

b)  Que hay un LISTENER escuchando en el servidor y la puerta. 

Para ejecutar el comando tnsping, usar:

tnsping [conexión_tnsnames ] [numero_veces]

oracle@dbsrv$ tnspinng test 2

Used TNSNAMES adapter to resolve the alias

Attempting to contact (DESCRIPTION = (ADDRESS_LIST = (ADDRESS =

(PROTOCOL = TCP) (HOST = dbsrv)(PORT = 1521))) (CONNECT_DATA =

(SERVER = DEDICATED) (SERVICE_NAME = test)))

OK (40 msec)

OK (10 msec)

Si lá configuración estuver correcta, verá algo como esto:

Si no tiene un mensaje como esta de arriba, aquí están algunos errores comunes, y algunas sugerencias para corregirlos:

Mesages común de errors

TNS-03505: Failed to resolve name

El nombre de base de datos especificada no se ha encontrado en el archivo TNSNAMES.ORA, ONAMES o LDAP. Esto significa que el comando “tnsping” ni siquiera ha llegado tan lejos como tratando de hacer contacto con un servidor - que simplemente no puede encontrar ningún registro de la base de datos que está tratando el comando “tnsping”. Asegúrese de que usted ha escrito el nombre de base de datos correctamente, y que tiene una entrada en el tnsnames.ora.

Si usted tiene un archivo SQLNET.ORA, mirar el ajuste para el parámetro NAMES.DEFAULT_DOMAIN.  Si se establece, entonces todas las entradas en el TNSNAMES.ORA deben tener un sufijo de dominio coincidente.

TNS-12545: Connect failed because target host or object does not exist

El host especificado en los archivo TNSNAMES.ORA no puede tocarlo. Compruebe que ha escrito el nombre del  host correctamente. Si es así, intente hacer un ping al host  utilizando el comando ping  '[hostname]'. Si los host desconocido vuelve el ping, hable con su administrador de red. Puede ser que usted tiene un problema de DNS (que podría tratar de usar la dirección IP si lo tiene a la mano). Si se obtiene el 'host inaccesible ", una vez más hablar con la persona de la red, el problema podría deberse a un problema de enrutamiento o un firewall.

TNS-12541: TNS: no listener

El nombre de host es válido, pero el LISTENER no estaba localizable. Cosas a comprobar son que el archivo TNSNAMES.ora tiene la puerta correcta  (y el nombre del servidor) se especifica, y que el LISTENER  se está ejecutando en el servidor y utiliza en la puerta correcto.

Tnsping hangs for a long time

He visto que esto suceda en situaciones donde hay algo escuchando en el host / puerta  - pero no es una escucha de Oracle. Asegúrese de que haya especificado el puerto correcto, y que su interlocutor está corriendo. Si todo se ve bien, trate de ejecutar el comando "netstat     -ap | grep 1521 “ (debe indicar la puerta que está utilizando) para averiguar qué programa está escuchando en ese puerta.

2. Intentar una conexión con el ejemplo

Una vez que haya comprobado que el archivo TNSNAMES.ORA está contactando correctamente con el agente de escucha (LISTENER), el siguiente paso es intentar una conexión permanente a la instancia. Para hacer esto, debe utilizar lo utilitario “SQL*Plus”.

sqlplus [usuario]/[contraseña]@[conexión_tnsnames]

Si funciona correctamente inicie una sesión en la instancia. Si no es así, aquí están algunos errores comunes:

ORA-01017: invalid username/password; logon denied

Esto es en realidad un error de buena en estas circunstancias. A pesar de que no ha utilizado el nombre de usuario o la contraseña correcta, usted debe haber realizado con éxito el contacto con la instancia.

ORA-12505: TNS:listener does not currently know of SID given in connect

El parámetro SID está mal escrito en el archivo TNSNAMES.ORA, o el  LISTENER no está escuchando para ello. Compruebe el parámetro en el archivo TNSNAMES.ORA. Si se ve bien, debe mirar el estado del LISTENER, correr el comando “lsnrctl status” en su servidor, para ver qué bases de datos que el LISTENER está escuchando.

ORA-12514: TNS: listener could not resolve SERVICE_NAME given in connect

Esto es un error común y significa que, mientras que el LISTENER era localizable, la base de datos (el servicio) se especifica en el archivo TNSNAMES.ORA no era una de las cosas que estaba escuchando.

Comience por mirar el archivo TNSNAMES.ORA. En ella, se ponga el parámetro SERVICE_NAME = [nombre_instancia].

Si está ejecutando una base de datos de instancia única (eso es, no RAC), y está seguro de que usted no está utilizando los servicios, podría ser más fácil de cambiar parámetro SERVICE_NAME =[nombre_instancia] en el archivo TNSNAMES.ORA. El uso de nombres de servicio es la forma más moderna de hacer las cosas y que tiene beneficios, pero el parámetro SID sigue funcionando perfectamente (por ahora de todos modos y versiones).

Si prefiere seguir utilizando los nombres de servicio, primero debe verificar que no haya escrito correctamente el nombre del servicio en el archivo TNSNAMES.ORA. Si se ve bien de verificación, al lado de que el LISTENER está escuchando por el servicio. Haga esto mediante la ejecución del comando “lsnrctl services” en su servidor. Si no hay una entrada para el servicio, usted debe asegurarse de que el parámetro SERVICE_NAMES está configurado correctamente en la base de datos.

MSc. Rubens Oliveira

DBA Oracle Consultor

olivert.dba@consultant.com

Package - DBMS_REPAIR

O banco de dados Oracle fornece diferentes métodos para detecção e correção de corrupção de blocos de dados. Uma maneira de controlar a corrupção de dados do bloco é a utilização do pacote de DBMS_REPAIR.

Nesse artigo serão apresentadas as características da “package” DBMS_REPAIR, seus componentes e como utilizá-la para detectar e reparar um bloco corrompido no banco de dados.

Existem duas tabelas que devem ser criadas antes de usar a “package” DBMS_REPAIR, são as tabelas (REPAIR_TABLE e ORPHAN_KEY_TABLE).

Nota: Estas tabelas devem ser criadas no esquema SYS.

Abaixo a relação das “procedures” que compõem a “package” DBMS_REPAIR.

Procedure                          Descrição

ADMIN_TABLES                  Cria duas tabelas que serão utilizadas pela “procedure” CHECK_OBJECT

                                           e armazenam informações sobre corrupção bloco.

CHECK_OBJECT                 Detecta as corrupções nas tabelas ou índices.

DUMP_ORPHAN_KEYS       Gera o relacionamento dos índices que apontam para linhas na tabela

                                           que estão com os blocos corrompidos.

FIX_CORRUPT_BLOCKS      Corrige os blocos corrompidos.

REBUILD_FREELISTS          Reconstrói os “freelists” do objeto.

SEGMENT_FIX_STATUS      Fornece as capacidades de correção do bloco danificado.

SKIP_CORRUPT_BLOCKS   Esta “procedure” que ignora blocos marcados como corrompidos durante

                                           a verificação. Se esta opção não for utilizada, o banco de dados irá

                                           gerar o erro ORA-1578 quando forem encontrados blocos corrompidos.

Criação das tabelas REPAIR_TABLE e ORPHAN_KEY_TABLE, utilizando a “procedure” ADMIN_TABLES.

Criação da tabela REPAIR_TABLE

SQL>conn “/ as sysdba”

Conected.

SQL> BEGIN
2 (DBMS_REPAIR.ADMIN_TABLES
3 TABLE_NAME => 'REPAIR_TABLE',
4 TABLE_TYPE => dbms_repair.repair_table,
5 ACTION => dbms_repair.create_action,
6 TABLESPACE => 'USERS');
7 END;
8 /

PL/SQL procedure successfully completed.

Conteúdo da tabela REPAIR_TABLE:

DESC REPAIR_TABLE

 Name                         Null?    Type

 ---------------------------- -------- --------------

 OBJECT_ID                    NOT NULL NUMBER

 TABLESPACE_ID                NOT NULL NUMBER

 RELATIVE_FILE_ID             NOT NULL NUMBER

 BLOCK_ID                     NOT NULL NUMBER

 CORRUPT_TYPE                 NOT NULL NUMBER

 SCHEMA_NAME                  NOT NULL VARCHAR2(30)

 OBJECT_NAME                  NOT NULL VARCHAR2(30)

 BASEOBJECT_NAME                       VARCHAR2(30)

 PARTITION_NAME                        VARCHAR2(30)

 CORRUPT_DESCRIPTION                   VARCHAR2(2000)

 REPAIR_DESCRIPTION                    VARCHAR2(200)

 MARKED_CORRUPT               NOT NULL VARCHAR2(10)

 CHECK_TIMESTAMP              NOT NULL DATE

 FIX_TIMESTAMP                         DATE

 REFORMAT_TIMESTAMP                    DATE

Criação da tabela ORPHAN_KEY_TABLE

SQL> BEGIN
2 (DBMS_REPAIR.ADMIN_TABLES
3 TABLE_NAME => 'ORPHAN_KEY_TABLE',
4 TABLE_TYPE => dbms_repair.orphan_table,
5 ACTION => dbms_repair.create_action,
6 TABLESPACE => 'USERS');
7 END;
8 /

PL/SQL procedure successfully completed.

Conteúdo da tabela ORPHAN_KEY_TABLE:

DESC ORPHAN_KEY_TABLE

 Name                         Null?    Type

 ---------------------------- -------- -----------------

 SCHEMA_NAME                  NOT NULL VARCHAR2(30)

 INDEX_NAME                   NOT NULL VARCHAR2(30)

 IPART_NAME                            VARCHAR2(30)

 INDEX_ID                     NOT NULL NUMBER

 TABLE_NAME                   NOT NULL VARCHAR2(30)

 PART_NAME                             VARCHAR2(30)

 TABLE_ID                     NOT NULL NUMBER

 KEYROWID                     NOT NULL ROWID

 KEY                          NOT NULL ROWID

 DUMP_TIMESTAMP               NOT NULL DATE

Exemplos de uso:

A “procedure” CHECK_OBJECT verifica o objeto especificado e os resultados são gravados na tabela REPAIR_TABLE. Opcionalmente pode-se especificar um intervalo, nome da partição, ou nome subpartição para realizar a verificação de um objeto. A validação consiste em verificar todos os blocos no objeto.

Abaixo um exemplo de execução de verificação de corrupção, a tabela “DEPT” do esquema “SCOTT”, foi utilizada neste exemplo.

SET SERVEROUTPUT ON

DECLARE num_corrupt INT;

BEGIN

num_corrupt := 0;

DBMS_REPAIR.CHECK_OBJECT (

     SCHEMA_NAME=> 'SCOTT',

     OBJECT_NAME=> 'DEPT',

     REPAIR_TABLE_NAME=> 'REPAIR_TABLE',

     CORRUPT_COUNT=>  num_corrupt);

DBMS_OUTPUT.PUT_LINE('number corrupt: ' || TO_CHAR (num_corrupt));

END;

/

Consultando os resultados da verificação na tabela REPAIR_TABLE.

SELECT OBJECT_NAME,

       BLOCK_ID,

       CORRUPT_TYPE,

       MARKED_CORRUPT,

       CORRUPT_DESCRIPTION,

       REPAIR_DESCRIPTION

  FROM REPAIR_TABLE;

OBJECT_NAME BLOCK_ID CORRUPT_TYPE MARKED_COR CORRUPT_DESCRIPTION REPAIR_DESCRIPTION

----------- -------- ------------ ---------- ------------------- ------------------

DEPT               3            1 FALSE      kdbchk: row locked  mark block

                                             by non-existent     software corrupt

                                             transaction

                                             table=0  slot=0

                                             lockid=32

                                             ktbbhitc=1

Para a correção dos blocos identificados como corrompidos, deve-se utilizar a procedure FIX_CORRUPT_BLOCKS.

SET SERVEROUTPUT ON

DECLARE num_fix INT;

BEGIN

num_fix := 0;

DBMS_REPAIR.FIX_CORRUPT_BLOCKS (

     SCHEMA_NAME=> 'SCOTT',

     OBJECT_NAME=> 'DEPT',

     OBJECT_TYPE=> dbms_repair.table_object,

     REPAIR_TABLE_NAME => 'REPAIR_TABLE',

     FIX_COUNT=> num_fix);

DBMS_OUTPUT.PUT_LINE('num fix: ' || TO_CHAR(num_fix));

END;

/

Para confirmar a correção, deve-se verificar a tabela REPAIR_TABLE, usar:

SELECT OBJECT_NAME,

       BLOCK_ID,

       MARKED_CORRUPT

 FROM REPAIR_TABLE;

OBJECT_NAME BLOCK_ID MARKED_COR

----------- -------- ----------

DEPT              3  TRUE

Existem algumas limitações e restrições para o pacote DBMS_REPAIR.

-    As tabelas com tipos de dados LOB, tabelas aninhadas e varrays são suportados, mas as colunas com esses tipos de dados são ignorados.

- Tabelas clusterizadas são suportadas para as procedures SKIP_CORRUPT_BLOCKS e REBUILD_FREELISTS, mas não são suportados para a procedure CHECK_OBJECT.

-      Objetos index-organized tables e índices LOB não são suportados.

-   A procedure DUMP_ORPHAN_KEYS não opera com índices bitmaps ou índices baseados em função (function-based).

-   Os processos da procedure DUMP_ORPHAN_KEYS não aceitam chaves maiores que 3.950 bytes de comprimento.

MSc. Rubens Oliveira

DBA Oracle Consultor

olivert.dba@consultant.com