Arquivo da categoria: permissao

Erro na Instalação – 10.2.0.1 – OUI-10094

Olá PessoALL,

Ontem tive uma necessidade de instalação do Oracle 10gR2 em um cliente. Isso mesmo, estamos em 07/2013, e precisamos instalar um Oracle 10gR2! rsrs. Deixa eu contar um pouco da história:

O banco de produção é um 9.2.0.6 (acharam que não podia ser pior que o 10gR2 né), rodando em um HP-UX Itanium 64bits e que não tem mais suporte por parte da HP, ou seja, temos que nos virar com o que temos para migrar este banco de 9.2.0.6 urgente! Afinal, não temos mais suporte nem do banco nem da máquina onde ele está instalado. Depois de muitas e muitas tentativas de migração, inclusive usando Golden Gate em que não tivemos sucesso, a opção menos pior encontrada foi expdp e impdp, só que para isso precisávamos estar pelo menos no 10g! Sei que deve estar se perguntando… porque não 11g direto? Lembram que a máquina não tem mais suporte? Pois é, para instalar o 11g neste servidor, mesmo sendo certificado, precisava instalar alguns pacotes, e claro que sem suporte, sem contrato e sem nada, a HP não iria dar de mão beijada estes pacotes para nos ajudar a deixar de usar a plataforma deles! Por isso a escolha do passo a passo foi:

1 – Instalar o Oracle 10GR2, 10.2.0.1.

2 – Aplicar o Patchset 10.2.0.4 e eliminar alguns possíveis bugs.

3 – Migrar o banco 9.2.0.6 para 10.2.0.4.

4 – Fazer expdp paralelizado para extrair os dados.

5 – Fazer impdp no novo, querido e parrudo servidor Linux com Oracle 11gR2!

Então, já no passo 1 encontramos um problema, o erro: OUI-10094.

A instalação ocorria normalmente, todas as configurações eram feitas e dava erro apenas na hora de registrar no inventário.

Pois é, na parte mais simples ocorria o erro.

Pesquisando no Metalink, encontrei uma nota que falava a respeito, em que a Oracle assumia sem nenhum pudor que o instalador do 10.2.0.1, versão base do 10gR2 tinha um “bug” que não conseguia fazer atualização de inventário caso tivessem outros Oracle Home´s  instalados com outros owners na mesma máquina. Por exemplo:

Tenho um Oracle 9.2.0.6 instalado com o owner ora96.

Tenho um Oracle 10gR1 instalado com o owner ora101.

No momento de instalar o Oracle 10gR2 com o owner ora102, ele vai ter que adicionar no inventário esta nova instalação, mas… quem criou o inventário não foi o owner ora102, por isso ocorre o problema, mas é um problema no instalador.

O grande aprendizado que quero passar neste post é sobre a recomendação da Oracle para corrigir o problema, que basicamente foi: “Instale o Oracle 10.2.0.1 com o instalador do 10.2.0.4!”, então, na hora de chamar o runInstaller, usar o executável da versão 10.2.0.4 chamando a instalação do 10.2.0.1. Como fazer isso… assim:


[ora10g@srvhp:/home/ora10g]: cd /ora10g/install/patch_10204/disk1/
[ora10g@srvhp:/home/ora10g]: ./runInstaller FROM_LOCATION="/ora10g/install/10201/disk1/stage/products.xml"

Então, o que fizemos foi ir até a pasta de instalação do Patchset 10.2.0.4 e chamar o instalador dele, só que informando que a instalação deveria pegar os produtos da versão base 10.2.0.1, usando o parâmetro FROM_LOCATION. Interessante não?! Você pode instalar um outro “produto” usando o instalador menos “bugado”.

A conclusão disso pra mim é: Que bom que a Oracle é muito boa de documentação, porque esses probleminhas tem de monte! Só que tudo tá documentado e geralmente tem uma solução de contorno!

Temos então nosso 10gR2 instalado e agora vamos a migração! Caso tenhamos mais novidades, mantenho vocês informados!

 

Abraços a todos.

 

 

Atc.

Gerson Júnior

gerson.vasconcelos@gmail.com

Privilegios (Grant) no Oracle

Fala PessoAll,

Demorei, mas estamos de volta.

Dessa vez, vou dar uma dica bem simples sobre privilégios (grants) no banco Oracle.

Quem muitas vezes não foi realizar um select em uma tabela qualquer no banco de dados e obteve um ora-00942: table or view does not exist? Pois é, este erro nem sempre é o que diz que é! Que coisa não? Muitas vezes a tabela existe só que pertence a um outro schema do banco de dados, e aí o usuário que voce está conectado não consegue enxergar este objeto. Isso pode acontecer com tabelas, views, functions, procedures, etc o que acontece é que o schema proprietário do objeto tem que conceder a devida permissão para o usuário que você está conectado.

