Heterogeneous Services – Conectividade entre Oracle e MS SQL Server

Olá pessoal!

Recentemente realizei uma atividade e vou compartilhar com vocês. Surgiu uma demanda para mim para estabelecer conexão entre uma base de dados Microsoft SQL Server 2000 e um Oracle 10G. Para atender à demanda foi utilizada a tecnologia “Oracle Database Gateway for MS SQL Server”.

Existem algumas formas de se configurar o link entre bases heterogêneas (bancos de dados distintos), e o que utilizei foi via ODBC (Open Database Connectivity), conforme figura 1.

Figura 1 Oracle Gateway via ODBC. (Fonte: DATADIRECT)

Vou descrever o passo a passo que realizei para configurar.

1 – Configuração de um Data Source ODBC (fonte de dados)

Primeiramente foi necessário criar um OBDC para o banco SQL Server. Esse passo envolveu outra instituição, que teve que dar permissão ao IP do servidor Oracle para acessar o servidor MS SQL Server. Além da liberação do IP, a empresa me passou um usuário e senha do banco remoto para acesso e configuração.

2 – Configuração do INIT.ORA

Após o estabelecimento de conectividade entre os bancos via ODBC, foi realizada uma configuração no servidor Oracle.

No diretório “<ORACLE_HOME>\hs\admin\ “ (vale lembrar que esse banco Oracle estava instalado em um servidor Windows Server 2003), provavelmente existe um arquivo chamado inithsodbc.ora, que poderia ter sido utilizado, mas como precisava acessar duas bases SQL Server distintas, criei outros init.ora e não alterei o inithsodbc.ora.

Criação dos arquivos .ORA:

init<SID1>.ora

# This is a sample agent init file that contains the HS parameters that are

# needed for an ODBC Agent.

# HS init parameters

HS_FDS_CONNECT_INFO = DS_ODBC_SQLSERVER1

HS_FDS_TRACE_LEVEL = off

# Environment variables required for the non-Oracle system

#set <envvar>=<value>

init<SID2>.ora

# This is a sample agent init file that contains the HS parameters that are

# needed for an ODBC Agent.

# HS init parameters

HS_FDS_CONNECT_INFO = DS_ODBC_SQLSERVER2

HS_FDS_TRACE_LEVEL = off

# Environment variables required for the non-Oracle system

#set <envvar>=<value>

Existem outros parâmetros que podem ser configurados nesse arquivo, a alteração de apenas esses atende a minha necessidade. O parâmetro HS_FDS_CONNECT_INFO está setado para o data source ODBC que criamos anteriormente no passo 1.

É importante saber que o nome do arquivo deve ser iniciado com “init”, e que o SID1 e SID2  serão “interpretados” pela configuração do TNSNAMES.ORA e LISTENER.ORA., então merecem um cuidado especial.

3 – Criação/alteração de LISTENER.ORA

No diretório “<ORACLE_HOME >\network\admin\” foi necessária uma alteração no arquivo LISTENER.ORA. No meu caso, criei um listener dedicado para esse serviço, para não impactar nos demais.

As alterações foram as listadas abaixo:

(...)

SID_LIST_LISTENERHS =

  (SID_LIST =

    (SID_DESC =

      (SID_NAME = SID1)

      (ORACLE_HOME = <ORACLE_HOME> )

      (PROGRAM = hsodbc)

    )

    (SID_DESC =

      (SID_NAME = SID2)

      (ORACLE_HOME = <ORACLE_HOME> )

      (PROGRAM = hsodbc)

    )

  )

(...)

LISTENERHS =

  (DESCRIPTION_LIST =

    (DESCRIPTION =

      (ADDRESS = (PROTOCOL = TCP)(HOST = <xxxxxx IP_HOST_ORACLE xxxxx>)(PORT = 1522))

    )

  )

(...)

Foi criado um listener chamado “LISTENERHS” em outra porta: 1522. Atentar para a lista de serviços que o listener vai atender (SID_LIST_LISTENERHS), lá consta o SID1 e SID2, ambos referenciando o programa HSODBC.

Para startar o lisntener novo, utilize o comando:

lsnrctl start LISTENERHS

Se houver necessidade, seguem os comandos para verificar o status e parar o listener.

lsnrctl status LISTENERHS

lsnrctl stop LISTENERHS

4 – Alteração no TNSNAMES.ORA

No diretório “<ORACLE_HOME >\network\admin\”, deve ser alterado o arquivo TNSNAMES.ORA, para acresentar os novos acessos aos bancos SQL Server.

HS_ODBC _SID1 =

   (DESCRIPTION =

     (ADDRESS_LIST =

       (ADDRESS = (PROTOCOL = TCP)(HOST = <xxxxxx IP_HOST_ORACLE xxxxx>)(PORT = 1522))

     )

    (CONNECT_DATA =

       (SID = SID1)

     )

     (HS=OK)

   )

