Menu de navegação

[airoospParticipante]

Boa tarde,

Pessoal, o depto esta assumindo um ambiente Oracle RAC 11g com 2 nodes (Windows server 2012 r2) e estou procurando informações e me familiarizando com este ambiente.

O pessoal de infra informou que na unidade C do servidor há muitos arquivos LOG_???.XML cada um com 10MB e o mais antigo é de 22/02/2017.

Este tipo de arquivo é gerado pelo próprio Oracle quando o LISTENER.LOG atinge 10MB, certo?

O detalhe é que o LISTENER.LOG é gravado em C:oracleproduct11.2.0gridlogdiagtnslsnrcabd2listenertrace e os arquivos LOG_???.XML são gravados em C:oracleproduct11.2.0gridlogdiagtnslsnrcabd1listeneralert.

No LISTENER.ORA é possível utilizar o parâmetro LOG_DIRECTORY_LISTENER e alterar a localização do arquivo LISTENER.LOG, baixando e subindo o serviço do listener.

É possível alterar a localização dos arquivos LOG_???.XML?

Outra coisa, os arquivos mais antigos podem ser removidos?

Obrigado.

Airton

[José Laurindo ChiappaModerador]

Não estou com um ambiente do tipo facilmente disponível para testar (então escrevo aqui de Memória – Recomendo Fortemente que vc consulte a Documentação, os artigos do metalink E os bons livros de referência sobre o Assunto, como o “Pro Oracle Database 11g RAC on Linux”, o “Oracle Database 11g Oracle Real Application Clusters Handbook” e o “Oracle 11g R1 R2 Real Application Clusters Essentials” para se Certificar, bem como para melhorar os teus conhecimentos) mas ao que me lembro não : no 11gR2 a Oracle introduziu a figura do ADR, que é um repositório Centralizado de LOGs e TRACEs, e é ele que cria os logs no foramto .XML … iirc vc pode mudar os arquivos de log tradicionais (com extensão .LOG) de lugar com os parâmetros apropriados MAs não os .XML criados pelo ADR, que necessariamente vão prum sub-diretório abaixo do ponto de instalação do ADR, que é chamado de ADR_BASE… O que vc PODERIA fazer é mudar o ADR_BASE (veja os comandos para isso na Documentação do ADRCI), mas com isso vc estaria mudando o local de ** TODOS ** os arquivos criados/controlados pelo ADR, não só o dos logs em .XML….

Sobre remoção, sim : esses arquivos de log TODOS (seja os .LOG tradicionais, sejam os novos arquivos de log no formato .XML) são o log de eventos passados, não são necessários para o funcionamento do banco em si, então TECNICAMENTE FALANDO vc os pode apagar… A questão é que quando vc tiver problemas no seu ambiente e for precisar abrir um Chamado no Suporte Oracle (ou mesmo for precisar pesquisar por sua conta algum problema, principalmente de Rede e abort de processos) vc VAI PRECISAR desses logs todos, se vc os apagou sem mais aquela a informação por vezes crucial para diagnóstico neles contida está perdida…
O que se faz então é estabelecer uma Política de Remoção no ADR e purgar os arquivos via comandos ADR, Obviamente apenas os mais antigos , para que tenha havido TEMPO pra backupear eles antes…. Veja na Documentação e nas refs sobre os comandos PURGE (para remover), SHOW CONTROL (para mostrar a política de tempo de retenção) e relacionados…

[]s

Chiappa

[airoospParticipante]

Boa tarde,

Sim, eu pesquisei um pouco sobre o assunto e vi que esse ADR não funciona corretamente para remover os arquivos de log. No sites que vi, o pessoal recomenda remover manualmente os arquivos mais antigos.

Aqui o RAC é em Windows server 2012 r2 com 2 nodes. Vou pedir para o pessoal de infra copiar os arquivos mais antigos, isto é o arquivos até o dia 10/03/2017 para outra pasta, e assim ter mais espaço no servidor.

Obrigado.

Airton

[José Laurindo ChiappaModerador]

