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.

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é

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!