HS_ODBC_SID2 =

   (DESCRIPTION =

     (ADDRESS_LIST =

       (ADDRESS = (PROTOCOL = TCP)(HOST = <xxxxxx IP_HOST_ORACLE xxxxx>)(PORT = 1522))

     )

    (CONNECT_DATA =

       (SID = SID2)

     )

     (HS=OK)

   )

5 – Criação do DBLINK no Oracle Database

Foram criados dois dblinks privados em um schema do Oracle que irá gerenciar (receber e tratar) as informações do MS SQL Server.

CREATE DATABASE LINK "BDLINK_SID1"

 CONNECT TO "<user_bd_sqlserver_1>"

 IDENTIFIED BY "<pass_bd_sqlserver_1>"

 USING ’ HS_ODBC_SID2';

CREATE DATABASE LINK " BDLINK_SID2"

 CONNECT TO "<user_bd_sqlserver_2>"

 IDENTIFIED BY "<pass_bd_sqlserver_2>"

 USING ‘HS_ODBC_SID2’;

Lembrando que para os dblinks no Oracle, foram criados com os mesmos usuário/senha que foi configurado na fonte de dados ODBC, e o tns usado (USING) o que foi configurado no arquivo TNSNAMES.ORA.

Pronto!

Agora é só testar:

select * from tabela_sqlserverSID1@DBLINK_SID1;

e

select * from tabela_sqlserverSID2@DBLINK_SID2;

Bom, pessoal...

É isso!

Espero ter ajudado no entendimento da configuração usada por mim para resolver uma demanda de “comunicação” entre bancos heterogêneos: Oracle 10g e MS SQL Server 2000.

Até a próxima!

Referências:

ORACLE - Configuring Oracle Database Gateway for ODBC. Disponível em: http://docs.oracle.com/cd/B28359_01/gateways.111/b31043/configodbc.htm. Acessado em: 21/08/2013.

ORACLE - Oracle Database Gateway. Installation and Configuration Guide. 11g Release 1 (11.1) for Microsoft Windows. Disponível em: http://docs.oracle.com/cd/B28359_01/gateways.111/b31043.pdf. Acessado em: 20/08/2013.

BURLESON CONSULTING - Creating Multiple Listeners Tips. Disponível em http://www.dba-oracle.com/t_configure_multiple_listeners.htm. Acessado em:21/08/2013.

DATADIRECT - Connect for ODBC with Oracle database. Gateway for ODBC (DG4ODBC). Disponível em: http://www.datadirect.com/resources/odbc/oracle-database-gateway/index.html. Acessado: 21/08/2013.

Leia mais...

Reorganizando os dados em uma tabela no Oracle Database

Olá pessoal!

No artigo de hoje falarei sobre um assunto que entendo como uma extensão do artigo Recriação de índices - Rebuild Index que escrevi tempos atrás.

Bom, o assunto é como efetuar uma reorganização dos dados de uma tabela em um banco de dados Oracle. Uma tabela pode se apresentar fragmentada, ou seja, com espaços não utilizados entre os espaços usados pela tabela.

Li um artigo bastante interessante, onde o autor, Mohammad, afirma que existem quatro formas de se reorganizar tabelas fragmentadas:
1) alter table ... move + rebuild indexes
2) export / truncate / import
3) create table as select
4) dbms_redefinition

No post de hoje vamos falar sobre a primeira alternativa.

Para isso vamos criar uma tabela de teste, inserir dados e manipula-los com o objetivo de criarmos lacunas de espaços na tabela. depois vamos realizar uma reorganização dos dados do objeto visando o ganho de espaço, um melhor plano de execução das consultas contra a tabela, além de uma organização melhor dos dados.

Primeiro vamos criar a tabela conforme script abaixo:

CREATE TABLE tbl_reorg
(
   codigo      NUMBER (8) NOT NULL,
   descricao   VARCHAR2 (100) NOT NULL
);

Agora vamos popular a tabela:

BEGIN
   FOR i IN REVERSE 1 .. 1000000
   LOOP
      INSERT INTO tbl_reorg (codigo, descricao) VALUES (i, 'registro da posição: ' || i);
   END LOOP;
   COMMIT;
END;


Verificando o tamanho da tabela após a inserção dos dados com o script abaixo. A projeção dos dados pode ser vista na figura 1.
SELECT SEGMENT_NAME, ROUND (SUM (bytes) / 1024 / 1024, 2) size_mb
    FROM dba_segments
   WHERE segment_name = 'TBL_REORG'
GROUP BY SEGMENT_NAME;

Figura 1: Tamanho da tabela TBL_REORG. (Fonte: autoria própria)

Vamos coletar as estatísticas da tabela pois como pode ser observado pela consulta abaixo, não existem dados estatísticos sobre o objeto.

