[oracle_br] Re: Perfis de acesso - Boas práticas
Sem dúvida, nos Clientes maiores e mais organizados, havia ** SIM ** um Documento formal registrando a solicitação e o Acesso concedido - normalmente nada era feito sem um pedido formal (GMUD, Gerência de Mudança) , onde constava o que deve ser feito, aonde, quem foi o Solicitante, quem oi o Aprovador (inclusive com um email de Aprovação) e quem foi o Beneficiado Futuramente, se fosse posto em dúvida algum privilégio, era só pesquisar as GMUDs que se localizava o histórico Isso funciona para qualquer tipo de acesso Caso a sua Empresa não disponha de um Aplicativo ITIL que permita GMUDs, Acompanhamento de Problems, e coisas do tipo, existem muitas Soluções para isso no mercado - via de regra é muito mais viável se adquirir uma delas do que desenvolver internamente... Tecnicamente falando, de boas práticas para gerenciamento de usuários e privilégios se pode citar : a. implementar política de verificação e duração de senhas - JAMAIS deixar um usuário ficar longo período sem trocar senhas, ou repetir a mesma senha b. fazer um levantamento de usuários do próprio database (como os de demos, os usuários donos de features como do Oracle Text, do AWR, etc, etc) e onde possível trocar a senha ou mesmo retirar o privilégio de conexão deles c. usar & abusar de ROLES : se vc tem um grupo de usuários que precisam dos mesmos privilégios, ao invés de manualmente vc dar cada privilégio pro ZEZINHO, o HUGUINHO, o LUIZINHO e não sei quem mais, o ** ideal ** é que vc crie uma ROLE, com um nome apropriado, dê os privilégios para a ROLE e associe a role para os usuários d. segurança a nível de colunas E de linhas : muitas vezes o pessoal esquece, mas nem todas as colunas e/ou todas as linhas de todas as tabelas que qualquer um deve acessar, então não basta para a Segurança e Controle dizer que quer SELECT na tabela X... O exemplo típico é, digamos, na tabela EMPREGADOS a coluna SALÁRIO : um funcionário de nível baixo só poderia ver a linha que corresponde a si mesmo, um gerente poderia ver a coluna SALARIO de todas as linhas que correspondam a funcionários do seu departamento, assim por diante... Isso se faz com uma combinaação de VIEWS, FGAC (Fine-Grained Access Control)/RLS (Row Level Security) e VPD (Virtual private database), com a eventual adição do OLS (Oracle Label Security) se vc o tiver acessível no database e. permissão MÍNIMA é a regra de ouro : vc TEM que sempre, sempre, sempre solicitar que os usuários responsáveis indiquem o conjunto ** mínimo ** de privilégios... É muito comum que, para não ter que pensar/analisar, neguim te peça SELECT ou UPDATE em todas as colunas em todas as tabelas, quando na verdade é só um sub-conjunto dos privs que Realmente eram necessários f. DELETE deve ser sempre alvo de política à parte , pois via de regra é uma operação mais difícil/custosa de ser desfeita no futuro g. Auditoria e Volta no tempo : vc TEM que ter ativo ao menos um nível mínimo de Auditoria, para que quando o pessoal te pedir vc tenha ao menos uma info mínima histórica para informar - isso pode implicar tanto em uso do comand AUDIT (que implica em espaço em disco para os audit records) quanto em ativação de Features como logminer (que implica em settings extras E em retenção de backup de archived redo logs), ficando os triggers (que tipicamente tem implicações em Performance) como uma terceira opção a ser usada com Extrema parcimônia Da mesma maneira, o database possui uma série de features para se recuperar uma informação apagada/alterada/inserida erroneamente (como os diversos FLASHBACKs) : avalie junto com os Responsáveis pelos dados o quanto isso seria desejável para o database, e em caso positivo qual o intervalo, sabendo-se que quanto maior o intervalo mais espaço em disco/recursos podem ser consumidos []s Chiappa
Re: [oracle_br] Re: Alert Oracle
Opa, seguem minhas obs abaixo de cada resposta : > >- ok, não há firewall NOS SERVIDORES, mas tem certeza que não há nenhum >envolvido na rota de >comunicação ??? O IP cliente reportado no erro de rede >no alert.log, era do servidor de aplicação ?? E >quanto a softwares de >controle de rede/segurança/filtros de pacotes/software de QOS ou controle de >>banda de rede, TEM CERTEZA que não há nada assim que possa estar >influenciando ?? > Resposta: Sim nao ha firewall, confirmei com o responsavel pela rede. ok, mas quando vc perguntou de FIREWALL, vc Também checou/perguntou por "softwares de controle de rede/segurança/filtros de pacotes/software de QOS ou controle de banda de rede", como eu disse ?? Pois esse pessoal de rede é meio binário, se vc pergunta só por firewall, é só isso que eles te respondem >- antes de tentar reproduzir, vc *** CONSULTOU *** os logs TODINHOS que >indiquei (ie, log do >listener, log do switch/roteador, do DNS, eventuais >tracefiles gerados na máquina-cliente, na >servidora de apps e/ou no RDBMS >server, etc) ?? Sem isso fica ** EXTREMAMENTE DIFÍCIL ** a gente >culpabilizar >pelo erro o próprio servidor que foi trocado (talvez por uma placa de rede >defeituosa, sei >lá) OU a rede em sim, que afaik pra mim ainda não está livre >de culpa, não > >Resposta: listener.log e o alert.log - em relação ao switch/roteador, a >aplicação e interna e ainda nao >solicitei. SIM, faça isso o quanto antes, até porque via de regras tais logs são reciclados rapidamente, às vezes diariamente... E não esqueça, como eu disse, de TAMBÉM checar na máquina cliente por eventuais tracefiles (muitas vezes quando o client Oracle recebe erro de rede ele grava um logfile ou tracefile), E como eu disse Também eventuais logs nas outras camadas de rede, como DNS por exemplo... Não esqueça dos logs DOS SERVIDORES (como dmesg e quetais, veja com os seus sysadmins), pois é lá que vc vai encontrar eventualmente alguma msg referente à falha local (digamos, placa de rede, etc)... => Sobre o pool , acho que não basta só dizer "o do JBOSS" : para que vc receba uma indicação melhor de quem o usa, plz obtenha a VERSÃO EXATA e o método de implementação usado, bem como a Configuração... mas de cara, se é um pool EXTERNO ao database, posso dizer que a view indicada pelo Suporte Oracle não toca APITO NENHUM, e eles estão fora da pista correta... []s Chiappa OBS : recomendo de novo , se a Investigação não encontrar um Culpado claro, PENSE SERIAMENTE numa solução de monitoramento do ambiente, okdoc ?? Não duvido nada se o Suporte da Oracle mesmo não indicar o OSWATCHER se não conseguir chegar ao culpado... === Em Quarta-feira, 8 de Abril de 2015 14:19, "jlchia...@yahoo.com.br [oracle_br]" escreveu: Então : - ok, não há firewall NOS SERVIDORES, mas tem certeza que não há nenhum envolvido na rota de comunicação ??? O IP cliente reportado no erro de rede no alert.log, era do servidor de aplicação ?? E quanto a softwares de controle de rede/segurança/filtros de pacotes/software de QOS ou controle de banda de rede, TEM CERTEZA que não há nada assim que possa estar influenciando ?? - antes de tentar reproduzir, vc *** CONSULTOU *** os logs TODINHOS que indiquei (ie, log do listener, log do switch/roteador, do DNS, eventuais tracefiles gerados na máquina-cliente, na servidora de apps e/ou no RDBMS server, etc) ?? Sem isso fica ** EXTREMAMENTE DIFÍCIL ** a gente culpabilizar pelo erro o próprio servidor que foi trocado (talvez por uma placa de rede defeituosa, sei lá) OU a rede em sim, que afaik pra mim ainda não está livre de culpa, não - vc diz que "utiliza pool de conexões" : tá, mas QUAL doas trocentas soluções de pooling a aplicação usa ??? Pois essa view DBA_CPOOL_INFO serve apenas para indicar/controlar status e detalhes da solução de pool embutida no database Oracle (a Oracle Database Resident Connection Pools), é essa que vc usa ??? Se for então sim, afaik o STATUS deveria estar ATIVO, isso pode indicar problemas, MAS se na verdade a aplicação usa OUTRA solução de pool, EXTERNA ao database, ÓBVIO que a view passa a ser IRRELEVANTE, okdoc ? Plz Obtenha a info correta com o pessoal da Aplicação, INCLUINDO além do nome a versão exata e a configuração da talzinha ... ==> Com essa info na mão, quem usa a mesma solução de POOL vai poder te indicar onde ficam os logs/tracefiles do pool, que podem ser ainda outra pista pra sua investigação... []s Chiappa OBS : se nenhum dos logs e/ou tracefiles indicar nada, e a Investigação do pessoal de rede não indicar nada, para se preparar para futuras ocorrências e/ou tentar comprovar que o ambiente está OK, vc aí então pode implementar alguma solução de monitoração de ambiente, para comprovar que não há erros intermitentes ou de muito pequena duração passando despercebidos E que a rede/cpu/memória/discos estão apresentando performance geral normal - uma solução gratuita para isso d
[oracle_br] Perfis de acesso - Boas práticas
Boa tarde senhores Estamos ajustando políticas de segurança em nosso banco de dados. No modelo atual, temos um usuário do banco de dados, com papel Grants para modificar dados. Estamos montando perfis para execução apenas de consultas. Quando é criado um usuário de banco, qual a política adotada pelos senhores? Existe o preenchimento de algum documento de responsabilidade? Quais são as boas práticas no caso de usuários mais avançados que queiram executar update, insert, etc etc Obrigado como sempre Atenciosamente Rafael Gustavo Gaspar da Silva.
Re: [oracle_br] Re: Alert Oracle
Bem
- ok, não há firewall NOS SERVIDORES, mas tem certeza que não há nenhum
envolvido na rota de comunicação ??? O IP cliente reportado no erro de rede no
alert.log, era do servidor de aplicação ?? E quanto a softwares de controle de
rede/segurança/filtros de pacotes/software de QOS ou controle de banda de rede,
TEM CERTEZA que não há nada assim que possa estar influenciando ??
Resposta: Sim nao ha firewall, confirmei com o responsavel pela rede.
- antes de tentar reproduzir, vc *** CONSULTOU *** os logs TODINHOS que
indiquei (ie, log do listener, log do switch/roteador, do DNS, eventuais
tracefiles gerados na máquina-cliente, na servidora de apps e/ou no RDBMS
server, etc) ?? Sem isso fica ** EXTREMAMENTE DIFÍCIL ** a gente culpabilizar
pelo erro o próprio servidor que foi trocado (talvez por uma placa de rede
defeituosa, sei lá) OU a rede em sim, que afaik pra mim ainda não está livre de
culpa, não
Resposta: listener.log e o alert.log - em relação ao switch/roteador, a
aplicação e interna e ainda nao solicitei.
- vc diz que "utiliza pool de conexões" : tá, mas QUAL doas trocentas soluções
de pooling a aplicação usa ??? Pois essa view DBA_CPOOL_INFO serve apenas para
indicar/controlar status e detalhes da solução de pool embutida no database
Oracle (a Oracle Database Resident Connection Pools), é essa que vc usa ??? Se
for então sim, afaik o STATUS deveria estar ATIVO, isso pode indicar problemas,
MAS se na verdade a aplicação usa OUTRA solução de pool, EXTERNA ao database,
ÓBVIO que a view passa a ser IRRELEVANTE, okdoc ? Plz Obtenha a info correta
com o pessoal da Aplicação, INCLUINDO além do nome a versão exata e a
configuração da talzinha ...
Resposta: Em relação ao pool ja sei que eles utilizam o do JBOSS
pools>
==> Com essa info na mão, quem usa a mesma solução de POOL vai poder te indicar
onde ficam os logs/tracefiles do pool, que podem ser ainda outra pista pra sua
investigação...
Vou verificar este item tambem. Atenciosamente,
André Luiz R. Marques
Administrador de Banco de Dados - SQL Server/OracleTel: (21) 99978-4564 Evite
imprimir. Colabore com o Meio Ambiente! "Embora ninguém possa voltar atrás e
fazer um novo começo, qualquer um pode
começar agora e fazer um novo fim." Chico Xavier
Em Quarta-feira, 8 de Abril de 2015 14:19, "jlchia...@yahoo.com.br
[oracle_br]" escreveu:
Então :
- ok, não há firewall NOS SERVIDORES, mas tem certeza que não há nenhum
envolvido na rota de comunicação ??? O IP cliente reportado no erro de rede no
alert.log, era do servidor de aplicação ?? E quanto a softwares de controle de
rede/segurança/filtros de pacotes/software de QOS ou controle de banda de rede,
TEM CERTEZA que não há nada assim que possa estar influenciando ??
- antes de tentar reproduzir, vc *** CONSULTOU *** os logs TODINHOS que
indiquei (ie, log do listener, log do switch/roteador, do DNS, eventuais
tracefiles gerados na máquina-cliente, na servidora de apps e/ou no RDBMS
server, etc) ?? Sem isso fica ** EXTREMAMENTE DIFÍCIL ** a gente culpabilizar
pelo erro o próprio servidor que foi trocado (talvez por uma placa de rede
defeituosa, sei lá) OU a rede em sim, que afaik pra mim ainda não está livre de
culpa, não
- vc diz que "utiliza pool de conexões" : tá, mas QUAL doas trocentas soluções
de pooling a aplicação usa ??? Pois essa view DBA_CPOOL_INFO serve apenas para
indicar/controlar status e detalhes da solução de pool embutida no database
Oracle (a Oracle Database Resident Connection Pools), é essa que vc usa ??? Se
for então sim, afaik o STATUS deveria estar ATIVO, isso pode indicar problemas,
MAS se na verdade a aplicação usa OUTRA solução de pool, EXTERNA ao database,
ÓBVIO que a view passa a ser IRRELEVANTE, okdoc ? Plz Obtenha a info correta
com o pessoal da Aplicação, INCLUINDO além do nome a versão exata e a
configuração da talzinha ...
==> Com essa info na mão, quem usa a mesma solução de POOL vai poder te indicar
onde ficam os logs/tracefiles do pool, que podem ser ainda outra pista pra sua
investigação...
[]s
Chiappa
OBS : se nenhum dos logs e/ou tracefiles indicar nada, e a Investigação do
pessoal de rede não indicar nada, para se preparar para futuras ocorrências
e/ou tentar comprovar que o ambiente está OK, vc aí então pode implementar
alguma solução de monitoração de ambiente, para comprovar que não há erros
intermitentes ou de muito pequena duração passando despercebidos E que a
rede/cpu/memória/discos estão apresentando performance geral normal - uma
solução gratuita para isso da própria Oracle é o ORACLE OSWATCHER BLACKBOX,
pesquise por ele no metalink... #yiv5117351020 #yiv5117351020 --
#yiv5117351020ygrp-mkp {border:1px solid #d8d8d8;font-family:Arial;margin:10px
0;padding:0 10px;}#yiv5117351020 #yiv5117351020ygrp-mkp hr {border:1px solid
#d8d8d8;}#yiv5117351020 #yiv5117351020ygrp-mkp #yiv5117351020hd
{color:#628c2a;font-size:8
Re: [oracle_br] Re: Alert Oracle
Então : - ok, não há firewall NOS SERVIDORES, mas tem certeza que não há nenhum envolvido na rota de comunicação ??? O IP cliente reportado no erro de rede no alert.log, era do servidor de aplicação ?? E quanto a softwares de controle de rede/segurança/filtros de pacotes/software de QOS ou controle de banda de rede, TEM CERTEZA que não há nada assim que possa estar influenciando ?? - antes de tentar reproduzir, vc *** CONSULTOU *** os logs TODINHOS que indiquei (ie, log do listener, log do switch/roteador, do DNS, eventuais tracefiles gerados na máquina-cliente, na servidora de apps e/ou no RDBMS server, etc) ?? Sem isso fica ** EXTREMAMENTE DIFÍCIL ** a gente culpabilizar pelo erro o próprio servidor que foi trocado (talvez por uma placa de rede defeituosa, sei lá) OU a rede em sim, que afaik pra mim ainda não está livre de culpa, não - vc diz que "utiliza pool de conexões" : tá, mas QUAL doas trocentas soluções de pooling a aplicação usa ??? Pois essa view DBA_CPOOL_INFO serve apenas para indicar/controlar status e detalhes da solução de pool embutida no database Oracle (a Oracle Database Resident Connection Pools), é essa que vc usa ??? Se for então sim, afaik o STATUS deveria estar ATIVO, isso pode indicar problemas, MAS se na verdade a aplicação usa OUTRA solução de pool, EXTERNA ao database, ÓBVIO que a view passa a ser IRRELEVANTE, okdoc ? Plz Obtenha a info correta com o pessoal da Aplicação, INCLUINDO além do nome a versão exata e a configuração da talzinha ... ==> Com essa info na mão, quem usa a mesma solução de POOL vai poder te indicar onde ficam os logs/tracefiles do pool, que podem ser ainda outra pista pra sua investigação... []s Chiappa OBS : se nenhum dos logs e/ou tracefiles indicar nada, e a Investigação do pessoal de rede não indicar nada, para se preparar para futuras ocorrências e/ou tentar comprovar que o ambiente está OK, vc aí então pode implementar alguma solução de monitoração de ambiente, para comprovar que não há erros intermitentes ou de muito pequena duração passando despercebidos E que a rede/cpu/memória/discos estão apresentando performance geral normal - uma solução gratuita para isso da própria Oracle é o ORACLE OSWATCHER BLACKBOX, pesquise por ele no metalink...
Re: [oracle_br] Re: Alert Oracle
Bom dia a todos,
Obrigado pela orientação. Vamos lá.
- Ontem solicitei ajuda ao pessoal de rede - Estava ok, Nao ha firewall nos
servidores envolvidos;- O que tudo indica e o servidor de aplicação ter
solicitado a requisição e como houve demora o pool de conexões retornou timout-
Abri um chamado na Oracle e me orientaram a rodar a seguinte consulta
select * from dba_cpool_info; )));- o resultado da consulta foi que a coluna:
select status, connection_pool, session_cached_cursors from dba_cpool_info;
STATUS CONNECTION_POOL
SESSION_CACHED_CURSORS
-- INACTIVE SYS_DEFAULT_CONNECTION_POOL
20
A aplicação foi feita em java, e utiliza pool de conexões. Saberiam me informar
se o status deve estar ativo?
Atenciosamente,
André Luiz R. Marques
Administrador de Banco de Dados - SQL Server/OracleTel: (21) 99978-4564 Evite
imprimir. Colabore com o Meio Ambiente! "Embora ninguém possa voltar atrás e
fazer um novo começo, qualquer um pode
começar agora e fazer um novo fim." Chico Xavier
Em Terça-feira, 7 de Abril de 2015 21:20, "jlchia...@yahoo.com.br
[oracle_br]" escreveu:
Opa : então, na verdade nada impede que haja firewall na rede interna
mesmo, entre uma máquina-cliente e o servidor Oracle : não deveria mas vai se
saber
E é claro : até pode acontecer algum problema no listener (até por isso
Recomendei que o colega olhasse os logs dele, entre outros), mas acho **
difícil ** o listener ficar sem responder e depois voltar - já vi muitas vezes
listener crashar (principalmente por bugs) , ou então parar de atender
(principalmente naquelas situações de log do listener chegando num limite do
SO, por exemplo), mas normalmente sempre que coisas assim ocorreram ele parou
de vez : isso de ficar sem conexão por um período e de repente, sem ação (ao
que entendi) voltar, aponta imho ** fortemente ** para problema externo, de
Rede mesmo, ou de alguém/algo cortando a conexão...
Só quando o colega lá fizer os levantamentos TODOS que indiquei é que vamos
ficar sabendo de detalhes
[]s
Chiappa
OBS : igualmente, acho difícil acreditar em queda e restart automático do banco
principalmente dada a ausência de entrada indicando o start do database no
alert.log, cfrme relatado pelo colega que fez a pergunta - até pode haver
chance de bug que cause isso mas acho bem difícil... #yiv2479136545
#yiv2479136545 -- #yiv2479136545ygrp-mkp {border:1px solid
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv2479136545
#yiv2479136545ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv2479136545
#yiv2479136545ygrp-mkp #yiv2479136545hd
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px
0;}#yiv2479136545 #yiv2479136545ygrp-mkp #yiv2479136545ads
{margin-bottom:10px;}#yiv2479136545 #yiv2479136545ygrp-mkp .yiv2479136545ad
{padding:0 0;}#yiv2479136545 #yiv2479136545ygrp-mkp .yiv2479136545ad p
{margin:0;}#yiv2479136545 #yiv2479136545ygrp-mkp .yiv2479136545ad a
{color:#ff;text-decoration:none;}#yiv2479136545 #yiv2479136545ygrp-sponsor
#yiv2479136545ygrp-lc {font-family:Arial;}#yiv2479136545
#yiv2479136545ygrp-sponsor #yiv2479136545ygrp-lc #yiv2479136545hd {margin:10px
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv2479136545
#yiv2479136545ygrp-sponsor #yiv2479136545ygrp-lc .yiv2479136545ad
{margin-bottom:10px;padding:0 0;}#yiv2479136545 #yiv2479136545actions
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv2479136545
#yiv2479136545activity
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv2479136545
#yiv2479136545activity span {font-weight:700;}#yiv2479136545
#yiv2479136545activity span:first-child
{text-transform:uppercase;}#yiv2479136545 #yiv2479136545activity span a
{color:#5085b6;text-decoration:none;}#yiv2479136545 #yiv2479136545activity span
span {color:#ff7900;}#yiv2479136545 #yiv2479136545activity span
.yiv2479136545underline {text-decoration:underline;}#yiv2479136545
.yiv2479136545attach
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px
0;width:400px;}#yiv2479136545 .yiv2479136545attach div a
{text-decoration:none;}#yiv2479136545 .yiv2479136545attach img
{border:none;padding-right:5px;}#yiv2479136545 .yiv2479136545attach label
{display:block;margin-bottom:5px;}#yiv2479136545 .yiv2479136545attach label a
{text-decoration:none;}#yiv2479136545 blockquote {margin:0 0 0
4px;}#yiv2479136545 .yiv2479136545bold
{font-family:Arial;font-size:13px;font-weight:700;}#yiv2479136545
.yiv2479136545bold a {text-decoration:none;}#yiv2479136545 dd.yiv2479136545last
p a {font-family:Verdana;font-weight:700;}#yiv2479136545 dd.yiv2479136545last p
span {margin-ri
RES: RES: [oracle_br] *** ORA-12514 ***
Bom dia pessoal. Chiappa, desculpe a demora no retorno, pois, na data que enviei o problema, o cliente acabou disponibilizando outro servidor que funcionou normalmente, e entre esse meio tempo estava tentando “simular o problema” em ambiente local para verificar essas informações passadas abaixo, porém, não consegui reproduzir o problema. De qualquer forma, vou ainda tentar simular esse caso, para testar esses pontos e ter a solução caso volte a ocorrer o problema. Obrigado novamente pelo retorno. At, Robson De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Enviada em: segunda-feira, 30 de março de 2015 23:45 Para: oracle_br@yahoogrupos.com.br Assunto: Re: RES: [oracle_br] *** ORA-12514 *** Tudo jóia ? Então, pra iniciar, vc mostrou : conn system\syssestini@nfeweb essa sintaxe que vc usou não é a correta, para se separar usuário e senha vc usa a barra NORMAL e NÂO a contra-barra, deveria estar escrito : conn system/syssestini@nfeweb okdoc ??? Plz tenta da forma correta... Se não for isso, a primeira obs que faço é a seguinte : o TNSPING só testa acesso ao LISTENER, enviando um 'ping' (ie, um pequeno pacote de rede) para a porta do listener, só isso - ele NÂO conecta no database, NÃO testa portanto se o database está disponível Assim, por uma questão de método, vamos testar o acesso LOCAL ao database antes de tudo... Isso se faz logando nesse servidor como o MESMO usuário admin local que instalou e (creio) executa o RDBMS, aí então abrindo um prompt de comandos, confirmando que o service Windows do database está up, setando as variáveis de ambiente Oracle e tentando a conexão SEM informar @hoststring Exemplo (substitua o NOME e ORACLE_HOME do exemplo pelos seus, E supondo sempre que é banco single-instance/não-RAC, E que não usa ASM, E QUE portanto vc vai usar o mesmo listener presente na HOME do banco) : => meu database se chama XE, então tenho que ter um serviço Windows chamado OracleServiceXE ativo : C:\Windows\system32>sc queryex OracleServiceXE => veja no resultado que tenho : NOME_DO_SERVIÇO: OracleServiceXE TIPO : 10 WIN32_OWN_PROCESS ESTADO : 4 RUNNING (STOPPABLE, PAUSABLE, ACCEPTS_SHUTDOWN) CÓDIGO_DE_SAÍDA_DO_WIN32 : 0 (0x0) CÓDIGO_DE_SAÍDA_DO_SERVIÇO : 0 (0x0) PONTO_DE_VERIFICAÇÃO : 0x0 AGUARDAR_DICA : 0x0 PID: 2652 SINALIZADORES : C:\Windows\system32> => ok, preciso setar o ORACLE_SID, o ID do database a se conectar : C:\Windows\system32>set ORACLE_SID=XE => instalei esse RDBMS em c:\oraclexe\app\oracle\product\11.2.0\server , então seto o valor adequado para a HOME : C:\Windows\system32>set ORACLE_HOME=c:\oraclexe\app\oracle\product\11.2.0\server => indico que os binários estão no sub-diretório BIN dessa ORACLE_HOME : C:\Windows\system32>set PATH=%ORACLE_HOME%\bin;%PATH% => ok, agora a conexão local (SEM listener) totalmente TEM que funcionar, PROVANDO (agora sim) que o banco está acessível mesmo : C:\Windows\system32>sqlplus system/oracle SQL*Plus: Release 11.2.0.2.0 Production Copyright (c) 1982, 2014, Oracle. All rights reserved. Conectado a: Oracle Database 11g Express Edition Release 11.2.0.2.0 - 64bit Production SQL> => blz ?? Saia do sqlplus com o comando EXIT e vamos agora ver o LISTENER... Julgando pelo seu listener.ora, eu vejo que o listener que vc criou se chama LISTENER mesmo, então não precisarei indicar o nome do listener nos comandos de verificação Para se verificar o listener, nesse mesmo prompt de comando anteriormente usado, já com ORACLE_HOME e PATH corretamente setados, vc usa o comando LSNRCTL STATUS, assim : C:\Windows\system32>lsnrctl status => o resultado vais er algo do tipo : LSNRCTL for 64-bit Windows: Version 11.2.0.2.0 - Production STATUS do LISTENER Apelido LISTENER VersÒoTNSLSNR for 64-bit Windows: Version 11.2.0.2.0 - Produ ction Data Inicial 30-MAR-2015 23:05:58 Funcionamento 0 dias 0 hr. 31 min. 6 seg NÝvel de Anßlise off Seguranþa ON: Local OS Authentication SNMP OFF Serviþo Default XE Arq. ParÔm. Listn.C:\oraclexe\app\oracle\product\11.2.0\server\network\admin \listener.ora Arq. Log ListenerC:\oraclexe\app\oracle\diag\tnslsnr\noteDell\listener\alert \log.xml Resumo de Atendimento... (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(PIPENAME=\\.\pipe\EXTPROC1ipc))) (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=noteDell)(PORT=1521))) (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=noteDell)(PORT=8080))(Presentation=H TTP)(Session=RAW)) Resumo de Serviþos... O serviþo "CLRExtProc" tem 1 instÔncia(s). InstÔncia "CLRExtProc", status UNKNOWN, tem 1 handler(s) para este serviþo... O serviþo "PLSExtProc" tem 1 instÔncia(s). InstÔncia "PLSEx