A limitação do PURGE do ADR é que (obviamente) ele só pode remover logfiles e traces/dumps gerados por ele mesmo e/ou pelo banco : arquivos gerados pelo ASM, pelo Clusterware, pelos Agents do OEM e assim por diante ele Não Conhece/Não remove, de modo geral…. Acho que é a isso que vc se refere (não tão precisamente) quando diz que o ADR “não funciona para remover logs”…
OK : apenas Recomendo que, como indiquei antes, vc faça um BACKUP desses caras antes de remover – então, se vc os move pra outra pasta sem problemas, só não esqueça de BACKUPEAR essa pasta antes do pessoal limpar/remover os arquivos nela…. Reforço , isso não é por causa do banco nem do RAC em si (esses arqs de log/trace/dump etc são inúteis pro banco e pro RAC), a idéia é vc ter a informação se algum dia precisar fazer diagnóstico de problemas de rede, de cluster, de banco, etc, nesse ambiente…

[]s

Chiappa

[airoospParticipante]

Opa,

Agradeço Chiappa a suas respostas, o detalhe é que no momento não tenho tempo para ver a documentação que você citou. Mas beleza, vou pedir o backup desdes arquivos antes de apagar da pasta.

Outra coisa, será que você pode ajudar, o cenário é o seguinte:

Tem uma aplicação que esta o Oracle RAC, para este sistema, foi criada uma tablespace com 3 datafiles e hoje esta com 40G, isto é:

+DATA/seg/datafile/mdc01.dbf, +DATA/seg/datafile/mdc02.dbf, +DATA/seg/datafile/mdc03.dbf,

select ((bytes / 1024) / 1024) as md
from dba_data_files
where tablespace = ‘MDC’

mdc01 15000 mb
mdc02 10000 mb
mdc03 15000 mb

Preciso exportar os dados dessa aplicação que estão no RAC 11g para um Single Instance 10g, mas antes tenho que criar usuário no banco de destino assim como a respectiva tablespace. O script que uso no single instance para ver (tamanho da tablespace, espaço utilizado, espaço livre), não funcionará no RAC, pois, este tem o armazenamento diferente, certo?

Para exportar este schema, é melhor usar o EXPDP do que o EXP, certo?

Aqui é muito comum fazer isso single instance para single instance, por causa dos ambientes de produção e homologação, ambos em 10g.

Obrigado.

Airton

[José Laurindo ChiappaModerador]

Seguem as respostas :

=======>>> “O script que uso no single instance para ver (tamanho da tablespace, espaço utilizado, espaço livre), não funcionará no RAC, pois, este tem o armazenamento diferente, certo?”

Se vc tá consultando as views internas do Oracle como DBA_TABLESPACES, DBA_FREE_SPACE, etc, a afirmação está Completamente Errada : RAC ou não, ASM ou não, o gerenciamento de espaço nas tablespaces é ** IGUALZINHO ** sempre…
Por exemplo, considere :

SQL> column bytes format 999G999G999G999
SQL> break on tablespace_name skip 1 on report
SQL> COMPUTE sum LABEL ‘SOMA DOS DATAFILES DA TABLESPACE’ OF bytes ON TABLPESPACE_NAME
SQL> COMPUTE sum LABEL ‘TOTAL GERAL’ OF bytes ON REPORT
SQL> select tablespace_name, file_name, bytes from dba_data_files;

TABLESPACE_NAME FILE_NAME BYTES

---

USERS C:ORACLEXEAPPORACLEORADATAXEUSERS.DBF 104.857.600

SYSAUX C:ORACLEXEAPPORACLEORADATAXESYSAUX.DBF 692.060.160

UNDOTBS1 C:ORACLEXEAPPORACLEORADATAXEUNDOTBS1.DBF 398.458.880

SYSTEM C:ORACLEXEAPPORACLEORADATAXESYSTEM.DBF 377.487.360

****************************** —————-
TOTAL GERAL 1.572.864.000

==> Neste meu exemplo, ** Não importa ** se vou criar os datafiles em ASM ou em filesystem, eu preciso do 1,5 GB acima demonstrado como um minimo…