SELECT owner,
       table_name,
       blocks,
       empty_blocks,
       num_rows,
       TO_CHAR (last_analyzed, 'DD-MM-RRRR HH24:MI:SS') AS "ANALYZE"
  FROM dba_tables
 WHERE table_name = 'TBL_REORG';

O script abaixo coleta as estatísticas da tabela.
exec dbms_stats.gather_table_stats (ownname=>'HOUSEWORK',tabname=>'TBL_REORG',estimate_percent=>30,method_opt=>'FOR ALL COLUMNS SIZE AUTO',degree=>6);

Vale lembrar que existem outras formas de coleta de estatísticas. Falei um pouco sobre isso no artigo Estatísticas no banco de dados Oracle.

Agora vamos apagar alguns dados para gerar os espaços em branco na tabela.
delete from tbl_reorg where codigo between 10000 and 20000;
delete from tbl_reorg where codigo between 50000 and 200000;
delete from tbl_reorg where codigo between 400000 and 700000;
delete from tbl_reorg where codigo > 900000;
commit;

Vamos verificar o tamanho da tabela após algumas exclusões. O resultado pode ser visto na figura 2.
SELECT SEGMENT_NAME, ROUND (SUM (bytes) / 1024 / 1024, 2) size_mb
    FROM dba_segments
   WHERE segment_name = 'TBL_REORG'
GROUP BY SEGMENT_NAME;

Figura 2: Tamanho da tabela TBL_REORG após exclusão de alguns registros. (Fonte: autoria própria)

Bom...

Para resolvermos esse problema de fragmentação, basta reconstruir o mapa binário da tabela, para isso vamos usar o comando MOVE.

Não vamos mover a tabela para outra tablespace, vamos move-la na própria tablespace com o script abaixo:
ALTER TABLE tbl_reorg MOVE;

Verificando novamente o tamanho da tabela,  se tem o resultado exibido na figura 3.

Figura 3: Tamanho da tabela TBL_REORG após exclusão de dados e MOVE. (Fonte: autoria própria)

Após a execução do MOVE, a tabela foi reorganizada e o tamanho da tabela caiu de 42MB para 19MB, fazendo apenas uma reconstrução dos extents da tabela.

É interessante também realizar uma nova coleta das estatísticas da tabela após o MOVE, para que seja "traçado" um plano de execução mais otimizado de consultas contra o objeto.

exec dbms_stats.gather_table_stats (ownname=>'HOUSEWORK',tabname=>'TBL_REORG',estimate_percent=>30,method_opt=>'FOR ALL COLUMNS SIZE AUTO',degree=>6);

Pois é pessoal...

Esse foi um dos métodos para resolver o problema da fragmentação de uma tabela no banco de dados, vale lembrar que essa situação pode causar perda de performance em um sistema de banco de dados então vale a pena ter um cuidado especial sobre o assunto.

Bom, é isso aí!

Até a próxima!

Referências:

Reis, Bruno - How to do reorg in a table in Oracle Database / Como fazer reorg em uma tabela no Banco de Dados Oracle. Disponível em: http://brunors.com/how-to-do-reorg-in-a-table-in-oracle-database-como-fazer-reorg-em-uma-tabela-no-banco-de-dados-oracle/. Acessado: 29/07/2013.

Almeida, Rodrigo - Entendendo a Marca d’água e fragmentação de tabelas. Disponível em : http://profissionaloracle.com.br/blogs/rodrigoalmeida/2008/10/07/entendendo-a-marca-dagua-e-fragmentacao-de-tabelas/. Acessado: 29/07/2013.

Taj, Mohammad - Table Fragmentation. Disponível em: http://dbataj.blogspot.com.br/2007/07/table-fragmentation.html. Acessado: 29/07/2013.

Leia mais...

Tirinhas de humor sobre Banco de Dados.

Olá pessoal,

Enquanto termino de escrever um material para postar, seguem algumas tirinhas do site Vida de Programador.

Essas são sobre banco de dados, mas tem várias outras bastante interessante. Acessem lá e confiram!

Segurança da informação é tudo! (Fonte: Vida de Programador)

SID do BD? Quem é esse? (Fonte: Vida de Programador)

Otimizando o banco de dados. (Fonte: Vida de Programador)

Fonte:

Vida de programador /*Linhas de código da vida de um programador*/ - Acesso à base de dados. Disponível em: http://vidadeprogramador.com.br/2013/05/02/acesso-a-base-de-dados/. Acessado em: 21/07/2013.

Vida de programador /*Linhas de código da vida de um programador*/ - SID do Banco. Disponível em: http://vidadeprogramador.com.br/2012/07/01/sid-do-banco/. Acessado em: 21/07/2013.

Vida de programador /*Linhas de código da vida de um programador*/ - Otimização do BD. Disponível em: http://vidadeprogramador.com.br/2012/08/03/otimizacao-do-bd/. Acessado em: 21/07/2013.

Leia mais...

