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!