A diferença vai ser na hora de vc quere CONSULTAR o espaço livre e consumido ** NO DISCO ** para vc poder criar os datafiles : para gerenciar espaço de disco dentro de um filesystem vc simplesmente faz um df -kh (ou um DIR se fosse Windows, enfim),ENQUANTO que para vc ver o espaço livre dentro do ASM vc tem que usar o utilitário asmcmd OU consultar as views correspondentes ao ASM, como v$asm_diskgroup (para ver os diskgroups), V$ASM_DISK para ver os discos…
Se vc não tiver uma GUI que te mostre isso (iirc o OEM mostra) , um script para vc consultar espaço livre nos discos ASM e nos diskgroups, a fim de confirmar se há o espaço necessário para criar os datafiles que vc já consultou antes com teu mesmo script de sempre, poderia ser :

set lines 255
col path for a35
col Diskgroup for a15
col DiskName for a20
col disk# for 999
col total_mb for 999,999,999
col free_mb for 999,999,999
compute sum of total_mb on DiskGroup
compute sum of free_mb on DiskGroup
break on DiskGroup skip 1 on report –
set pages 255
select a.name DiskGroup, b.disk_number Disk#, b.name DiskName, b.total_mb, b.free_mb, b.path, b.header_status
from v$asm_disk b, v$asm_diskgroup a
where a.group_number (+) =b.group_number
order by b.group_number, b.disk_number, b.name
/
set lines 122
set pages 66

Vc CAPTOU a diferença, né ? Espaço DENTRO da tablespace é sempre a mesma coisa, é o Espaço nos discos que dá alteração…

=====>>> “Preciso exportar os dados dessa aplicação que estão no RAC 11g para um Single Instance 10g, mas antes tenho que criar usuário no banco de destino assim como a respectiva tablespace”

ok : realmente, seja com exp seja com expdp se vc usar a opção de exportar apenas um schema o export *** não *** vai criar nem o usuário nem as tablespaces no banco-destino, sim, então a primeira vez que vc for fazer o import antes tem que ter criado o usuário E as tablespaces, sim…
Uma opção para vc extrair os comandos de CREATE USER, CREATE TABLESPACE e os GRANTs necessários pra criar o usuário e a tablespace lá no banco-destino é vc rodar no banco-origem a package DBMS_METADATA, cfrme https://oracle-base.com/dba/script?category=script_creation&file=user_ddl.sql e https://oracle-base.com/dba/script?category=script_creation&file=tablespace_ddl.sql – obviamente, uma vez extraído o SQL, vc o altera para trocar a parte onde se indica diskgroup para indicar um filesystem, é claro….
Outra coisa que vc pode fazer é alterar os scripts para listarem apenas as tablespaces que contém objetos pertencentes ao usuário que vc quer exportar/recriar, bastaria trocar DBA_TABLESPACES por DBA_SEGMENTS w incluir mais um filtro com OWNER=usuarioaserexportado…

=====>>> “Para exportar este schema, é melhor usar o EXPDP do que o EXP, certo?”

Não : em não havendo datatypes extendidos que o exp não entenda ou qualquer outra razão que ** demande ** expdp, usando os parâmetros adequados (como direct-mode), em várias sessões paralelas E sendo executados diretamente no servidor (para poupar tráfego de rede), eu esperaria ver performances *** SIMILARES *** entre o expdp e o exp…. Dá uma testada no seu ambiente e compare os dois…

OBS : Uma Exceção completamente possível que favoreceria ENORMEMENTE o expdp é se vc fosse gerar o dump file dentro do ASM (pois via de regra os discos que estão no ASM são ** imensamente mais Rápidos ** do que os simples discos locais do filesystem), OU então se vc fosse gerar o dump file num mountpoint NFS, que depois seria acessado pela máquina-destino (via de regra o expdp é muito mais eficiente do que o exp tradicional em NFS, até por ser mais recente)….

[]s

Chiappa

[Autor]

Posts