Geração de relatório Excel no SQL*Plus

Olá pessoal.

Hoje vou falar sobre algo que pode ser bem interessante para administradores de banco de dados.

Muitas vezes nós DBA's recebemos solicitações para geração de relatórios em ambiente de produção (pelo menos onde trabalho isso é muito comum).

A questão é que sempre utilizamos o SQL*Plus para solicitações dos analistas e, na maioria das vezes, é desejado que a projeção da informação seja salva em planilha.

Para resolver essa situação, podemos utilizar um tipo de saída do SQL*Plus que torna o layout do arquivo gerado mais "apresentável". Na verdade, a projeção será gerada dentro de um código HTML, mas podemos gerá-lo como um XLS por se tratar de uma estrutura em tabelas através do markup html.

O comando, em uma forma bem básica, é o seguinte:

set feed off markup html on
spool c:\temp\relatorio.xls
SELECT * FROM hr.employees;
spool off
set markup html off

O arquivo gerado pode ser aberto no MS-Excel pois o spool foi para um ".xls".

Para se ter uma melhora na apresentação do arquivo, pode-se editá-lo retirando a consulta executada (que deve aparecer no início do arquivo) e o comando "spool off" (que deve aparecer no final do arquivo).

Bom pessoal, fica a dica!

Até a próxima.

Referências:

Oracle – Generating HTML Reports from SQL*Plus. Disponível em: http://docs.oracle.com/cd/B13789_01/server.101/b12170/ch8.htm. Acessado: 102/07/2013.

Leia mais...

Vídeo: Desenvolvedores vs. DBA

Meus caros,

Assisti a esse vídeo e achei muito engraçado e interessante.

Legal é que mesmo sendo uma edição, ficou muito bem casado com o texto, e com a realidade do dia-a-dia de um DBA, inclusive fazendo críticas à equipe de desenvolvimento (frequentes na vivência do profissional de banco).

Assistam e digam se não é bem real!

Leia mais...

Arquitetura Oracle Database 11g - Estrutura de memória

Pessoal,

Estou de férias do trabalho e estou aproveitando para resolver algumas coisas e viajar para descansar, por isso estou com pouco tempo para desenvolver algo para o Blog.

Bom...


Estava pretendendo escrever sobre a estrutura de memória do banco de dados Oracle. Foi então que em busca de material para referência, encontrei um vídeo que explica de forma muito interessante o assunto. Não gostei muito do áudio, mas achei o conteúdo legal.

Vejam e tirem suas próprias conclusões.




Valeu pessoal!!

Até a próxima...

Leia mais...

Bilionários da T.I.

Muito bom dia a todos!

Saiu na semana passada (se não estou enganado, no dia 24/05/2013) uma lista atualizada das pessoas mais ricas do mundo. Essa pesquisa foi elaborada pela Bloomberg. Como os assuntos abordados nesse blog são sobre T.I. (Tecnologia da Informação), abstrai dessa lista apenas os bilionários dessa área.

É importante salientar que Larry Ellison (da Oracle) está no TOP 10 da lista de bilionários. Muito justo! (hehehe)

Bom...

Segue a lista dos bilionários da T.I.:

 

Bilionários da T.I. (Fonte: Bloomberg) 

1) Bill Gates (U$ 72.4 Bilhões) - cofundador da Microsoft #1

2) Larry Ellison (U$ 41 Bilhões) - fundador da Oracle #8

3) Larry Page (U$ 25.5 Bilhões) - cofundador e CEO do Google #20

4) Sergey Brin (U$ 25.2 Bilhões) - cofundador do Google #23

5) Jeff Bezos (U$ 24.5 Bilhões) - fundador e presidente da Amazon #24

6) Steve Ballmer (U$ 16.7 Bilhões) - CEO da Microsoft #44

7) Paul Allen (U$ 15.3 Bilhões) - cofundador da Microsoft #54

8) Michael Dell (U$ 14.8 Bilhões) fundador da Dell #59

9) Jim Goodnight (U$ 12.3 Bilhões) - CEO da SAS Institute #80

10) Mark Zuckerberg (U$ 12 Bilhões) - cofundador e CEO do Facebook #87

11) Lee Kun Hee (U$ 11 Bilhões) - presidente da Samsung Electronics #94

12) Azim Premji (U$ 11 Bilhões) - presidente da Wipro #96

Por hoje é só, pessoal!
É melhor seguir trabalhando que um dia chegaremos lá!! (hehehe)
Até a próxima.

Referências:

Bloomberg. Disponível em: http://www.bloomberg.com/billionaires/2013-05-24/aaa. Acessado: 26/05/2013.

Leia mais...

Um pouco de conceitos da Oracle sobre pfile e spfile

Olá pessoal!

O processo para inicialização de uma instância no banco Oracle é feito a partir da leitura do seu arquivo de inicialização, e os tipos desse arquivo é o assunto que vou abordar hoje.