Vamos a um cenário, para que possamos entender esse rolo todo.

Suponhamos que em nossa base a gente tenha o usuário DONOSISTEMA que criou uma tabela chamada TABELA_BASE e você se conecta no banco com o usuário USERSISTEMA, então como faríamos para que você conseguisse acessar esta tabela?

Assim:

Primeiro vamos conectar com DONOSISTEMA e criar a tabela:

SQL> conn donosistema/oracle;
Conectado.
SQL> create table tabela_base(campo1 number, campo2 varchar2(100));

Tabela criada.

Beleza, agora vamos conectar com o usuário USERSISTEMA e tentar dar um select count(*) nesta tabela:

SQL> conn usersistema/oracle;
Conectado.
SQL> select count(*) from donosistema.tabela_base;
select * from donosistema.tabela_base
*
ERRO na linha 1:
ORA-00942: a tabela ou view nÒo existe

Parece que não deu muito certo não? Pois é, não tem privilégio.
Agora vamos conectar novamente como DONOSISTEMA e conceder o privilégio:

SQL> conn donosistema/oracle;
Conectado.
SQL> grant select on tabela_base to usersistema;

ConcessÒo bem-sucedida.

Perfeito… agora vamos conectar novamente com o usuário USERSISTEMA e tentar novamente fazer o select count(*) nessa tabela:

SQL> conn usersistema/oracle;
Conectado.

SQL> select count(*) from donosistema.tabela_base;

COUNT(*)
----------
0

Agora parece que ficou beleza não? Nosso usuário conseguiu realizar acessar a tabela sem problemas.

Só que… eu sou um cara chato! Não quero ter que colocar nome do dono do objeto na frente (DONOSISTEMA.)… na verdade não quero nem que meu usuário que vai acessar a aplicação saiba quem é o dono dos objetos, pra ele não cair em tentação! Rsrs. Para isso, precisamos criar um objeto chamado SYNONYM que nada mais é que um sinônimo (óbvio não) para o objeto original. Por exemplo, no nosso caso, temos que criar um synonym com o nome TABELA_BASE que aponte para o objeto DONOSISTEMA.TABELA_BASE certo?

Então vamos lá.

Pra não dizerem que estou mentindo (rsrs) inicialmente vou conectar como USERSISTEMA para que possamos ver que se tirar o nome do dono do objeto da frente da tabela o select não vai funcionar, vamos ver:


SQL> conn usersistema/oracle;
Conectado.

SQL> select count(*) from tabela_base;
select count(*) from tabela_base
*
ERRO na linha 1:
ORA-00942: a tabela ou view nÒo existe

Hum… realmente não funciona.

Agora vamos conectar como DONOSISTEMA e criar o synonym para esta tabela ok? vamos lá:


SQL> conn donosistema/oracle;
Conectado.
SQL> create public synonym tabela_base for donosistema.tabela_base;

Sin¶nimo criado.

Beleza. Agora vamos conectar novamente como USERSISTEMA e ver se ele consegue acessar sem o nome do dono na frente? Vamos:


SQL> conn usersistema/oracle;
Conectado.
SQL> select count(*) from tabela_base;

COUNT(*)
----------
0

Perfeito não? Que beleza!! É assim que fazemos para que tenhamos um usuário dono dos objetos do nosso banco de dados e vários outros usuários que apenas utilizam estes objetos. Desta forma organizamos nossos objetos e garantimos que fica transparente aos usuários seu acesso.

E como eu sei se tenho permissão ou não para um determinado objeto?
Simples, consultando o dicionário dados. Tentem rodar o select abaixo:


select grantor, grantee, table_name, privilege
from all_tab_privs
where grantee = 'USUARIO_RECEBEDOR_PRIVILEGIO'
and grantor = 'USUARIO_DONO_OBJETO'
and table_name = 'NOME_DO_OBJETO'

Aí vocês podem usar ou não todos os filtros que coloquei.
Aí podemos filtrar por:
GRANTOR: que é o usuário que concedeu a permissão. No nosso caso DONOSISTEMA.

GRANTEE: que é o usuário que recebeu a permissão. No nosso caso USERSISTEMA.

TABLE_NAME: que é o nome da tabela envolvida no nosso processo. No nosso caso TABLE_BASE.

É isso gente.
Espero que tenham gostado e que daqui pra frente fique tudo mais claro sobre permissões, sinônimos e etc.

Atc.
Gerson Júnior
(gerson.vasconcelos@gmail.com)