Re: [oracle_br] DBSNMP obrigatorio?

2016-02-04 Por tôpico Roland Martins dadim...@yahoo.com.br [oracle_br] 
A situação é semelhante:1 target (que é o ambiente de produção, RAC de 4 nós, 
versão 12.1.0.2, sim Banco 12cR1)2 EM12c (o deles e o nosso, em servidores 
standalone no mesmo data center que o target) ... cada EM12c tem seu sysman, 
óbvio.
Mas ao se conectarem ao target, usam DBSNMP ... aí temos o conflito ... ambos 
EM12c precisam usar o mesmo usuário de banco (DBSNMP) no target ?  

Em Quinta-feira, 4 de Fevereiro de 2016 19:20, "Luis Freitas 
lfreita...@yahoo.com [oracle_br]"  escreveu:
 

     Dadim,
  Acho que você está confundindo DBSNMP com SYSMAN.
 No EM 12c (ou 11g...), o esquema SYSMAN fica no repositorio do EM, mas o 
DBSNMP é parte do catalogo dos respectivos bancos de dados.
   Então se você tem dois EM 12c, o que acontece é que você tem dois esquemas 
SYSMAN, um em cada base repositorio do EM, mas nos "targets", tem só um DBSNMP 
mesmo.
   É comum ter essa situação quando se usa o EM com o Exadata, pois o servidor 
do "Platinum" tem um EM, mas que é exclusivo para o suporte da Oracle, então o 
cliente tem que instalar um segundo EM separado se quiser usar.
Atc,Luis Freitas 

On Thursday, February 4, 2016 8:56 AM, "dadim...@yahoo.com.br [oracle_br]" 
 wrote:
 

     Suponhamos que minha empresa tem um contrato com outra, que usa o EM12c 
para monitorar 1 determinado target (produção, super-crítico, 24x7, etc).Agora 
suponhamos que minha empresa comprou o EM12c e quer monitorar o mesmo target 
(inclusive banco de dados 24x7, supercrítico).É possível monitorar um banco com 
outro usuário, que não o DBSNMP? Ou o EM12c é amarrado neste usuário ?Obrigado 
pelas respostas!  

 #yiv5770992327 #yiv5770992327 -- #yiv5770992327ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv5770992327 