Existem dois tipos de arquivos de inicialização para o Oracle: o PFILE (que é um arquivo texto conhecido também por init.ora) e o SPFILE que é um arquivo binário de parâmetros do servidor (conhecido como spfile.ora).

No post de hoje vou falar sobre alguns conceitos relacionados a esses arquivos, porém não vou entrar no detalhe sobre parâmetros, ou pelo menos não é minha ideia, pois o intuito desse artigo é falar sobre o que são esses arquivos, como e quando são usados.

O PFILE

Esse arquivo armazena os parâmetros de inicialização para "levantar" uma instância Oracle. Através desse arquivo, o DBA pode controlar a memória em seu banco de dados Oracle, atribuindo valores para os parâmetros de memória no arquivo INIT.ORA para o seu sistema. A localização deste arquivo varia, dependendo do sistema operacional em questão. Por exemplo:

 - No UNIX ou Linux, o init.ora poderá ser encontrado em: $ORACLE_HOME/dbs

 - No Windows, o diretório será: ORACLE_HOME/database

É possível que em alguns sistemas, exista mais de um arquivo init.ora, o que possibilita ter diferentes bases de dados com seus próprios parâmetros.

Por exemplo, initDESENV.ora pode controlar o banco de dados de desenvolvimento, initHML.ora o banco de dados de homologação, e initPROD.ora banco de dados de produção; ou ainda diferentes ambientes, como: initRH.ora, initFIN.ora, initADM.ora...

Como o PFILE é um arquivo de texto puro, ele pode ser editado no VI do UNIX ou no Notepad do Windows.

Para saber quais parâmetros podem ser alterados no PFILE, recomendo a leitura dos artigos: “INIT.ORA Parameters A-L” e “INIT.ORA Parameters M-Z” da TOAD WORLD.

O SPFILE (server parameter file)

O arquivo SPFILE é uma versão binária do PFILE. O SPFILE não pode ser alterado diretamente, porém através do comando ALTER SYSTEM é possível mudar alguns de seus parâmetros dinamicamente, ou seja, sem a necessidade de reiniciar o banco de dados. Para saber quais parâmetros podem ser alterados dinamicamente, pode-se executar uma consulta em uma view do schema SYS, conforme script abaixo:

SELECT * FROM V$PARAMETER;

O SPFILE possui algumas vantagens em relação ao PFILE, pois a Oracle criou procedimentos de otimização automática do banco baseadas no uso do SPFILE.

É possível verificar se existe o SPFILE com o seguinte comando:

SHOW PARAMETER SPFILE;

Para criar o SPFILE a partir do PFILE, pode-se utilizar os seguintes comandos:

CREATE SPFILE FROM PFILE;

ou

CREATE SPFILE FROM PFILE=’/U01/APP/ORACLE/PRODUCT/11.2.0/DBHOME_1/DBS/initSID.ORA’

ou

CREATE SPFILE=’/U01/APP/ORACLE/PRODUCT/11.2.0/DBHOME_1/DBS/spfileSID.ORA’ FROM PFILE=’/U01/APP/ORACLE/PRODUCT/11.2.0/DBHOME_1/DBS/initSID.ORA’

Após de qualquer um desses comandos, para efetivar a criação, é necessário reiniciar o banco:

SHUTDOWN IMMEDIATE;

STARTUP

Pode existir a necessidade, devido a alguma mudança dinâmica dos parâmetros do banco, que o DBA necessite gerar um novo init.ora (PFILE), a partir do SPFILE. O comando para realizar essa criação é:

CREATE PFILE FROM SPFILE;

Executando esse script, será criado um PFILE chamado init.ora no diretório $ORACLE_HOME/dbs (Linux/Unix) ou no $ORACLE_HOME/database (Windows).

É possível também que o DBA especifique um diretório de sua preferência para gravar o PFILE, basta executar comando:

CREATE PFILE=C:/TEMP/initTESTE.ORA FROM SPFILE;

Caso seja necessário iniciar um banco Oracle com o PFILE pode-se utilizar o seguinte comando:

STARTUP OPEN PFILE='/OPT/ORACLE/PRODUCT/9IR2/DBS/initSID.ORA'

Uma consulta interessante para saber se sua instância está utilizando o SPFILE ou PFILE, é apresentada abaixo:

SELECT DECODE (VALUE, NULL, 'PFILE', 'SPFILE') "INIT FILE TYPE" FROM SYS.V_$PARAMETER WHERE NAME = 'SPFILE';

É importante saber que para iniciar uma instância Oracle, os parâmetros de inicialização são buscados nos diretórios devidos (mencionados anteriormente com a variação entre UNIX e WINDOWS), na seguinte ordem:

1.  spfileSID.ora

2.  spfile.ora

3.  initSID.ora

4.  init.ora

Bom pessoal, por hoje é só!

