datablock corrompido?

Há pouco tempo vi no alert que tinha um datablock corrompido na base. Segui a solução do MOS e repasso-a aqui:

No alert_orcl.log recebi a seguinte linha de erro:

ORA-01578: ORACLE data block corrupted (file # 6, block # 2506161)
ORA-01110: data file 6: ‘/u01/app/oracle/oradata/orcl/users4.dbf’

E pude confirmá-la através da query abaixo:

SQL> select * from v$database_block_corruption;

FILE#       BLOCK#       BLOCKS       CORRUPTION_CHANGE#       CORRUPTIO

———       ————        ————        ————————————-       —————-

6              2506161      1                   0                                        CORRUPT

Com o número do arquivo e o número do bloco em mãos, preencha a query abaixo e a execute:

SELECT
‘Tablespace: ‘||tablespace_name TS,
‘Extent-RFN-Blk: ‘||relative_fno||’ ‘||block_id EXTENT,
‘Segment-Type: ‘||segment_type SEGTYPE,
‘Segment: ‘||owner||’.’||segment_name SEGMENT,
‘Partition: ‘||PARTITION_NAME PARTITION,
‘Extent-ID/Blocks: ‘||extent_id||’ / ‘||blocks EXT_BLK
FROM dba_extents
WHERE file_id=<FILE#> and <BLOCK#> between block_id and block_id+blocks-1;

E o resultado será algo como:

Tablespace: USERS
Extent-RFN-Blk: 6 2506121
Segment-Type: INDEX
Segment: USUARIO.EMPREGADOS_001
Partition:
Extent-ID/Blocks: 12 / 128

Já sabemos, então, que o que foi corrompido foi um INDEX. No meu caso só precisei fazer 3 passos para me ver livre e tranquilo desse problema. Primeiro o rebuild do INDEX:

alter index USUARIO.EMPREGADOS_001 rebuild online;

Depois verificar o datafile inteiro em busca de mais blocos corrompidos:

dbv file=/u01/app/oracle/oradata/orcl/users4.dbf

E, por fim, um dump do bloco afetado para análise:

alter session set tracefile_identifier=’BLOCKDUMP’;
alter session set max_dump_file_size = unlimited;
alter system dump datafile ‘/u01/app/oracle/oradata/orcl/users4.dbf’ block 2506161;

E pronto. Resolvido.

apagando no SQL Plus

Como apagar caracteres no SQL Plus no Linux?

Em vez de você apertar o backspace e surgir dois caracteres referentes àquela tecla no SQLPLUS, digite o seguinte:

!stty erase [BACKSPACE]

Pressione a tecla backspace após o erase, como indicado. Deve surgir algo como:

SQL> !stty erase ^H

E voilá. Agora é possível apagar os caracteres sem problemas.

java.sql.SQLException: Conexão Fechada

Toda vez que uma sessão de Jboss sofria um kill (alter system kill session), uma série de erros “java.sql.SQLException: Conexão Fechada” era gerada:

Caused by: java.sql.SQLException: Conexão Fechada
Caused by: java.sql.SQLException: Conexão Fechada
Caused by: java.sql.SQLException: Conexão Fechada
2017-09-14 11:29:10,518 ERROR [org.hibernate.util.JDBCExceptionReporter] Conexão Fechada
Caused by: java.sql.SQLException: Conexão Fechada
2017-09-14 11:29:10,731 ERROR [org.hibernate.util.JDBCExceptionReporter] Conexão Fechada
Caused by: java.sql.SQLException: Conexão Fechada
2017-09-14 11:29:11,177 ERROR [org.hibernate.util.JDBCExceptionReporter] Conexão Fechada
Caused by: java.sql.SQLException: Conexão Fechada
Caused by: java.sql.SQLException: Conexão Fechada
Caused by: java.sql.SQLException: Conexão Fechada
2017-09-14 11:29:11,896 ERROR [org.hibernate.util.JDBCExceptionReporter] Conexão Fechada
Caused by: java.sql.SQLException: Conexão Fechada
2017-09-14 11:29:12,077 ERROR [org.hibernate.util.JDBCExceptionReporter] Conexão Fechada
Caused by: java.sql.SQLException: Conexão Fechada

E estes erros também causavam impacto direto na aplicação, gerando Status 500 e impactando seu uso. Toda vez que um kill era executado, a sessão do Jboss continuava tentando executar suas funções e não encontrava uma conexão direta com o banco estabelecida, gerando erros indefinidamente. Para parar os erros, apenas fazendo um restart no Jboss, o que causava sua indisponibilidade total.

Como fazer um workaround temporário para isso?

Simplesmente adicionar a linha abaixo no arquivo *ds.xml, um de seus arquivos de configuração do jboss:

<check-valid-connection-sql>select 1 from dual</check-valid-connection-sql>

Com isso, as sessões do Jboss vão tentar executar uma query de validação sempre antes de tentar continuar com suas funções. Caso não consigam, vão tentar estabelecer uma nova conexão com o banco. Com isso o problema de Conexão Fechada é solucionado.

sinônimos do oracle

Sempre bom deixar em mãos.

Digamos que tem o usuário BOB_DEE e quer que ele acesse os dados da tabela DEF_STRATEGY, porém esta tabela pertence ao usuário TOM_DAY.

SELECT * FROM TOM_DAY.DEF_STRATEGY;

O sinônimo entra como um facilitador, um atalho.

CREATE (PUBLIC) SYNONYM DEF_STRATEGY FOR TOM_DAY.DEF_STRATEGY;

A partir daí o select anterior pode ser feito da seguinte forma:

SELECT * FROM DEF_STRATEGY;

Pronto, sinônimo criado. Há a distinção entre público e privado que deve ser sempre levada em consideração antes da criação do sinônimo. Enfim, para apagar/dropar o sinônimo:

DROP SYNONYM DEF_STRATEGY;

Diferenças no Tratamento de Linhas em Branco

Estava executando um script para gerar um relatório através do SQL*Plus e sempre parava no mesmo resultado de 1400 linhas, quando no SQL Developer o resultado era 4000 linhas. A query em si não demonstrava erro na tela, quando rodada pelo SQL*Plus. 

Era algo como:

SELECT campo1,
campo2
FROM tabelaUno
WHERE Uno = Duo
UNION

 

SELECT campo1,
campo2
FROM tabelaZwei
WHERE Uno = Duo
UNION

 

SELECT campo1,
campo2
FROM tabelaTrois
WHERE Uno = Duo;

E a mesmíssima query era rodada das duas formas. O que poderia estar errado?

Simples. Aparentemente o SQL*Plus tem sérios problemas com linhas em branco. Ele lia a query mas só executava o último select, ignorando todo o resto da query. Retirando as linhas, tcharãn, resultados iguais no SQL*Plus e no SQL Developer. 

Problema com Restores e Incarnations

Era um processo rotineiro de clonagem do banco de produção para o desenvolvimento. Não havia o que errar, o processo já estava no sangue e o fazia instintivamente. Até que essa semana fui surpreendido com um ORA-01180 – can not create datafile 1.

Refiz então o processo esperando que fosse só um erro ao acaso, voodoo talvez. Mas não, novamente o 01180. Apaguei os datafiles todos que eu tinha e refiz o processo. Mesmo problema. Notei que, assim que o RESTORE era executado uma nova incarnation era criada, o que é errado, já que a incarnation só deveria ser criada após o recover.

Tentei mudar para a incarnation original (reset database to incarnation 1) e refiz o restore. Sucesso. Ou, pelo menos, aparentemente sucesso.

Prossegui com o processo e bati em uma nova parede: erro no recover: ORA-19909: datafile 1 belongs to an orphan incarnation.

Ou seja, o restore criava uma nova incarnation assim que era executado e alternava para ela. Dava erro ORA-01180 e não restaurava. Ao mudar a incarnation na mão o restore concluía, porém os archivelogs não podiam ser aplicados.

Pesquisa daqui e dali. Cheguei a criar um SR no MOS. Até que achamos esse post do ucraniano Oleksandr Denysenko que relatava um problema similar, cuja solução não se aplicava a nossa situação. Porém, ele indicava uma entrada no suporte da Oracle a respeito de “Common Causes for RMAN-06023 and RMAN-06026”. Eu não havia tido esses erros, porém decidimos ler a entrada e, surpreendentemente, lá havia um parágrafo que explicava, enfim, o meu problema:

New incarnation added due to implicit resync

This is isssue is only relevant if a Flash | Fast Recovery Area (FRA) is being used.

If 1 or more restore and recovery attempts have been done for this database and the database has been opened with RESETLOGS,
than there might be archived redologs generated for this new incarnation of the database.

During the RMAN recovery-phase, RMAN will do an catalog of all the files in the FRA, and will catalog the new archived redologs aswell.
As they belong to another incarnation, the incarnation will be added (if not there) and will be marked as CURRENT.
The recovery will than look for archived redologs of a different incarnation than intended, as the CURRENT incarnation belongs to a prior RESETLOGS-operation

The best option is to remove all the old files from the FRA eg. flashbacklogs, archivelogs, backupsets, datafiles etc.
belonging to an incarnation of a prior attempt.

Então seguimos o conselho da entrada. Apagamos todos os datafiles novamente, todos os archivelogs e backupsets que estavam no servidor, e tentamos fazer o restore a partir de um backup novo e intocado. Sucesso. Prosseguimos para o recover. Sucesso!

Ou seja, o problema se deu com mais de um restore e recover sendo executados antes de o banco ser aberto com OPEN RESETLOGS.

Então, se alguém enfrentar esse mesmo problema, de incarnations sendo criadas assim que é executado o restore e que não é possível criar datafiles sem mudança de incarnation, muito provavelmente está enfrentando o mesmo problema que enfrentei. Boa sorte!

emoms.properties goes bye bye

Essa minha sorte, vou te contar.

Hoje tive a satisfação de descobrir que a versão do banco que uso é agraciada com um bugzinho chato. Quando a partição onde está instalado o Oracle enche há grandes chances de o próprio Oracle apagar o arquivo emoms.properties e zoar o funcionamento do Enterprise Manager. Referência ao bug: Unpublished Bug 6716659 – [ 10.2.0.4.0 RC2 ] EMOMS.PROPERTIES REMAINS EMPTY UNDER OMS_HOME/SYSMAN/CONFIG (fonte).

Pra resolver isso eu me baseei nesse howto da Oracle. Tive sorte de ter um emoms.properties de outro servidor também para servir de ajuda na re-criação do meu. E ele ficou mais ou menos assim:

oracle.sysman.emSDK.svlt.ConsoleServerName=|hostname|_Management_Service
oracle.sysman.eml.mntr.emdRepPwd=|senha do sysman|
emdrep.ping.pingCommand=/usr/sbin/ping
oracle.sysman.eml.mntr.emdRepPort=1231
oracle.sysman.eml.mntr.emdRepDBName=|SID|
oracle.sysman.eml.mntr.emdRepPwdSeed=|senha do sysman|
oracle.sysman.emSDK.svlt.ConsoleMode=standalone
oracle.sysman.emRep.dbConn.statementCacheSize=30
oracle.sysman.db.isqlplusUrl=http\://|hostname|\:4360/isqlplus/dynamic
oracle.sysman.emSDK.svlt.ConsoleServerPort=5500
oracle.sysman.eml.mntr.emdRepRAC=FALSE
oracle.sysman.emSDK.emd.rt.useMonitoringCred=true
oracle.sysman.eml.mntr.emdRepPwdEncrypted=TRUE
oracle.sysman.db.isqlplusWebDBAUrl=http\://|hostname|\:4360/isqlplus/dba/dynamic
oracle.sysman.emSDK.svlt.ConsoleServerHost=|hostname|
oracle.sysman.eml.mntr.emdRepDBID=2067803468
oracle.sysman.emSDK.svlt.ConsoleServerHTTPSPort=1875
oracle.sysman.eml.mntr.emdRepSID=|SID|
oracle.sysman.eml.mntr.emdRepServer=|hostname|
oracle.sysman.emSDK.sec.ReuseLogonPassword=true
oracle.sysman.eml.mntr.emdRepConnectDescriptor=(DESCRIPTION\=(ADDRESS_LIST\=(ADDRESS\=(PROTOCOL\=TCP)(HOST\=|hostname|)(PORT\=1231)))(CONNECT_DATA\=(SERVICE_NAME\=|SID|)))
oracle.sysman.emkeyfile=$ORACLE_HOME/sysman/config/emkey.ora
oracle.sysman.eml.mntr.emdRepUser=SYSMAN
oracle.sysman.db.adm.conn.statementCacheSize=2
oracle.sysman.db.perf.conn.statementCacheSize=30

Mesmo depois de tê-lo recriado o Enterprise Manager não subia. Com um tail -f no emoms.log verifiquei que a conta SYSMAN estava lockada. Para desbloquear, então:

ALTER USER SYSMAN ACCOUNT UNLOCK;

E depois disso ainda o emoms.log indicava que o usuário ou a senha estava errado. Aí descobri que usar senhas que possuem alguns caracteres especiais pode ser um problema. Depois de conseguir finalmente mudar a senha para uma que o emoms.properties e que o Enterprise Manager aceite, finalmente o EM subiu. Para constar, para mudar a senha do SYSMAN:

SQL> ALTER USER SYSMAN IDENTIFIED BY |nova senha|;

[oracle@hostname admin]$ emctl setpasswd dbconsole

Agora sim o EM sobe!

sql*net more data from client

Reparei que a documentação e a quantidade de relatos a respeito de problemas com os wait events ‘SQL*Net More Data To Client‘ e ‘SQL*Net More Data From Client‘ é escassa.

Enfrentei problemas com o segundo caso, From Client, durante alguns dias. Não havia impacto aparente na aplicação, mas o gráfico incomodada e deixava o mistério no ar. Pesquisas a respeito disso resultavam em respostas vagas. Afinal, partia-se da premissa que era ou um problema de rede ou um problema em que a aplicação tinha muito o que enviar para o banco e ocorria algum problema no processo.

Verificando no EM eu chegava a uma query, um insert bem simples, sempre atrelada aos picos de rede. Talvez havia ocorrido alguma mudança na aplicação em que a inserção de dados no sentido aplicação – banco era atrasada? Pesquisa aqui, pesquisa ali, consulta tais e tais queries. Nada.

Vamos então verificar a rede. Será um gargalo?

No servidor da aplicação vou verificar a placa de rede. Configurada corretamente, estável no geral:

[root@aplicacao1 ~]# mii-tool eth0
eth0: negotiated 100baseTx-FD, link ok

Desconfiado, pesquiso uma alternativa ao mii-tool e acho a mais moderna e parruda ethtool. Resultados corretos, dessa vez, e condizentes com as portas do switch no qual os servidores estão conectados (output cortado para reduzir o tamanho):

[root@aplicacao1 ~]# ethtool eth0
Settings for eth0:
Advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Link detected: yes

Agora sim.

Daí então verifico como anda o tráfego em tempo real. Uso a ferramenta iftop para tal. Nela eu verifico que TX e RX estão acima de 90Mb/s mas não ultrapassam essa marca. Verifico então o servidor do banco:

[root@banco ~]# ethtool eth0
Settings for eth0:
Advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Link detected: yes

Ahá. Hora de trocar alguns cabos no switch. Colocando o banco na saída certa, uma 100/1000, pode-se verificar a mudança imediata:

[root@banco ~]# ethtool eth0 | grep Speed
Speed: 1000Mb/s

Perfeito. Com o iftop consigo ver que agora a aplicação supera os 100Mb/s mas não muito. Havia, enfim, um gargalo de rede com um teto causado pela porta 10/100 do switch do lado do banco.

Problema de SQL*Net More Data From Client resolvido!

Erro De Autenticação De BI

Surgiu um problema no servidor que roda BI e Datawarehouse Oracle, e lá fui eu aprender a mexer nisso. Segundo os logs, não era mais possível logar na ferramenta de BI, além de termos este erro retornando nos logs do BI:

An Exception is thrown: WSM-06162 The policy referenced by URI “oracle/wss_username_token_service_policy” could not be retrieved as connection to Policy Manager cannot be established at “t3://calisto:7001” due to invalid configuration or inactive state.

Acessando o Enterprise Manager (Fusion Middleware Control) através de http://host:port/em no próprio servidor, eu verifiquei que haviam dois serviços (ou aplicações) falhas: bipublisher e wsm-pm.

Pesquisando um pouco, achei a solução. Ou, pelo menos a solução para a minha configuração atual. O problema é causado por falha na autenticação do usuário dos serviços. E a solução se dá da seguinte forma.

Primeiramente deve-se certificar de qual usuário é utilizado pelo serviço (no caso exemplo, o serviço é o wsm-pm). Para tal, deve-se selecionar o serviço e ir para o console de administração do Weblogic:

Na nova tela devemos buscar a tela de gerenciamento do serviço. Neste caso, o meio mais rápido é primeiramente selecionando Serviços e em seguida Origem de Dados:

E em seguida, da lista de origens, selecionar o mds-owsm:

E finalmente selecionar a aba Pool de Conexões:

Nesta área verá-se configurado o usuário utilizado pelo serviço:

Agora deve-se verificar o status do usuário no banco:

 SELECT USERNAME, ACCOUNT_STATUS FROM DBA_USERS WHERE USERNAME='<usuário>’>;

 E verificando o estado de EXPIRED, deve-se “desexpirar” o usuário atribuindo uma nova senha a ele (podendo ser a senha anterior repetida):

 ALTER USER <usuário> IDENTIFIED BY ;

 Em seguida, voltando à tela inicial do EM, deve-se clicar com o botão esquerdo no serviço, selecionar Controle e finalmente em Inicializar:

Verifica-se então o status do serviço na tela inicial ou na tela do próprio. E pronto! Já é possível logar normalmente na ferramenta de BI da Oracle!

Shrink Tablespace

Desde que voltei a mexer no Enterprise Manager do 10g, eu comecei a notar as recomendações do Segment Advisor sobre as tablespaces, recomendações essas que sugerem reorganização ou encolhimento para liberação de espaço. No caso das tbsps do banco que uso, o SA apenas recomendou shrink. Agora, o que é isso?

Suponhamos que tenhamos uma tablespace USERS, com a tabela T e outras tabelas diversas X, além de espaços vazios f:

XXXXXTTTTTffXXfffff

Agora, se dropássemos a tabela T, teríamos a TBSP assim:

XXXXXfffffffXXfffff

Agora, o efeito do shrink é liberar mais espaço numa tablespace ajustando sua high water mark. E isso resulta, no fim, com uma TBSP assim:

XXXXXfffffffXX

Devo lembrar que a diferença entre os dois últimos cenários é que, no penúltimo, os espaços vazios ao final da tablespace, mesmo sendo vazios, estão alocados na tablespace USERS e são propriedade dela. Já no último cenário, aquele espaço vazio não está associado a uma tablespace, por ora.

Mas, e aquele espaço vazio no meio ta TBSP? Disso eu tento falar mais pra frente.

Agora, voltando ao shrink, você pode usá-lo através do Enterprise Manager (Segment Advisor Recommendations -> Recommendation Details for Tablespace) ou através de comando (ALTER SHRINK).

A documentação é bem completa sobre esse método, assim como há inúmeros blogs e afins que relatam as mais diversas formas de utilização do shrink, inclusive comparando-o a move, coalesce, reorg, etc.

Ainda não realmente utilizei o método, estou aguardando uma janela para isso, já que o shrink muito provavelmente irá gerar locks. Então, no futuro eu voltarei a postar sobre shrink, expandindo mais o assunto.