Sempre quando vamos realizar uma instalação de um ambiente diferente do nosso habitual, buscamos em fóruns, blogs, google, etc, exemplos e tutorias de pessoas que já passaram pela situação, que postaram algo referente a instalação, etc...
Porém nada melhor que a documentação da própria Oracle.
O link abaixo possui um tutorial muito completo sobre a instalação do 11gR2 com ASM no Oracle Linux (ou Red Hat), com informações muito mais detalhadas do que qualquer outro tutorial que já encontrei por ai... vale dar uma olhada:
http://docs.oracle.com/cd/E11882_01/install.112/e24321/toc.htm
Até logo!
segunda-feira, 26 de março de 2012
sábado, 7 de maio de 2011
DATA PUMP com REMAP_SCHEMA e REMAP_TABLESPACE
Ok. Faz quase um ano que não posto nada aqui, isso após somente 2 posts. Tudo bem. Se você está lendo isso agora e está entrando nesta via de DBA, se prepare: você não terá tempo para BLOGS! rs. É temos muito serviço, há muita demanda no mercado para profissionais ORACLE DBA porém a exigência é grande.
Bom, hoje irei abordar um processo simples usando EXPDP/IMPDP (Data Pump). O objetivo do BLOG é ajudar em processos simples do dia-a-dia de um DBA Jr. e não ir profundamente em nenhum assunto. Por isso não irei abordar aqui o conceito do EXPDP nem todas as possibilidade que temos com ele.
O REMAP_SCHEMA e o REMAP_TABLESPACE se tornaram parte da minha rotina devido a clientes que insistem em colocar ambiente de teste, homologação, produção, desenvolvimento, etc, na mesma instância do banco de dados, fazendo esta separação através de usuários do banco (schema) e tablespace distintas para cada aplicação. Esta prática é altamente irrecomendável (rs), porém é muito comum e temos que nos adaptar a ela.
Bom, por exemplo: Solicitam a atualização de um SCHEMA APP_TESTE (ambiente de teste), com base no SCHEMA APP_PROD (ambiente de produção), sendo que os 2 estão no mesmo banco de dados. Ai é que entra o nosso amigo (e acreditem, ainda pouco explorado) EXPDP:
1) Realizar o EXPORT do SCHEMA de produção usando EXPDP:
$ expdp system/senha schemas=APP_PROD directort=BACKUP dumpfile=APP_PROD.dmp logfile=APP_PROD.log
Obs: o diretório BACKUP deve já existir ou ser criado antes do início do processo:
SQL> create or replace directory BACKUP as '/tmp'; -- exemplo
2) Dropar objetos no SCHEMA APP_TESTE (ambiente de testes):
Antes da importação temos que nos certificar que o schema onde serão impostados os dados do APP_TESTE (exportados no item 1) está vazio. Para isso, uso os 3 SELECTS abaixo, que geram os scripts para dropar todos os objetos de um SCHEMA:
spool drop_fk.sql
select 'alter table '||owner||'."'||table_name||'" drop constraint "'||constraint_name||'"' cmd
from dba_constraints
where owner = 'APP_TESTE'
and constraint_type='R';
spool off
spool drop_tables.sql
select 'drop table '||owner||'."'||table_name||'"' cmd
bulk collect into v_tabs
from dba_tables
where owner = 'APP_TESTE';
spool off
spool drop_objects.sql
select 'drop '||object_type||' '||owner||'."'||object_name||'"' cmd
bulk collect into v_objs
from dba_objects
where owner = 'APP_TESTE'
and object_type not in ('LOB')
order by object_type;
spool off
-- Executa scripts gerados
@drop_fk.sql
@drop_tables.sql
@drop_objects.sql
3) Realizar a importação dos dados do SCHEMA APP_PROD para o APP_TESTE, supondo:
- Tablespaces usadas por APP_PROD: APP_PROD_DT e APP_PROD_IX
- Tablespaces usadas por APP_TESTE: APP_TESTE_DT e APP_TESTE_IX
# impdp system/senha DIRECTORY=BACKUP dumpfile=APP_PROD.dmp logfile=impdpAPP_TESTE.log remap_schema=APP_PROD:APP_TESTE remap_tablespace=APP_PROD_DT:APP_TESTE_DT,APP_PROD_IX:APP_TESTE_IX
No IMPDP acima estamos utilizando o DUMP (APP_PROD.dmp) gerado pelo EXPDP e 'informando' que os dados do schema APP_PROD devem ser importados no schema APP_TESTE. Destes dados, os que estiverem armazenados nas tablespaces APP_PROD_DT e APP_PROD_IX devem ser agora importados nas tablespaces APP_TESTE_DT e APP_TESTE_IX.
Obs: Antes de realizar a importação você deve saber em que tablespaces estão as tabelas/índices do schema APP_PROD, que você pode obter consultando as views DBA_TABLES e DBA_INDEXES.
Vale também ressaltar que para realizar o EXPDP e IMPDP, o usuário que realizará o processo (system nos exemplos acima) devem ter grant de DBA ou grant de CONNECT, RESOURCE, EXP_FULL_DATABASE e FLASHBACK ANY TABLE.
Tenho certeza que mais dia, menos dia o REMAP_SCHEMA e o REMAP_TABLESPACE será muito útil para você!
Até a próxima!
Bom, hoje irei abordar um processo simples usando EXPDP/IMPDP (Data Pump). O objetivo do BLOG é ajudar em processos simples do dia-a-dia de um DBA Jr. e não ir profundamente em nenhum assunto. Por isso não irei abordar aqui o conceito do EXPDP nem todas as possibilidade que temos com ele.
O REMAP_SCHEMA e o REMAP_TABLESPACE se tornaram parte da minha rotina devido a clientes que insistem em colocar ambiente de teste, homologação, produção, desenvolvimento, etc, na mesma instância do banco de dados, fazendo esta separação através de usuários do banco (schema) e tablespace distintas para cada aplicação. Esta prática é altamente irrecomendável (rs), porém é muito comum e temos que nos adaptar a ela.
Bom, por exemplo: Solicitam a atualização de um SCHEMA APP_TESTE (ambiente de teste), com base no SCHEMA APP_PROD (ambiente de produção), sendo que os 2 estão no mesmo banco de dados. Ai é que entra o nosso amigo (e acreditem, ainda pouco explorado) EXPDP:
1) Realizar o EXPORT do SCHEMA de produção usando EXPDP:
$ expdp system/senha schemas=APP_PROD directort=BACKUP dumpfile=APP_PROD.dmp logfile=APP_PROD.log
Obs: o diretório BACKUP deve já existir ou ser criado antes do início do processo:
SQL> create or replace directory BACKUP as '/tmp'; -- exemplo
2) Dropar objetos no SCHEMA APP_TESTE (ambiente de testes):
Antes da importação temos que nos certificar que o schema onde serão impostados os dados do APP_TESTE (exportados no item 1) está vazio. Para isso, uso os 3 SELECTS abaixo, que geram os scripts para dropar todos os objetos de um SCHEMA:
spool drop_fk.sql
select 'alter table '||owner||'."'||table_name||'" drop constraint "'||constraint_name||'"' cmd
from dba_constraints
where owner = 'APP_TESTE'
and constraint_type='R';
spool off
spool drop_tables.sql
select 'drop table '||owner||'."'||table_name||'"' cmd
bulk collect into v_tabs
from dba_tables
where owner = 'APP_TESTE';
spool off
spool drop_objects.sql
select 'drop '||object_type||' '||owner||'."'||object_name||'"' cmd
bulk collect into v_objs
from dba_objects
where owner = 'APP_TESTE'
and object_type not in ('LOB')
order by object_type;
spool off
-- Executa scripts gerados
@drop_fk.sql
@drop_tables.sql
@drop_objects.sql
3) Realizar a importação dos dados do SCHEMA APP_PROD para o APP_TESTE, supondo:
- Tablespaces usadas por APP_PROD: APP_PROD_DT e APP_PROD_IX
- Tablespaces usadas por APP_TESTE: APP_TESTE_DT e APP_TESTE_IX
# impdp system/senha DIRECTORY=BACKUP dumpfile=APP_PROD.dmp logfile=impdpAPP_TESTE.log remap_schema=APP_PROD:APP_TESTE remap_tablespace=APP_PROD_DT:APP_TESTE_DT,APP_PROD_IX:APP_TESTE_IX
No IMPDP acima estamos utilizando o DUMP (APP_PROD.dmp) gerado pelo EXPDP e 'informando' que os dados do schema APP_PROD devem ser importados no schema APP_TESTE. Destes dados, os que estiverem armazenados nas tablespaces APP_PROD_DT e APP_PROD_IX devem ser agora importados nas tablespaces APP_TESTE_DT e APP_TESTE_IX.
Obs: Antes de realizar a importação você deve saber em que tablespaces estão as tabelas/índices do schema APP_PROD, que você pode obter consultando as views DBA_TABLES e DBA_INDEXES.
Vale também ressaltar que para realizar o EXPDP e IMPDP, o usuário que realizará o processo (system nos exemplos acima) devem ter grant de DBA ou grant de CONNECT, RESOURCE, EXP_FULL_DATABASE e FLASHBACK ANY TABLE.
Tenho certeza que mais dia, menos dia o REMAP_SCHEMA e o REMAP_TABLESPACE será muito útil para você!
Até a próxima!
quinta-feira, 3 de junho de 2010
Alterando local dos DATAFILES
Esses dias me deparei com um chamado pouco comum porém óbvio e que tem relação com o post anterior: por "FALTA DE ESPAÇO EM DISCO", o cliente solicitou/necessitou da alteração do local dos datafiles.
O banco cresceu e divide a mesma unidade de disco com outros arquivos importantes, tornando necessária a movimentação dos datafiles para outra unidade de disco. Vamos aos passos necessários, é bem simples:
- Primeiro temos que derrubar a base de dados, para que a cópia seja consistente e sem problemas. Como "/ as sysdba":
SQL> shutdown immediate
- Depois devemos mover todos os datafiles, ou por maior segurança inicialmente copiá-los para a nova unidade de discos:
# cp /oracle/oradata/orcl/*.dbf /u01/oradata/orcl/
- Se os controlfiles forem para a nova unidade de discos, devemos realizar a devida alteração no arquivo de parâmetros. Neste caso é interessante criar uma cópia do mesmo (ex: SQL> create pfile='/oracle/pfile.txt' from spfile;) por segurança, e alterar o caminho no pfile:
Alterar de:
*.control_files=/oracle/oradata/orcl/CONTROL01.CTL,
/oracle/oradata/orcl/CONTROL02.CTL, /oracle/oradata/orcl/CONTROL03.CTL
para:
*.control_files=/u01/oradata/orcl/CONTROL01.CTL,
/u01/oradata/orcl/CONTROL02.CTL, /u01/oradata/orcl/CONTROL03.CTL
- Feito isso, devemos subir a base em modo MOUNT e com o pfile criado e já alterado:
SQL> startup mount pfile='/oracle/pfile.txt';
Só para relembrar, de forma bem resumida e simples:
- modo nomount: lê o arquivo de parametros (spfile ou pfile) e sobe a instância somente
- modo mount: lê o controlfile
- modo open: lê os datafiles
Ou seja, se abrimos o banco em modo MOUNT, significa que o PFILE foi lido corretamente e que os CONTROLFILES estão corretos no local que indicamos ao copiá-los/movê-los e ao alterar o PFILE.
- Feito isso, devemos indicar para o CONTROLFILE a alteração do local dos DATAFILES que estamos modificando de lugar. O comando é simples, conforme o exemplo:
SQL> alter database rename file '/oracle/oradata/orcl/tsd_orcl_01.dbf' TO '/u01/oradata/orcl/tsd_orcl_01.dbf';
Este comando deve ser emitido para cada um dos DATAFILES.
- Caso precise se certificar de todos os caminhos e nomes dos DATAFILES, podemos utilizar a dba_data_files ainda com o banco em modo OPEN:
SQL> select file_name from dba_data_files;
- Após renomear todos os DATAFILES e com a certeza de que eles estão no caminho indicado, base abrir o banco:
SQL> alter database open;
Vale lembrar que desta forma podemos também mover somente alguns DATAFILES ou mesmo somente os CONTROLFILES. Isto é útil quando estamos buscando melhorar o desempenho de I/O no Oracle. Se tivérmos discos diferentes, podemos por exemplo separar tablespaces de índices e dados, ou separar dois datafiles que são mais requisitados, etc.
O banco cresceu e divide a mesma unidade de disco com outros arquivos importantes, tornando necessária a movimentação dos datafiles para outra unidade de disco. Vamos aos passos necessários, é bem simples:
- Primeiro temos que derrubar a base de dados, para que a cópia seja consistente e sem problemas. Como "/ as sysdba":
SQL> shutdown immediate
- Depois devemos mover todos os datafiles, ou por maior segurança inicialmente copiá-los para a nova unidade de discos:
# cp /oracle/oradata/orcl/*.dbf /u01/oradata/orcl/
- Se os controlfiles forem para a nova unidade de discos, devemos realizar a devida alteração no arquivo de parâmetros. Neste caso é interessante criar uma cópia do mesmo (ex: SQL> create pfile='/oracle/pfile.txt' from spfile;) por segurança, e alterar o caminho no pfile:
Alterar de:
*.control_files=/oracle/oradata/orcl/CONTROL01.CTL,
/oracle/oradata/orcl/CONTROL02.CTL, /oracle/oradata/orcl/CONTROL03.CTL
para:
*.control_files=/u01/oradata/orcl/CONTROL01.CTL,
/u01/oradata/orcl/CONTROL02.CTL, /u01/oradata/orcl/CONTROL03.CTL
- Feito isso, devemos subir a base em modo MOUNT e com o pfile criado e já alterado:
SQL> startup mount pfile='/oracle/pfile.txt';
Só para relembrar, de forma bem resumida e simples:
- modo nomount: lê o arquivo de parametros (spfile ou pfile) e sobe a instância somente
- modo mount: lê o controlfile
- modo open: lê os datafiles
Ou seja, se abrimos o banco em modo MOUNT, significa que o PFILE foi lido corretamente e que os CONTROLFILES estão corretos no local que indicamos ao copiá-los/movê-los e ao alterar o PFILE.
- Feito isso, devemos indicar para o CONTROLFILE a alteração do local dos DATAFILES que estamos modificando de lugar. O comando é simples, conforme o exemplo:
SQL> alter database rename file '/oracle/oradata/orcl/tsd_orcl_01.dbf' TO '/u01/oradata/orcl/tsd_orcl_01.dbf';
Este comando deve ser emitido para cada um dos DATAFILES.
- Caso precise se certificar de todos os caminhos e nomes dos DATAFILES, podemos utilizar a dba_data_files ainda com o banco em modo OPEN:
SQL> select file_name from dba_data_files;
- Após renomear todos os DATAFILES e com a certeza de que eles estão no caminho indicado, base abrir o banco:
SQL> alter database open;
Vale lembrar que desta forma podemos também mover somente alguns DATAFILES ou mesmo somente os CONTROLFILES. Isto é útil quando estamos buscando melhorar o desempenho de I/O no Oracle. Se tivérmos discos diferentes, podemos por exemplo separar tablespaces de índices e dados, ou separar dois datafiles que são mais requisitados, etc.
sábado, 24 de abril de 2010
Listener Log
Quem nunca passou pela seguinte situação: cliente liga e diz que o espaço em disco já era. E agora o que fazer? Sempre atacamos o crescimento da tablespace de UNDO ou da TEMP, tamanho de alert e archives acumulando. Mesmo assim muitos DBA's iniciantes (como já aconteceu comigo) não se dão conta de que o LISTENER gera um log de todas as conexões realizadas no banco de dados.
Dependendo da aplicação e do banco, o crescimento pode ser mínimo e insignificante ou pode ser enorme e incômodo - então, vamos limpá-lo!
Onde está o log do listener?
$ORACLE_HOME/network/log/listener.log
Para limpá-lo, primeiro desabilitamos a "alimentação" do log:
- Entra no prompt do listener:
# lsnrctl
- Seta o status do log como OFF:
LSNRCTL> set log_status off
Então podemos apagar o arquivo ou se necessário copiá-lo para outro disco/partição e posteriormente habilitamos novamente o log que, caso tenha sido excluído o arquivo, um novo será gerado:
- Entra no prompt do listener:
# lsnrctl
- Seta o status do log como ON:
LSNRCTL> set log_status on
Procedimento simples e que pode economizar alguns "gigas" de espaço em disco. Vale a pena também analisar a necessidade de manter o log do listener. Na minha opinião é interessante mantê-lo para podermos auditar qualquer problema que venha a ocorrer com a conexão do Client com o Server.
Até
Dependendo da aplicação e do banco, o crescimento pode ser mínimo e insignificante ou pode ser enorme e incômodo - então, vamos limpá-lo!
Onde está o log do listener?
$ORACLE_HOME/network/log/listener.log
Para limpá-lo, primeiro desabilitamos a "alimentação" do log:
- Entra no prompt do listener:
# lsnrctl
- Seta o status do log como OFF:
LSNRCTL> set log_status off
Então podemos apagar o arquivo ou se necessário copiá-lo para outro disco/partição e posteriormente habilitamos novamente o log que, caso tenha sido excluído o arquivo, um novo será gerado:
- Entra no prompt do listener:
# lsnrctl
- Seta o status do log como ON:
LSNRCTL> set log_status on
Procedimento simples e que pode economizar alguns "gigas" de espaço em disco. Vale a pena também analisar a necessidade de manter o log do listener. Na minha opinião é interessante mantê-lo para podermos auditar qualquer problema que venha a ocorrer com a conexão do Client com o Server.
Até
Welcome
É isso ai! Este é mais um entre os centenas de blogs sobre Oracle Database que você pode encontrar na internet. Mas, se é só mais um, porque criá-lo? O objetivo deste blog é compartilhar as experiências de um DBA Oracle Junior, aquele que apanha o dia todo e vive de Google e de Metalink.
Ao contrário da maioria dos blogs, que se aprofundam nos assuntos complexos de performance, RAC, alta disponibilidade e coisas mirabolantes, o "DBA ORACLE Jr." irá mostrar coisas básicas do dia-a-dia de um DBA junior e que nem sempre estão nas literaturas ou que passam desapercebidas nos cursos e treinamentos.
Espero que seja útil, para mim e para quem ler!
Ao contrário da maioria dos blogs, que se aprofundam nos assuntos complexos de performance, RAC, alta disponibilidade e coisas mirabolantes, o "DBA ORACLE Jr." irá mostrar coisas básicas do dia-a-dia de um DBA junior e que nem sempre estão nas literaturas ou que passam desapercebidas nos cursos e treinamentos.
Espero que seja útil, para mim e para quem ler!
Assinar:
Postagens (Atom)