Espero ter ajudado a entender um pouco sobre arquivos de inicialização no banco Oracle.

Sinta-se a vontade para deixar seu comentário com críticas, sugestões ou elogios sobre os artigos. Isso me ajuda a saber se agrado ou não com meus artigos e seus temas.

Grande abraço e até a próxima!

Referências:

ORACLE HOME. Disponível em: http://www.oracle-home.ro/Oracle_Database/Maintenance/PFILEvsSPFILE.html. Acessado em: 20/05/2013.

Carvalho, Pedro - Arquivos de Parâmetros PFILE e SPFILE do Oracle. Disponível em: http://www.pedrofcarvalho.com.br/PDF/ORACLE_SPFILE_PFILE.pdf. Acessado em: 20/05/2013.

Oracle - Starting Up a Database. Disponível em: http://docs.oracle.com/cd/B28359_01/server.111/b28310/start001.htm. Acessado em: 21/05/2013.

Oracle - Specifying Initialization Parameters. Disponível em: http://docs.oracle.com/cd/B28359_01/server.111/b28310/create005.htm. Acessado em: 21/05/2013.

TOAD WORLD - INIT.ORA Parameters A-L. INIT.ORA Disponível em: http://www.toadworld.com/KNOWLEDGE/KnowledgeXpertforOracle/tabid/648/TopicID/ARC513A/Default.aspx. Acessado em: 21/05/2013.

TOAD WORLD - INIT.ORA Parameters M-Z. Disponível em: http://www.toadworld.com/KNOWLEDGE/KnowledgeXpertforOracle/tabid/648/TopicID/ARC513B/Default.aspx. Acessado em: 21/05/2013.

TOAD WORLD - INIT.ORA Parameters. Disponível em: http://www.toadworld.com/KNOWLEDGE/KnowledgeXpertforOracle/tabid/648/TopicID/ARC513/Default.aspx. Acessado em: 21/05/2013.

TOAD WORLD - Creating an SPFILE. Disponível em: http://www.toadworld.com/KNOWLEDGE/KnowledgeXpertforOracle/tabid/648/TopicID/SPF1/Default.aspx. Acessado em: 21/05/2013.

Leia mais...

Recriação de índices - Rebuild Index

Olá pessoal!

Hoje vou falar um pouco sobre rebuild de índice no Oracle.

No dia 04/04/2013 postei uma situação que eu tinha vivido no trabalho. O nome do post foi: "Recuperar uma instância Oracleapós a exclusão acidental de um datafile". Em uma passagem do que escrevi, cito um comando (ALTER TABLE OWNER.TBL_TABELA MOVE TABLESPACE TBS50MB) que move uma tabela para outra tablespace (ou a mesma tablespace), porém em contrapartida torna os índices da tabela em questão "inutilizável", e é sobre isso que falarei agora!

Quando um índice está com status inutilizável (UNUSABLE), ele necessita ser reparado antes que possa ser usado. Diferentemente de um objeto PL/SQL por exemplo, pois quando é acessado a primeira vez o objeto é recompilado automaticamente pelo Oracle.

Para identificar se um índice está inutilizável, podemos usar a consulta abaixo:

SELECT owner, table_name, index_name

  FROM dba_indexes

WHERE status = 'UNUSABLE';

Mas o que fazer para tornar o ínidice utilizável novamente?

Bom pessoal...

A forma que vou usar para tornar um índice novamente preparado para utilização, é muito importante também para desfragmentar o índice (caso o mesmo esteja fragmentado).

O problema da fragmentação aparece quando atualizamos ou apagamos (update/delete)  dados de uma tabela. Se os campos alterados possuem índices associados, provavelmente o índice ficará fragmentado. Podemos dizer que a fragmentação é a existência de espaços não utilizados (ou disponíveis) no meio de um espaço utilizado. Isso porque os espaços que são liberados durante manipulação dos dados (update/delete) não são imediatamente reutilizado, o que resulta em “espaços livres" ou "blocos de dados espalhados nas tablespaces “.

Basicamente, a sintaxe que vou apresentar aqui é:

ALTER INDEX owner.nome_do_indice REBUILD;

Mas vamos fazer com que esse script seja gerado para todos os indices que estão inutilizáveis no banco.

SELECT    ' alter index '

       || owner

       || '.'

       || index_name

       || ' rebuild; '

  FROM dba_indexes

 WHERE status = 'UNUSABLE';

A projeção dessa query pode ser usado para reconstruir os índices, e pode também desfragmentar o índice. Não necessariamente a desfragmentação do índice ocorrerá pois dependerá da disponibilidade de espaço livre da tablespace.

Por hoje é só!

Espero ter contribuído e agregado algum conhecimento a você leitor.

Fico grato por você ler meu post, e indico a leitura dos demais artigos publicados.

Um grande abraço e até a próxima!

Leia mais...

Explicação sobre RAID

Muito bom dia, pessoal!