#yiv5770992327ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv5770992327 
#yiv5770992327ygrp-mkp #yiv5770992327hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv5770992327 #yiv5770992327ygrp-mkp #yiv5770992327ads 
{margin-bottom:10px;}#yiv5770992327 #yiv5770992327ygrp-mkp .yiv5770992327ad 
{padding:0 0;}#yiv5770992327 #yiv5770992327ygrp-mkp .yiv5770992327ad p 
{margin:0;}#yiv5770992327 #yiv5770992327ygrp-mkp .yiv5770992327ad a 
{color:#ff;text-decoration:none;}#yiv5770992327 #yiv5770992327ygrp-sponsor 
#yiv5770992327ygrp-lc {font-family:Arial;}#yiv5770992327 
#yiv5770992327ygrp-sponsor #yiv5770992327ygrp-lc #yiv5770992327hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv5770992327 
#yiv5770992327ygrp-sponsor #yiv5770992327ygrp-lc .yiv5770992327ad 
{margin-bottom:10px;padding:0 0;}#yiv5770992327 #yiv5770992327actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv5770992327 
#yiv5770992327activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv5770992327
 #yiv5770992327activity span {font-weight:700;}#yiv5770992327 
#yiv5770992327activity span:first-child 
{text-transform:uppercase;}#yiv5770992327 #yiv5770992327activity span a 
{color:#5085b6;text-decoration:none;}#yiv5770992327 #yiv5770992327activity span 
span {color:#ff7900;}#yiv5770992327 #yiv5770992327activity span 
.yiv5770992327underline {text-decoration:underline;}#yiv5770992327 
.yiv5770992327attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv5770992327 .yiv5770992327attach div a 
{text-decoration:none;}#yiv5770992327 .yiv5770992327attach img 
{border:none;padding-right:5px;}#yiv5770992327 .yiv5770992327attach label 
{display:block;margin-bottom:5px;}#yiv5770992327 .yiv5770992327attach label a 
{text-decoration:none;}#yiv5770992327 blockquote {margin:0 0 0 
4px;}#yiv5770992327 .yiv5770992327bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv5770992327 
.yiv5770992327bold a {text-decoration:none;}#yiv5770992327 dd.yiv5770992327last 
p a {font-family:Verdana;font-weight:700;}#yiv5770992327 dd.yiv5770992327last p 
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv5770992327 
dd.yiv5770992327last p span.yiv5770992327yshortcuts 
{margin-right:0;}#yiv5770992327 div.yiv5770992327attach-table div div a 
{text-decoration:none;}#yiv5770992327 div.yiv5770992327attach-table 
{width:400px;}#yiv5770992327 div.yiv5770992327file-title a, #yiv5770992327 
div.yiv5770992327file-title a:active, #yiv5770992327 
div.yiv5770992327file-title a:hover, #yiv5770992327 div.yiv5770992327file-title 
a:visited {text-decoration:none;}#yiv5770992327 div.yiv5770992327photo-title a, 
#yiv5770992327 div.yiv5770992327photo-title a:active, #yiv5770992327 
div.yiv5770992327photo-title a:hover, #yiv5770992327 
div.yiv5770992327photo-title a:visited {text-decoration:none;}#yiv5770992327 
div#yiv5770992327ygrp-mlmsg #yiv5770992327ygrp-msg p a 
span.yiv5770992327yshortcuts 
{font-family:Verdana;font-size:10px;font-weight:normal;}#yiv5770992327 
.yiv5770992327green {color:#628c2a;}#yiv5770992327 .yiv5770992327MsoNormal 
{margin:0 0 0 0;}#yiv5770992327 o {font-size:0;}#yiv57

Re: [oracle_br] Privilégio insuficiente

2016-02-04 Por tôpico 'Fernando Franquini 'capin'' fernando.franqu...@gmail.com [oracle_br] 
Acho que se fizer com os usuários vais ver aonde está o problema
Em 04/02/2016 18:43, "Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]" <
oracle_br@yahoogrupos.com.br> escreveu:

>
>
> Como sys.
>
>
> Em Quinta-feira, 4 de Fevereiro de 2016 17:18, "'Fernando Franquini
> 'capin'' fernando.franqu...@gmail.com [oracle_br]" <
> oracle_br@yahoogrupos.com.br> escreveu:
>
>
>
> Estou na rua, se não conseguir mais a noite tento fazer aqui.
> Você está dando permissão como System ou como owner dos objetos?
>
> Em quinta-feira, 4 de fevereiro de 2016, Rafael Mendonca
> raffaell.t...@yahoo.com [oracle_br] 
> escreveu:
>
>
>
> Fernando exatamente. Se não a view nem compilada ficaria, o usuário PACK
> já possui privilégio as tabelas do schema TELEVISAO.
>
> Ainda está dando erro, muito estranho, acho que meu cérebro não está
> conseguindo mais raciocionar.
>
> :(
>
>
> Em Quinta-feira, 4 de Fevereiro de 2016 16:50, "'Fernando Franquini
> 'capin'' fernando.franqu...@gmail.com [oracle_br]" <
> oracle_br@yahoogrupos.com.br> escreveu:
>
>
>
> Usuario pack precisa também acesso as tabelas da televisão.
>
> 2016-02-04 17:44 GMT-02:00 Rafael Mendonca raffaell.t...@yahoo.com
> [oracle_br] :
>
>
>
> Oracle 11.2.0.4
>
>
> Usuário XUXA deve realizar uma consulta em uma view do usuário PACK.
>
> Essa view(simples) do schema PACK possui uma consulta em 2 tabelas do
> schema TELEVISAO.
>
>
> Para que o usuário XUXA consiga realizar uma consulta na view PACK
> realizei os seguintes grants:
>
>
> GRANT SELECT ON PACK.view to XUXA;
>
> GRANT SELECT ON TELEVISAO.TABELA1 to XUXA;
> GRANT SELECT ON TELEVISAO.TEBELA2 to XUXA;
>
>
> Não existe nenhum sinônimo/outro objeto com o mesmo nome da VIEW.
>
> Acontece que quando o usuário XUXA faz uma consulta na VIEW do schema PACK
> ainda me gera o erro de privilégio insuficiente.
>
>
> Mas quando pego a consulta da view e rodo por fora com usuário XUXA a
> consulta é me retornada.
>
> Alguém teria alguma idéia do que possa estar acontecendo?
>
>
>
>
>
>
>
>
> --
> Capin
> Graduado: Bacharel em Ciências da Computação - UFSC
> Analista de Sistemas e de Banco de Dados / DBA
> 48.9924.8212 Vivo - Florianópolis - SC - Brasil
> 
> http://certificacaobd.com.br/
> http://br.linkedin.com/in/capin
>
>
>
>
>
>
>
> --
> Capin
> Graduado: Bacharel em Ciências da Computação - UFSC
> Analista de Sistemas e de Banco de Dados / DBA
> 48.9924.8212 Vivo - Florianópolis - SC - Brasil
> 
> http://certificacaobd.com.br/
> http://br.linkedin.com/in/capin
>
>
>
>
>
>
> 
>

Re: [oracle_br] DBSNMP obrigatorio?

2016-02-04 Por tôpico Luis Freitas lfreita...@yahoo.com [oracle_br] 
Dadim,
  Acho que você está confundindo DBSNMP com SYSMAN.
 No EM 12c (ou 11g...), o esquema SYSMAN fica no repositorio do EM, mas o 
DBSNMP é parte do catalogo dos respectivos bancos de dados.
   Então se você tem dois EM 12c, o que acontece é que você tem dois esquemas 
SYSMAN, um em cada base repositorio do EM, mas nos "targets", tem só um DBSNMP 
mesmo.
   É comum ter essa situação quando se usa o EM com o Exadata, pois o servidor 
do "Platinum" tem um EM, mas que é exclusivo para o suporte da Oracle, então o 
cliente tem que instalar um segundo EM separado se quiser usar.
Atc,Luis Freitas 

On Thursday, February 4, 2016 8:56 AM, "dadim...@yahoo.com.br [oracle_br]" 
 wrote:
 

     Suponhamos que minha empresa tem um contrato com outra, que usa o EM12c 
para monitorar 1 determinado target (produção, super-crítico, 24x7, etc).Agora 
suponhamos que minha empresa comprou o EM12c e quer monitorar o mesmo target 
(inclusive banco de dados 24x7, supercrítico).É possível monitorar um banco com 
outro usuário, que não o DBSNMP? Ou o EM12c é amarrado neste usuário ?Obrigado 
pelas respostas!  #yiv7328513939 #yiv7328513939 -- #yiv7328513939ygrp-mkp 
{border:1px solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 
10px;}#yiv7328513939 #yiv7328513939ygrp-mkp hr {border:1px solid 
#d8d8d8;}#yiv7328513939 #yiv7328513939ygrp-mkp #yiv7328513939hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv7328513939 #yiv7328513939ygrp-mkp #yiv7328513939ads 
{margin-bottom:10px;}#yiv7328513939 #yiv7328513939ygrp-mkp .yiv7328513939ad 
{padding:0 0;}#yiv7328513939 #yiv7328513939ygrp-mkp .yiv7328513939ad p 
{margin:0;}#yiv7328513939 #yiv7328513939ygrp-mkp .yiv7328513939ad a 
{color:#ff;text-decoration:none;}#yiv7328513939 #yiv7328513939ygrp-sponsor 
#yiv7328513939ygrp-lc {font-family:Arial;}#yiv7328513939 
#yiv7328513939ygrp-sponsor #yiv7328513939ygrp-lc #yiv7328513939hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv7328513939 
#yiv7328513939ygrp-sponsor #yiv7328513939ygrp-lc .yiv7328513939ad 
{margin-bottom:10px;padding:0 0;}#yiv7328513939 #yiv7328513939actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv7328513939 
#yiv7328513939activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv7328513939
 #yiv7328513939activity span {font-weight:700;}#yiv7328513939 
#yiv7328513939activity span:first-child 
{text-transform:uppercase;}#yiv7328513939 #yiv7328513939activity span a 
{color:#5085b6;text-decoration:none;}#yiv7328513939 #yiv7328513939activity span 
span {color:#ff7900;}#yiv7328513939 #yiv7328513939activity span 
.yiv7328513939underline {text-decoration:underline;}#yiv7328513939 
.yiv7328513939attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv7328513939 .yiv7328513939attach div a 
{text-decoration:none;}#yiv7328513939 .yiv7328513939attach img 
{border:none;padding-right:5px;}#yiv7328513939 .yiv7328513939attach label 
{display:block;margin-bottom:5px;}#yiv7328513939 .yiv7328513939attach label a 
{text-decoration:none;}#yiv7328513939 blockquote {margin:0 0 0 
4px;}#yiv7328513939 .yiv7328513939bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv7328513939 
.yiv7328513939bold a {text-decoration:none;}#yiv7328513939 dd.yiv7328513939last 
p a {font-family:Verdana;font-weight:700;}#yiv7328513939 dd.yiv7328513939last p 
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv7328513939 
dd.yiv7328513939last p span.yiv7328513939yshortcuts 
{margin-right:0;}#yiv7328513939 div.yiv7328513939attach-table div div a 
{text-decoration:none;}#yiv7328513939 div.yiv7328513939attach-table 
{width:400px;}#yiv7328513939 div.yiv7328513939file-title a, #yiv7328513939 
div.yiv7328513939file-title a:active, #yiv7328513939 
div.yiv7328513939file-title a:hover, #yiv7328513939 div.yiv7328513939file-title 
a:visited {text-decoration:none;}#yiv7328513939 div.yiv7328513939photo-title a, 
#yiv7328513939 div.yiv7328513939photo-title a:active, #yiv7328513939 
div.yiv7328513939photo-title a:hover, #yiv7328513939 
div.yiv7328513939photo-title a:visited {text-decoration:none;}#yiv7328513939 
div#yiv7328513939ygrp-mlmsg #yiv7328513939ygrp-msg p a 
span.yiv7328513939yshortcuts 
{font-family:Verdana;font-size:10px;font-weight:normal;}#yiv7328513939 
.yiv7328513939green {color:#628c2a;}#yiv7328513939 .yiv7328513939MsoNormal 
{margin:0 0 0 0;}#yiv7328513939 o {font-size:0;}#yiv7328513939 
#yiv7328513939photos div {float:left;width:72px;}#yiv7328513939 
#yiv7328513939photos div div {border:1px solid 
#66;height:62px;overflow:hidden;width:62px;}#yiv7328513939 
#yiv7328513939photos div label 
{color:#66;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv7328513939
 #yiv7328513939reco-category {font-size:77%;}#yiv7328513939 
#yiv7328513939reco-desc {font-size:77%;}#yiv7328513939 .yiv7328513939replbq 
{margin:4px;}#yiv7328513939 #yiv7328513939ygrp-

Re: [oracle_br] Privilégio insuficiente

2016-02-04 Por tôpico Rafael Mendonca raffaell.t...@yahoo.com [oracle_br] 
Como sys. 

Em Quinta-feira, 4 de Fevereiro de 2016 17:18, "'Fernando Franquini 
'capin'' fernando.franqu...@gmail.com [oracle_br]" 
 escreveu:
 

     Estou na rua, se não conseguir mais a noite tento fazer aqui.Você está 
dando permissão como System ou como owner dos objetos?

Em quinta-feira, 4 de fevereiro de 2016, Rafael Mendonca 
raffaell.t...@yahoo.com [oracle_br]  escreveu:

 

Fernando exatamente. Se não a view nem compilada ficaria, o usuário PACK já 
possui privilégio as tabelas do schema TELEVISAO.
Ainda está dando erro, muito estranho, acho que meu cérebro não está 
conseguindo mais raciocionar.
:( 

Em Quinta-feira, 4 de Fevereiro de 2016 16:50, "'Fernando Franquini 
'capin'' fernando.franqu...@gmail.com [oracle_br]" 
 escreveu:
 

     Usuario pack precisa também acesso as tabelas da televisão.
2016-02-04 17:44 GMT-02:00 Rafael Mendonca raffaell.t...@yahoo.com [oracle_br] 
:

 

 Oracle 11.2.0.4

Usuário XUXA deve realizar uma consulta em uma view do usuário PACK.
Essa view(simples) do schema PACK possui uma consulta em 2 tabelas do schema 
TELEVISAO.

Para que o usuário XUXA consiga realizar uma consulta na view PACK realizei os 
seguintes grants:

GRANT SELECT ON PACK.view to XUXA;
GRANT SELECT ON TELEVISAO.TABELA1 to XUXA;GRANT SELECT ON TELEVISAO.TEBELA2 to 
XUXA;

Não existe nenhum sinônimo/outro objeto com o mesmo nome da VIEW.
Acontece que quando o usuário XUXA faz uma consulta na VIEW do schema PACK 
ainda me gera o erro de privilégio insuficiente.

Mas quando pego a consulta da view e rodo por fora com usuário XUXA a consulta 
é me retornada.
Alguém teria alguma idéia do que possa estar acontecendo?








-- 
CapinGraduado: Bacharel em Ciências da Computação - UFSC
Analista de Sistemas e de Banco de Dados / DBA
48.9924.8212 Vivo - Florianópolis - SC - Brasil
http://certificacaobd.com.br/http://br.linkedin.com/in/capin
  

   




-- 
CapinGraduado: Bacharel em Ciências da Computação - UFSC
Analista de Sistemas e de Banco de Dados / DBA
48.9924.8212 Vivo - Florianópolis - SC - Brasil
http://certificacaobd.com.br/http://br.linkedin.com/in/capin

  #yiv9316406969 #yiv9316406969 -- #yiv9316406969ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv9316406969 
#yiv9316406969ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv9316406969 
#yiv9316406969ygrp-mkp #yiv9316406969hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv9316406969 #yiv9316406969ygrp-mkp #yiv9316406969ads 
{margin-bottom:10px;}#yiv9316406969 #yiv9316406969ygrp-mkp .yiv9316406969ad 
{padding:0 0;}#yiv9316406969 #yiv9316406969ygrp-mkp .yiv9316406969ad p 
{margin:0;}#yiv9316406969 #yiv9316406969ygrp-mkp .yiv9316406969ad a 
{color:#ff;text-decoration:none;}#yiv9316406969 #yiv9316406969ygrp-sponsor 
#yiv9316406969ygrp-lc {font-family:Arial;}#yiv9316406969 
#yiv9316406969ygrp-sponsor #yiv9316406969ygrp-lc #yiv9316406969hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv9316406969 
#yiv9316406969ygrp-sponsor #yiv9316406969ygrp-lc .yiv9316406969ad 
{margin-bottom:10px;padding:0 0;}#yiv9316406969 #yiv9316406969actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv9316406969 
#yiv9316406969activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv9316406969
 #yiv9316406969activity span {font-weight:700;}#yiv9316406969 
#yiv9316406969activity span:first-child 
{text-transform:uppercase;}#yiv9316406969 #yiv9316406969activity span a 
{color:#5085b6;text-decoration:none;}#yiv9316406969 #yiv9316406969activity span 
span {color:#ff7900;}#yiv9316406969 #yiv9316406969activity span 
.yiv9316406969underline {text-decoration:underline;}#yiv9316406969 
.yiv9316406969attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv9316406969 .yiv9316406969attach div a 
{text-decoration:none;}#yiv9316406969 .yiv9316406969attach img 
{border:none;padding-right:5px;}#yiv9316406969 .yiv9316406969attach label 
{display:block;margin-bottom:5px;}#yiv9316406969 .yiv9316406969attach label a 
{text-decoration:none;}#yiv9316406969 blockquote {margin:0 0 0 
4px;}#yiv9316406969 .yiv9316406969bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv9316406969 
.yiv9316406969bold a {text-decoration:none;}#yiv9316406969 dd.yiv9316406969last 
p a {font-family:Verdana;font-weight:700;}#yiv9316406969 dd.yiv9316406969last p 
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv9316406969 
dd.yiv9316406969last p span.yiv9316406969yshortcuts 
{margin-right:0;}#yiv9316406969 div.yiv9316406969attach-table div div a 
{text-decoration:none;}#yiv9316406969 div.yiv9316406969attach-table 
{width:400px;}#yiv9316406969 div.yiv9316406969file-title a, #yiv9316406969 
div.yiv9316406969file-title a:active, #yiv9316406969 
div.yiv9316406969file-title a:hover, #yiv9316406969 div.yiv9316406969file-title 
a:visited {text-decoration:none;}#yiv9316406969 div.yiv9316406969photo-title a

Re: [oracle_br] Privilégio insuficiente

2016-02-04 Por tôpico 'Fernando Franquini 'capin'' fernando.franqu...@gmail.com [oracle_br] 
Estou na rua, se não conseguir mais a noite tento fazer aqui.
Você está dando permissão como System ou como owner dos objetos?

Em quinta-feira, 4 de fevereiro de 2016, Rafael Mendonca
raffaell.t...@yahoo.com [oracle_br]  escreveu:

>
>
> Fernando exatamente. Se não a view nem compilada ficaria, o usuário PACK
> já possui privilégio as tabelas do schema TELEVISAO.
>
> Ainda está dando erro, muito estranho, acho que meu cérebro não está
> conseguindo mais raciocionar.
>
> :(
>
>
> Em Quinta-feira, 4 de Fevereiro de 2016 16:50, "'Fernando Franquini
> 'capin'' fernando.franqu...@gmail.com
> 
> [oracle_br]"  > escreveu:
>
>
>
> Usuario pack precisa também acesso as tabelas da televisão.
>
> 2016-02-04 17:44 GMT-02:00 Rafael Mendonca raffaell.t...@yahoo.com
>  [oracle_br] <
> oracle_br@yahoogrupos.com.br
> >:
>
>
>
> Oracle 11.2.0.4
>
>
> Usuário XUXA deve realizar uma consulta em uma view do usuário PACK.
>
> Essa view(simples) do schema PACK possui uma consulta em 2 tabelas do
> schema TELEVISAO.
>
>
> Para que o usuário XUXA consiga realizar uma consulta na view PACK
> realizei os seguintes grants:
>
>
> GRANT SELECT ON PACK.view to XUXA;
>
> GRANT SELECT ON TELEVISAO.TABELA1 to XUXA;
> GRANT SELECT ON TELEVISAO.TEBELA2 to XUXA;
>
>
> Não existe nenhum sinônimo/outro objeto com o mesmo nome da VIEW.
>
> Acontece que quando o usuário XUXA faz uma consulta na VIEW do schema PACK
> ainda me gera o erro de privilégio insuficiente.
>
>
> Mas quando pego a consulta da view e rodo por fora com usuário XUXA a
> consulta é me retornada.
>
> Alguém teria alguma idéia do que possa estar acontecendo?
>
>
>
>
>
>
>
>
> --
> Capin
> Graduado: Bacharel em Ciências da Computação - UFSC
> Analista de Sistemas e de Banco de Dados / DBA
> 48.9924.8212 Vivo - Florianópolis - SC - Brasil
> 
> http://certificacaobd.com.br/
> http://br.linkedin.com/in/capin
>
>
>
>
>
> 
>


-- 
Capin
Graduado: Bacharel em Ciências da Computação - UFSC
Analista de Sistemas e de Banco de Dados / DBA
48.9924.8212 Vivo - Florianópolis - SC - Brasil

http://certificacaobd.com.br/
http://br.linkedin.com/in/capin

Re: [oracle_br] Privilégio insuficiente

2016-02-04 Por tôpico Rafael Mendonca raffaell.t...@yahoo.com [oracle_br] 
Sim para todas as alternativas. Mas não é um ANY para objetos do schema, 
somente para os relacionados na descrição da thread. 

Em Quinta-feira, 4 de Fevereiro de 2016 17:09, "André Luiz 
aandre...@yahoo.com.br [oracle_br]"  escreveu:
 

     
Uma dúvida?
-Xuxa tem permissão para acessar o schema pack;-Xuxa também tem permissão para 
acessar o schema televisão -mas o schema pack onde esta a view tem permissão no 
schema televisão?

Enviado do meu iPhone
Em 4 de fev de 2016, às 17:44, Rafael Mendonca raffaell.t...@yahoo.com 
[oracle_br]  escreveu:


     Oracle 11.2.0.4

Usuário XUXA deve realizar uma consulta em uma view do usuário PACK.
Essa view(simples) do schema PACK possui uma consulta em 2 tabelas do schema 
TELEVISAO.

Para que o usuário XUXA consiga realizar uma consulta na view PACK realizei os 
seguintes grants:

GRANT SELECT ON PACK.view to XUXA;
GRANT SELECT ON TELEVISAO.TABELA1 to XUXA;GRANT SELECT ON TELEVISAO.TEBELA2 to 
XUXA;

Não existe nenhum sinônimo/outro objeto com o mesmo nome da VIEW.
Acontece que quando o usuário XUXA faz uma consulta na VIEW do schema PACK 
ainda me gera o erro de privilégio insuficiente.

Mas quando pego a consulta da view e rodo por fora com usuário XUXA a consulta 
é me retornada.
Alguém teria alguma idéia do que possa estar acontecendo?


  
  #yiv3912839131 #yiv3912839131 -- #yiv3912839131ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv3912839131 
#yiv3912839131ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv3912839131 
#yiv3912839131ygrp-mkp #yiv3912839131hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv3912839131 #yiv3912839131ygrp-mkp #yiv3912839131ads 
{margin-bottom:10px;}#yiv3912839131 #yiv3912839131ygrp-mkp .yiv3912839131ad 
{padding:0 0;}#yiv3912839131 #yiv3912839131ygrp-mkp .yiv3912839131ad p 
{margin:0;}#yiv3912839131 #yiv3912839131ygrp-mkp .yiv3912839131ad a 
{color:#ff;text-decoration:none;}#yiv3912839131 #yiv3912839131ygrp-sponsor 
#yiv3912839131ygrp-lc {font-family:Arial;}#yiv3912839131 
#yiv3912839131ygrp-sponsor #yiv3912839131ygrp-lc #yiv3912839131hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv3912839131 
#yiv3912839131ygrp-sponsor #yiv3912839131ygrp-lc .yiv3912839131ad 
{margin-bottom:10px;padding:0 0;}#yiv3912839131 #yiv3912839131actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv3912839131 
#yiv3912839131activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv3912839131
 #yiv3912839131activity span {font-weight:700;}#yiv3912839131 
#yiv3912839131activity span:first-child 
{text-transform:uppercase;}#yiv3912839131 #yiv3912839131activity span a 
{color:#5085b6;text-decoration:none;}#yiv3912839131 #yiv3912839131activity span 
span {color:#ff7900;}#yiv3912839131 #yiv3912839131activity span 
.yiv3912839131underline {text-decoration:underline;}#yiv3912839131 
.yiv3912839131attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv3912839131 .yiv3912839131attach div a 
{text-decoration:none;}#yiv3912839131 .yiv3912839131attach img 
{border:none;padding-right:5px;}#yiv3912839131 .yiv3912839131attach label 
{display:block;margin-bottom:5px;}#yiv3912839131 .yiv3912839131attach label a 
{text-decoration:none;}#yiv3912839131 blockquote {margin:0 0 0 
4px;}#yiv3912839131 .yiv3912839131bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv3912839131 
.yiv3912839131bold a {text-decoration:none;}#yiv3912839131 dd.yiv3912839131last 
p a {font-family:Verdana;font-weight:700;}#yiv3912839131 dd.yiv3912839131last p 
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv3912839131 
dd.yiv3912839131last p span.yiv3912839131yshortcuts 
{margin-right:0;}#yiv3912839131 div.yiv3912839131attach-table div div a 
{text-decoration:none;}#yiv3912839131 div.yiv3912839131attach-table 
{width:400px;}#yiv3912839131 div.yiv3912839131file-title a, #yiv3912839131 
div.yiv3912839131file-title a:active, #yiv3912839131 
div.yiv3912839131file-title a:hover, #yiv3912839131 div.yiv3912839131file-title 
a:visited {text-decoration:none;}#yiv3912839131 div.yiv3912839131photo-title a, 
#yiv3912839131 div.yiv3912839131photo-title a:active, #yiv3912839131 
div.yiv3912839131photo-title a:hover, #yiv3912839131 
div.yiv3912839131photo-title a:visited {text-decoration:none;}#yiv3912839131 
div#yiv3912839131ygrp-mlmsg #yiv3912839131ygrp-msg p a 
span.yiv3912839131yshortcuts 
{font-family:Verdana;font-size:10px;font-weight:normal;}#yiv3912839131 
.yiv3912839131green {color:#628c2a;}#yiv3912839131 .yiv3912839131MsoNormal 
{margin:0 0 0 0;}#yiv3912839131 o {font-size:0;}#yiv3912839131 
#yiv3912839131photos div {float:left;width:72px;}#yiv3912839131 
#yiv3912839131photos div div {border:1px solid 
#66;height:62px;overflow:hidden;width:62px;}#yiv3912839131 
#yiv3912839131photos div label 
{color:#66;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:

Re: [oracle_br] Privilégio insuficiente

2016-02-04 Por tôpico André Luiz aandre...@yahoo.com.br [oracle_br] 

Uma dúvida?

-Xuxa tem permissão para acessar o schema pack;
-Xuxa também tem permissão para acessar o schema televisão 
-mas o schema pack onde esta a view tem permissão no schema televisão?


Enviado do meu iPhone

> Em 4 de fev de 2016, às 17:44, Rafael Mendonca raffaell.t...@yahoo.com 
> [oracle_br]  escreveu:
> 
> Oracle 11.2.0.4
> 
> 
> Usuário XUXA deve realizar uma consulta em uma view do usuário PACK.
> 
> Essa view(simples) do schema PACK possui uma consulta em 2 tabelas do schema 
> TELEVISAO.
> 
> 
> Para que o usuário XUXA consiga realizar uma consulta na view PACK realizei 
> os seguintes grants:
> 
> 
> GRANT SELECT ON PACK.view to XUXA;
> 
> GRANT SELECT ON TELEVISAO.TABELA1 to XUXA;
> GRANT SELECT ON TELEVISAO.TEBELA2 to XUXA;
> 
> 
> Não existe nenhum sinônimo/outro objeto com o mesmo nome da VIEW.
> 
> Acontece que quando o usuário XUXA faz uma consulta na VIEW do schema PACK 
> ainda me gera o erro de privilégio insuficiente.
> 
> 
> Mas quando pego a consulta da view e rodo por fora com usuário XUXA a 
> consulta é me retornada.
> 
> Alguém teria alguma idéia do que possa estar acontecendo?
> 
> 
> 
>

Re: [oracle_br] Privilégio insuficiente

2016-02-04 Por tôpico Rafael Mendonca raffaell.t...@yahoo.com [oracle_br] 
Fernando exatamente. Se não a view nem compilada ficaria, o usuário PACK já 
possui privilégio as tabelas do schema TELEVISAO.
Ainda está dando erro, muito estranho, acho que meu cérebro não está 
conseguindo mais raciocionar.
:( 

Em Quinta-feira, 4 de Fevereiro de 2016 16:50, "'Fernando Franquini 
'capin'' fernando.franqu...@gmail.com [oracle_br]" 
 escreveu:
 

     Usuario pack precisa também acesso as tabelas da televisão.
2016-02-04 17:44 GMT-02:00 Rafael Mendonca raffaell.t...@yahoo.com [oracle_br] 
:

 

 Oracle 11.2.0.4

Usuário XUXA deve realizar uma consulta em uma view do usuário PACK.
Essa view(simples) do schema PACK possui uma consulta em 2 tabelas do schema 
TELEVISAO.

Para que o usuário XUXA consiga realizar uma consulta na view PACK realizei os 
seguintes grants:

GRANT SELECT ON PACK.view to XUXA;
GRANT SELECT ON TELEVISAO.TABELA1 to XUXA;GRANT SELECT ON TELEVISAO.TEBELA2 to 
XUXA;

Não existe nenhum sinônimo/outro objeto com o mesmo nome da VIEW.
Acontece que quando o usuário XUXA faz uma consulta na VIEW do schema PACK 
ainda me gera o erro de privilégio insuficiente.

Mas quando pego a consulta da view e rodo por fora com usuário XUXA a consulta 
é me retornada.
Alguém teria alguma idéia do que possa estar acontecendo?








-- 
CapinGraduado: Bacharel em Ciências da Computação - UFSC
Analista de Sistemas e de Banco de Dados / DBA
48.9924.8212 Vivo - Florianópolis - SC - Brasil
http://certificacaobd.com.br/http://br.linkedin.com/in/capin
  #yiv5692760338 #yiv5692760338 -- #yiv5692760338ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv5692760338 
#yiv5692760338ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv5692760338 
#yiv5692760338ygrp-mkp #yiv5692760338hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv5692760338 #yiv5692760338ygrp-mkp #yiv5692760338ads 
{margin-bottom:10px;}#yiv5692760338 #yiv5692760338ygrp-mkp .yiv5692760338ad 
{padding:0 0;}#yiv5692760338 #yiv5692760338ygrp-mkp .yiv5692760338ad p 
{margin:0;}#yiv5692760338 #yiv5692760338ygrp-mkp .yiv5692760338ad a 
{color:#ff;text-decoration:none;}#yiv5692760338 #yiv5692760338ygrp-sponsor 
#yiv5692760338ygrp-lc {font-family:Arial;}#yiv5692760338 
#yiv5692760338ygrp-sponsor #yiv5692760338ygrp-lc #yiv5692760338hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv5692760338 
#yiv5692760338ygrp-sponsor #yiv5692760338ygrp-lc .yiv5692760338ad 
{margin-bottom:10px;padding:0 0;}#yiv5692760338 #yiv5692760338actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv5692760338 
#yiv5692760338activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv5692760338
 #yiv5692760338activity span {font-weight:700;}#yiv5692760338 
#yiv5692760338activity span:first-child 
{text-transform:uppercase;}#yiv5692760338 #yiv5692760338activity span a 
{color:#5085b6;text-decoration:none;}#yiv5692760338 #yiv5692760338activity span 
span {color:#ff7900;}#yiv5692760338 #yiv5692760338activity span 
.yiv5692760338underline {text-decoration:underline;}#yiv5692760338 
.yiv5692760338attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv5692760338 .yiv5692760338attach div a 
{text-decoration:none;}#yiv5692760338 .yiv5692760338attach img 
{border:none;padding-right:5px;}#yiv5692760338 .yiv5692760338attach label 
{display:block;margin-bottom:5px;}#yiv5692760338 .yiv5692760338attach label a 
{text-decoration:none;}#yiv5692760338 blockquote {margin:0 0 0 
4px;}#yiv5692760338 .yiv5692760338bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv5692760338 
.yiv5692760338bold a {text-decoration:none;}#yiv5692760338 dd.yiv5692760338last 
p a {font-family:Verdana;font-weight:700;}#yiv5692760338 dd.yiv5692760338last p 
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv5692760338 
dd.yiv5692760338last p span.yiv5692760338yshortcuts 
{margin-right:0;}#yiv5692760338 div.yiv5692760338attach-table div div a 
{text-decoration:none;}#yiv5692760338 div.yiv5692760338attach-table 
{width:400px;}#yiv5692760338 div.yiv5692760338file-title a, #yiv5692760338 
div.yiv5692760338file-title a:active, #yiv5692760338 
div.yiv5692760338file-title a:hover, #yiv5692760338 div.yiv5692760338file-title 
a:visited {text-decoration:none;}#yiv5692760338 div.yiv5692760338photo-title a, 
#yiv5692760338 div.yiv5692760338photo-title a:active, #yiv5692760338 
div.yiv5692760338photo-title a:hover, #yiv5692760338 
div.yiv5692760338photo-title a:visited {text-decoration:none;}#yiv5692760338 
div#yiv5692760338ygrp-mlmsg #yiv5692760338ygrp-msg p a 
span.yiv5692760338yshortcuts 
{font-family:Verdana;font-size:10px;font-weight:normal;}#yiv5692760338 
.yiv5692760338green {color:#628c2a;}#yiv5692760338 .yiv5692760338MsoNormal 
{margin:0 0 0 0;}#yiv5692760338 o {font-size:0;}#yiv5692760338 
#yiv5692760338photos div {float:left;width:72px;}#yiv5692760338 
#yiv5692760338photos div div {border:1px solid 
#66

Re: [oracle_br] Privilégio insuficiente

2016-02-04 Por tôpico 'Fernando Franquini 'capin'' fernando.franqu...@gmail.com [oracle_br] 
Usuario pack precisa também acesso as tabelas da televisão.

2016-02-04 17:44 GMT-02:00 Rafael Mendonca raffaell.t...@yahoo.com
[oracle_br] :

>
>
> Oracle 11.2.0.4
>
>
> Usuário XUXA deve realizar uma consulta em uma view do usuário PACK.
>
> Essa view(simples) do schema PACK possui uma consulta em 2 tabelas do
> schema TELEVISAO.
>
>
> Para que o usuário XUXA consiga realizar uma consulta na view PACK
> realizei os seguintes grants:
>
>
> GRANT SELECT ON PACK.view to XUXA;
>
> GRANT SELECT ON TELEVISAO.TABELA1 to XUXA;
> GRANT SELECT ON TELEVISAO.TEBELA2 to XUXA;
>
>
> Não existe nenhum sinônimo/outro objeto com o mesmo nome da VIEW.
>
> Acontece que quando o usuário XUXA faz uma consulta na VIEW do schema PACK
> ainda me gera o erro de privilégio insuficiente.
>
>
> Mas quando pego a consulta da view e rodo por fora com usuário XUXA a
> consulta é me retornada.
>
> Alguém teria alguma idéia do que possa estar acontecendo?
>
>
>
>
>
> 
>



-- 
Capin
Graduado: Bacharel em Ciências da Computação - UFSC
Analista de Sistemas e de Banco de Dados / DBA
48.9924.8212 Vivo - Florianópolis - SC - Brasil

http://certificacaobd.com.br/
http://br.linkedin.com/in/capin

[oracle_br] Privilégio insuficiente

2016-02-04 Por tôpico Rafael Mendonca raffaell.t...@yahoo.com [oracle_br] 
 Oracle 11.2.0.4

Usuário XUXA deve realizar uma consulta em uma view do usuário PACK.
Essa view(simples) do schema PACK possui uma consulta em 2 tabelas do schema 
TELEVISAO.

Para que o usuário XUXA consiga realizar uma consulta na view PACK realizei os 
seguintes grants:

GRANT SELECT ON PACK.view to XUXA;
GRANT SELECT ON TELEVISAO.TABELA1 to XUXA;GRANT SELECT ON TELEVISAO.TEBELA2 to 
XUXA;

Não existe nenhum sinônimo/outro objeto com o mesmo nome da VIEW.
Acontece que quando o usuário XUXA faz uma consulta na VIEW do schema PACK 
ainda me gera o erro de privilégio insuficiente.

Mas quando pego a consulta da view e rodo por fora com usuário XUXA a consulta 
é me retornada.
Alguém teria alguma idéia do que possa estar acontecendo?

Re: [oracle_br] Re: Mídi a WebLogic Server 10.3.2

2016-02-04 Por tôpico Emerson Martins emersonmarti...@gmail.com [oracle_br] 
Boa Vitão.


Rumo a OCM \0/.


Att,


Emerson Martins
DBA Oracle
Oracle 11g Certified Associate




Em 3 de fevereiro de 2016 14:14, Vitor Junior vitorj...@gmail.com
[oracle_br]  escreveu:


>
>
> Depois de todo esse tempo, finalmente consegui todos os softwares
> necessários! :)
> Começando os estudos! Abraço a todos que tentaram ajudar de alguma forma!
>
> Em qua, 27 de jan de 2016 às 11:45, jlchia...@yahoo.com.br [oracle_br] <
> oracle_br@yahoogrupos.com.br> escreveu:
>
>>
>>
>> maravilha, toda sorte do mundo pra vc...
>>
>>  []s
>>
>>Chiappa
>>
> --
> Att,/Regards,
>
>
> Vitor Jr.
> Infraestrutura / Infrastructure Team
>
> Oracle 12c DBA Certified Professional - OCP 12c
> Oracle 11g DBA Certified Professional - OCP 11g
> Oracle Certified Expert, Oracle Real Application Clusters 11g and Grid
> Infrastructure Administrator - OCE
> Oracle Database 11g Performance Tuning Certified Expert - OCE
> Oracle Exadata 11g Certified Implementation Specialist
> Oracle Certified Associate, MySQL 5
> mail, gtalk e msn: vitorj...@gmail.com
> http://certificacaobd.com.br/
> skype: vjunior1981
> https://mybizcard.co/vitor.jr.385628
>
>
>

[oracle_br] Mover node entre clusters

2016-02-04 Por tôpico Vitor Junior vitorj...@gmail.com [oracle_br] 
Buenas.

Cenário: OEL 6.7, Oracle EE 11.2.0.4 x86-64

Digamos que eu tivesse 5 clusters de 2 nodes cada e quisesse transformar em
um grande cluster de 10 máquinas, o procedimento básico seria remove para
cada node e ir adicionando em um dos clusters? Ou existe algo do tipo um
'relocate' ou 'move'?
Estou procurando material na web, mas não achei nada específico.
Caso alguém tenha essa experiência e puder dar um pitaco, agradeço! :)
-- 
Att,/Regards,


Vitor Jr.
Infraestrutura / Infrastructure Team

Oracle 12c DBA Certified Professional - OCP 12c
Oracle 11g DBA Certified Professional - OCP 11g
Oracle Certified Expert, Oracle Real Application Clusters 11g and Grid
Infrastructure Administrator - OCE
Oracle Database 11g Performance Tuning Certified Expert - OCE
Oracle Exadata 11g Certified Implementation Specialist
Oracle Certified Associate, MySQL 5
mail, gtalk e msn: vitorj...@gmail.com
http://certificacaobd.com.br/
skype: vjunior1981
https://mybizcard.co/vitor.jr.385628

[oracle_br] DBSNMP obrigatorio?

2016-02-04 Por tôpico dadim...@yahoo.com.br [oracle_br] 
Suponhamos que minha empresa tem um contrato com outra, que usa o EM12c para 
monitorar 1 determinado target (produção, super-crítico, 24x7, etc).
 Agora suponhamos que minha empresa comprou o EM12c e quer monitorar o mesmo 
target (inclusive banco de dados 24x7, supercrítico).
 É possível monitorar um banco com outro usuário, que não o DBSNMP? Ou o EM12c 
é amarrado neste usuário ?
 Obrigado pelas respostas!

Re: [oracle_br] Re: Perda de contrato com a Oracle

2016-02-04 Por tôpico Ivan Ricardo Schuster ivanr...@gmail.com [oracle_br] 
Duas informações adicionais a essa thread:

1) A questão de não pagar suporte para ambientes não produtivos ou pagar
licenciamento de um produto mais barato para ter acesso aos downloads não é
bem assim.

Em teoria (em contrato) caso seu banco de dados não esteja em contrato de
suporte você não pode aplicar nenhum patch/patchset nem atualização de
versão que tenha sido lançado depois do cancelamento do seu contrato de
suporte. Isso implica que, digamos que você pague suporte para PRD mas não
pague para DSV/HML, você não poderá aplicar em DSV/HML os patches que foram
aplicados em PRD. Isso faz sentido? Além disso, pagando suporte a um
produto mais barato não te dá o direito de instalar atualizações de
produtos mais caros. Talvez você possa, mas não deve!

2) Você não informou que versão do seu banco de dados você usa (SE, SE1 ou
EE), mas recentemente a Oracle publicou informação que estaria
descontinuando o SE1 e SE, transformando em uma unica versão SE2, e que
licenças de SE1 e SE seriam migradas para SE2 sem custos. Falando de
valores (não sei quão atualizados) estaríamos falando de uma licença de
20k/proc do SE1 ser migrada para o SE2 que custa 80k/proc. E o que isso tem
a ver? Via de regra, se você deixa de pagar o suporte ao seu produto,
quando quiser atualizar ou aplicar patch, etc, você precisará comprar
licença nova (de 80k), caso esteja com o suporte ativo e válido não
precisará comprar nada, simplesmente atualizar.

2016-02-03 16:33 GMT-02:00 Rafael Mendonca raffaell.t...@yahoo.com
[oracle_br] :

>
>
> Opa Chiappa, ótima explicação e obrigado pela atenção de sempre.
>
>
> Em Quarta-feira, 3 de Fevereiro de 2016 15:07, "jlchia...@yahoo.com.br
> [oracle_br]"  escreveu:
>
>
>
> Redução de Custos Operacionais Oracle - ref.
> Blz ? Certamente vc já sabe de tudo que vou dizer, mas apenas para
> informação de quem for ler esta thread no futuro, vou detalhar algumas
> opções relacionadas
>   A primeira coisa a dizer é que há basicamente 3 tipos de pagamentos que
> vc pode ter que fazer para a Oracle no que se refere a databases :
> Licenciamento, Suporte Técnico e Add-ons/features licenciadas à parte, vou
> dar algumas dicas do que se pode fazer em cada caso :
>
>   ==> Licença : isso Não PODE e NÃO DEVE nunca ser confundido com o
> Suporte... A taxa de Licença é um valor que vc paga para ter Direito de
> usar o RDBMS com seus dados reais e/ou seu software REAL (ie, que vai te
> dar Lucro/ser vendido/ser usado no seu negócio,Produzindo resultado
> usável), ENQUANTO que o Suporte é algo Opcional, que vc paga se quiser
> obter ajuda a usar melhor o software via recomendações/best practices,
> resolver bugs/problemas de usabilidade...
> A observação é que se pode OU Licenciar o RDBMS por servidor (ie, se
> faz um cálculo de capacidade bruta , envolvendo entre outras coisas número
> e tipo de processadores), paga-se um valor tabelado por isso e se pode ter
> quantos databases quiser, gerenciados por quantas instalações de RDBMS
> quiser, sendo acessador por qquer número de usuários processadores ), OU se
> pode licenciar cada database por número de usuários nomeados, ie, cada
> usuário que vai conectar pode ser identificado e vc paga um valor fixo por
> cada usuário
>Então é simples , a primeira coisa que se faz ao tentar reduzir custo
> de licenças é identificar eventuais servidores/database que não são
> produção (basicamente POCs, usando software e/ou dados não-reais),
> identificar eventuais casos de databases onde a lista de usuários seja
> conhecida e fixa (ou possa ser fixada) e comparar custos de licenciamento
> por usuário x licenciamento por servidor...
>
>   ==> Suporte Técnico : como a gente disse antes, isso é Muitíssimo
> Recomendado mas principalmente em ambientes produtivos, onde um bugfix e/ou
> uma análise do Suporte Oracle podem ser um diferencial vital para a
> Estabilidade/Continuidade do negócio da empresa, e/ou para racionalização
> de recursos... OBVIAMENTE, a primeira Ação para reduzir custos de Suporte é
> CATEGORIZAR/LEVANTAR direitinho a utilização dos databases e *** ELIMINAR
> ***, em dó nem pena, o Contrato de Suporte para os ambientes não-críticos
> que não Justifiquem o investimento Notar que não é simplesmente dizer
> se é produção ou não, tranquilamente PODEM existir databases não-produção
> que sejam críticos e exijam Suporte (sei lá, um database dedicado a
> reports, ou um de Homologação, digamos), E/OU podem existir databases
> produção que estejam atendendo sistemas / ambientes menos Críticos que
> Talvez possam rodar sem Suporte.
>
>   O SEGUNDO PONTO de diminuição de custo de Suporte é Avaliar qual/quais
> databases podem rodar sem um Contrato de Suporte específico para eles : o
> que acontece é que, se vc tiver um Contrato de Suporte para um outro
> produto Oracle mais baratinho vc, OBVIAMENTE, não vai poder abrir um
> Chamado de ajuda/verificação para o RDBMS grandão/fullzão que vc tem na
> Produção ** MAS  vai poder SIM baixar a m