Hoje vou compartilhar rapidamente com vocês uma figura que vi e achei muito interessante. Se trata de uma "explicação" sobre RAID que encontrei no blog do sábio DBA Ricardo Portilho.

Muito legal e se assemelha muito com a realidade!!

Confiram na figura abaixo.

Figura 1 - Entendendo o que é RAID. (Fonte: Blog do Portilho)

Referência:

Blog do Portilho - GPO Blogs. Entendendo RAID. Dsponível em: http://profissionaloracle.com.br/blogs/portilho/2009/07/28/entendendo-raid/ Acessado: 09/05/2013.

Leia mais...

Um pouco sobre redo log file e archive

Olá, meus caros!

Recentemente passei por um problema na empresa onde trabalho e achei um tema interessante para se abordar aqui no blog. Resumidamente a situação foi a seguinte: um dos servidores de banco de dados foi inesperadamente desligado, e quando a máquina foi ligada, no momento em que tentávamos “levantar” uma instância, não foi possível pois um dos arquivos de redo log estava corrompido. Foi uma situação muito tensa, pois era uma base importante para o negócio da empresa. Não vou entrar no detalhe do que aconteceu, tampouco falar da solução, mas motivado pelo problema ocorrido vou falar hoje um pouco sobre redo log file e archive.

Bom, pessoal...

Para começar, acho de extrema importância conhecermos algumas estruturas do banco. São elas: log buffer, log writer e archiver. Basicamente, o primeiro (log buffer) é uma área de memória pequena onde são gravadas instruções de desfazer uma alteração (comando DML) disparada contra a base, antes de essa instrução ser gravada no disco (no redo log file). Eu escrevi algo sobre essa estrutura com um pouco mais de riqueza no artigo: [Hard Parse]Parte 01 - Execução de comandos DML. O log writer é o processo de background responsável pela gravação do conteúdo do log buffer no redo log file. O archiver também é um processo de background, porém sua existência está condicionada a uma configuração da instância (ARCHIVELOG). O archiver copia o conteúdo dos arquivos de redo log (que são arquivos cíclicos e reutilizáveis – falarei melhor sobre isso) em arquivos chamados de archives (ou redo log arquivado). Cada uma dessas estruturas podem ser alvo de bastante discussão e conteúdo, que não focarei nesse post, mas é importante que entendamos ao menos o básico para não nos atrapalharmos mais adiante em outras explicações.

Redo Log File

Esse arquivo é uma cadeia contínua e cronológica de cada vetor de alteração (“instruções” para desfazer um DML de alteração – insert, update, delete). Uma utilidade de fácil entendimento desses arquivos é na recuperação de uma base após um problema que necessite “voltar” o backup. Para que não haja perda de trabalho até o momento do crash ou erro, os arquivos de redo log podem ser aplicados ao backup para refazer o trabalho, adiantando-os no tempo até o momento em que o dano ocorreu.

John Watson afirma que o redo log pode ser dividido em dois tipos: redo log online e o redo log arquivado (os archives).

Cada banco de dados deve ter por definição pelo menos dois redo log online. Arquivos de redo log compõe um grupo de arquivo, e são conhecidos como membros. Um banco de dados requer ao menos dois grupos com pelo menos um membro para funcionar. Para um melhor desempenho, podem ser criados mais de dois grupos, e para uma maior segurança, deve-se criar mais de um membro por grupo (caso opte por essa configuração não é necessário se preocupar com desempenho ou sincronismo, pois o processo responsável irá gravar em todos os membros de forma paralela mantendo-os idênticos). A razão do requisito mínimo para o banco Oracle funcionar ser um mínimo de dois grupos é devido à situação de que enquanto um dos grupos (o de status current) está recebendo as alterações (através de comando do processo de background Log Writer – LGWR), o outro está sendo “arquivado” (pelo processo de background Archiver – ARCn), ou seja, está sendo gerado um Archive a partir de um Redo Log File com status inactive. Um passo a passo do processo pode ser o seguinte: ao tempo em que as sessões dos usuários atualizam registros (no buffer cache), elas também gravam vetores de alterações mínimos no redo log buffer, e o LGWR continuamente grava os dados desse buffer para os arquivos que compõem o grupo de arquivos de redo log atual (com status current). Por serem de tamanhos limitados, os redo log se alternam quando estiverem completamente cheios, tornando o outro grupo o atual. Se o banco de dados estiver configurado para gerar Archive (o que é uma segurança para que não haja perda de dados), os processos ARCn arquivarão (ou copiarão) os membros do redo log file que compõe o primeiro grupo. Quando o segundo grupo é totalmente preenchido, o LGWR mudará de volta para o primeiro (setará seu status como current) e irá sobrescrever seu conteúdo (que já foi arquivado), ao mesmo tempo, o ARCn começará a arquivar o segundo grupo (de status inactive). Basicamente é dessa forma que se dá esse processo, de forma cíclica (alternância de log) e reutilizando os membros dos grupos de redo log file.

É importante saber que é possível adicionar ou excluir redo log files (inclusive com tamanhos diferentes dos demais) a qualquer momento, sem a necessidade de reiniciar a instância.

Para criar um novo grupo de redo log file, podemos usar o comando abaixo:

ALTER DATABASE ADD LOGFILE ('/oracle/dbs/log1c.rdo', '/oracle/dbs/log2c.rdo') SIZE 4M;

Ou criar um novo grupo especificando o seu número:

ALTER DATABASE ADD LOGFILE GROUP 10 ('/oracle/dbs/log1c.rdo', '/oracle/dbs/log2c.rdo') SIZE 4M;

E para adicionar um membro a um grupo, podemos utilizar o comando

ALTER DATABASE ADD LOGFILE MEMBER '/oracle/dbs/log2b.rdo' TO GROUP 2;

Ou de uma forma alternativa de identificar um grupo, que é identificando seus membros, conforme exemplo abaixo:

ALTER DATABASE ADD LOGFILE MEMBER '/oracle/dbs/log2c.rdo' TO ('/oracle/dbs/log2a.rdo', '/oracle/dbs/log2b.rdo');

Para excluir um grupo do redo log file, segundo a Oracle, existem três restrições. São elas:

 - É necessário que a mais de dois grupos de redo log file, para após a exclusão ainda existirem o mínimo aceitável pelo banco de dados Oracle (conforme explicado anteriormente);

 - Só é possível excluir grupos de redo log com status inactive. Para excluir o grupo atual (current), é necessário primeiro alternar o log para torná-lo inactive.

 - Tenha certeza que o redo log file foi arquivado (se estiver no modo archive) antes de excluí-lo. Na view V$LOG é possível verificar se já ocorreu o arquivamento.

O comando da exclusão é o seguinte:

ALTER DATABASE DROP LOGFILE GROUP 3;

Para excluir um membro, deve-se atender aos requisitos citados para o grupo pois seguem as mesmas restrições. a Sintaxe é a seguinte:

ALTER DATABASE DROP LOGFILE MEMBER '/oracle/dbs/log3c.rdo';

Para forçar que o banco alterne o grupo de redo log atual, podemos utilizar o comando:

ALTER SYSTEM SWITCH LOGFILE;

Archive

Vamos falar um pouco sobre o tal redo log file arquivado, ou archive.

O banco Oracle garante que sua instância nunca fique corrompida, por meio dos redo log files, porém para garantir que não haja perda de dados após uma falha, é necessário ter um registro de todas as alterações aplicadas ao banco de dados desde o último backup. Por default, um banco de dados é criado em modo NOARCHIVELOG, o que significa que os redo log files são sobrescritos sem que tenha ocorrido o arquivamento dos seus dados. Quando alteramos o banco para o modo ARCHIVELOG, a Oracle afirma que é impossível que ocorra perda de dados (desde que os archives gerados após o último backup estejam disponíveis. Nesse modo, um novo processo de background (na verdade são quatro processos por default) será iniciado automaticamente: o Archiver (ARCn), isso nas versões do Oracle a partir do 10G.

É importante saber que a transição do modo NOARCHIVELOG para ARCHIVELOG (ou o contrário) só pode ser feita enquanto o banco está no modo mount após um shutdown e deve ser feito por um usuário com privilégio SYSDBA. Também é necessário fazer a configuração nos parâmetros de inicialização que controlam os nomes e os locais dos archives.

Para habilitar o modo ARCHIVELOG, podemos usar os comandos abaixo:

SQLPLUS /NOLOG

CONNECT / AS SYSDBA

ALTER SYSTEM SET LOG_ARCHIVE_DEST_1=’LOCATION=/oracle/dbs/archives’ SCOPE=SPFILE;

SHUTDOWN IMMEDIATE;

STARTUP MOUNT;

ALTER DATABASE ARCHIVELOG;

ALTER DATABASE OPEN;

Bom pessoal…

Por hoje é isso!

Espero ter ajudado no entendimento sobre o redo log file do Oracle e o Archive.

Grande abraço a todos e até a próxima.

Referências:

Oracle® Database Administrator's Guide - 11g Release 1 (11.1) - Creating Redo Log Groups and Members. Disponível em: http://docs.oracle.com/cd/B28359_01/server.111/b28310/onlineredo003.htm. Acessado em 03/05/2013.

Oracle® Database Administrator's Guide - 11g Release 1 (11.1) - Dropping Redo Log Groups and Members. Disponível em: http://docs.oracle.com/cd/B28359_01/server.111/b28310/onlineredo005.htm. Acessado em 03/05/2013.

WATSON, JOHN – OCA Oracle Database 11g – Administração I – Guia do Exame 1z0-052. Editora: BOOKMAN.

Leia mais...