Estou utilizando o APEX, mas a dúvida serve também quando utilizo o SQL Developer ou o SQL Plus.
Ao usar o APEX, eu crio uma área de trabalho. Quando eu tenho dois ou mais usuários criados no APEX residentes na mesma área de trabalho, as tabelas que um cria o outro pode ver e utilizar, e vice e versa. Quando eu coloco usuários em áreas de trabalho diferentes, um somente pode ver as tabelas do outro se houver concessões, como grant select, por exemplo.
Li em vários fóruns que um usuário pode ler todas as tabelas do banco de dados quando cria um usuário e estabelece grant resources a ele, o que implicitamente garante unlimited tablespace. Ou seja, um usuário pode ler todas as tabelas de um banco de dados por causa do unlimited tablespace. Fiz um teste no APEX e isso não se confirmou. No SQL Plus, criei dois usuários. Dentro de um deles, criei várias tabelas. No outro, apenas uma. No primeiro, dei grant connect, resources e no segundo, dei grant individualmente, como grant create table, create view..., não atribuindo unlimited tablespace. No APEX, criei dois espaços de trabalho distintos, baseados nesses dois usuários criados. Depois, criei dois usuários no APEX.
Conclusão: quando os dois usuários estão na mesma área de trabalho, um pode acessar as tabelas do outro. Quando são criados em áreas de trabalho distintas, não podem acessar as tabelas do outro, mesmo tendo o grant unlimited tablespace.
Afinal, para que serve o unlimited tablespace? Como posso ver as concessões que são atribuídas ao usuário quando dou um grant resource, connect?
APEX - unlimited tablespace
-
stcoutinho
- Moderador
- Mensagens: 850
- Registrado em: Qua, 11 Mai 2011 5:15 pm
- Localização: são Paulo - SP
Olá Milhorini,
Estamos falando de dois produtos distintos. Um deles seria o ORACLE APEX e outro seria o ORACLE DATABASE. Ambos dispõe de conceitos de administração/segurança distintos.
A permissão de "UNLIMITED TABLESPACE" nada tem a ver com permissões de acesso à tabelas de banco.
Quando se cria um usuário de banco de dados, eu posso por exemplo "limitar" o espaço ocupado em tablespaces pelos objetos dele (tabelas, índices).
Por exemplo, eu criei no BANCO DE DADOS um usuário XPTOUSER e desejo que os objetos de tabela e índice criados por ele ocupem no máximo 500 M na tablespace USERS. Neste caso, eu poderia executar como DBA o comando
Mas digamos que você não deseja que seu usuário XPTOUSER sofra restrições de espaço na tablespace USERS. Neste caso você pode executar como DBA o comando
Digamos ainda que você não quer que seu usuário de BANCO XPTOUSER sofra QUALQUER restrição de espaço em nenhuma tablespaces do BANCO. Desta forma você pode executar como DBA o comando
Os recursos APEX de "WORKSPACE" e "USUARIOS" são recursos do produto ORACLE APEX e não do BANCO de DADOS.
Quando você cria uma WORKSPACE, você mesmo assim precisa apontar para um SCHEMA de banco de dados (um schema é um usuário de BANCO que disponha de objectos criados nele - tabelas, sinonimos, views, etc).
Então, digamos que você criou no APEX:
- Workspace SISTEMA, apontando para o schema de banco XPTOUSER (este é um usuário de BANCO);
- Dois usuários (JOAO / ANTONIO) para esta Workspace SISTEMA (estes são usuários APEX);
Em teoria, qualquer objeto de banco criado com o usuário de XPTOUSER (BANCO) será visível para os usuários JOAO (APEX) e ANTONIO (APEX), não havendo necessidade de se criar nenhuma permissão adicional de banco.
Agora, digamos que você criou no APEX:
- Workspace SISTEMA2, apontando para o mesmo schema de banco XPTOUSER (este é um usuário de BANCO);
- Dois usuários (ZE / LUIS) para esta Workspace SISTEMA2 (estes são usuários APEX);
Os usuários APEX JOAO, ANTONIO, ZE e LUIS vão conseguir acessar as mesmas tabelas, pois elas pertencem ao mesmo schema XPTOUSER;
Vamos supor uma última atividade. Digamos que você criou :
- Workspace SISTEMA3, apontando para o schema de banco WXYZUSER (este é um usuário de BANCO);
- Dois usuários (ANA / MARIA) para esta Workspace SISTEMA3 (estes são usuários APEX);
Pelo fato de SISTEMA3 apontar para um schema DIFERENTE (WXYZUSER), ANA e MARIA não vão conseguir acessar as tabelas do schema XPTOUSER, enquanto que JOAO, ANTONIO, ZE e LUIS não vão conseguir acessar as tabelas do schema WXYZUSER.
Neste caso, como seria possível todos acessarem as tabelas de todos? Eu teria que entrar no banco como XPTOUSER e dar as permissões de acesso aos objetos de banco dele para o usuário de banco WXYZUSER. E deveria repetir o mesmo processo em WXYZUSER, atribuindo as permissões de acesso às tabelas dele para o XPTOUSER. Fora isso, deveria criar sinônimos privados em XPTOUSER e WXYZUSER, para que um pudesse consultar as tabelas um do outro sem a necessidade de informar o schema
ex:
Desculpe, eu escrevi muito e mesmo assim talvez não tenha ficado muito claro para você. É que é preciso entender que estamos falando de dois universos diferentes (APEX e BANCO). Quando falamos de usuários e permissões do APEX, não significa que estamos falando exatamente de banco de dados.
Talvez este artigo abaixo (da oracle) lhe permita entender um pouco sobre permissões de BANCO de DADOS:
http://www.oracle.com/technetwork/pt/ar ... 6-ptb.html
Fora isso, seria interessante dar uma lida nos manuais do Oracle APEX, para verificar como seria possível você organizar as workspaces.
Abraços e tudo de bom,
Sergio Coutinho
Estamos falando de dois produtos distintos. Um deles seria o ORACLE APEX e outro seria o ORACLE DATABASE. Ambos dispõe de conceitos de administração/segurança distintos.
A permissão de "UNLIMITED TABLESPACE" nada tem a ver com permissões de acesso à tabelas de banco.
Quando se cria um usuário de banco de dados, eu posso por exemplo "limitar" o espaço ocupado em tablespaces pelos objetos dele (tabelas, índices).
Por exemplo, eu criei no BANCO DE DADOS um usuário XPTOUSER e desejo que os objetos de tabela e índice criados por ele ocupem no máximo 500 M na tablespace USERS. Neste caso, eu poderia executar como DBA o comando
ALTER USER XPTOUSER QUOTA 500M ON USERS;
ALTER USER XPTOUSER QUOTA UNLIMITED ON USERS;GRANT UNLIMITED TABLESPACE TO XPTOUSERS;Quando você cria uma WORKSPACE, você mesmo assim precisa apontar para um SCHEMA de banco de dados (um schema é um usuário de BANCO que disponha de objectos criados nele - tabelas, sinonimos, views, etc).
Então, digamos que você criou no APEX:
- Workspace SISTEMA, apontando para o schema de banco XPTOUSER (este é um usuário de BANCO);
- Dois usuários (JOAO / ANTONIO) para esta Workspace SISTEMA (estes são usuários APEX);
Em teoria, qualquer objeto de banco criado com o usuário de XPTOUSER (BANCO) será visível para os usuários JOAO (APEX) e ANTONIO (APEX), não havendo necessidade de se criar nenhuma permissão adicional de banco.
Agora, digamos que você criou no APEX:
- Workspace SISTEMA2, apontando para o mesmo schema de banco XPTOUSER (este é um usuário de BANCO);
- Dois usuários (ZE / LUIS) para esta Workspace SISTEMA2 (estes são usuários APEX);
Os usuários APEX JOAO, ANTONIO, ZE e LUIS vão conseguir acessar as mesmas tabelas, pois elas pertencem ao mesmo schema XPTOUSER;
Vamos supor uma última atividade. Digamos que você criou :
- Workspace SISTEMA3, apontando para o schema de banco WXYZUSER (este é um usuário de BANCO);
- Dois usuários (ANA / MARIA) para esta Workspace SISTEMA3 (estes são usuários APEX);
Pelo fato de SISTEMA3 apontar para um schema DIFERENTE (WXYZUSER), ANA e MARIA não vão conseguir acessar as tabelas do schema XPTOUSER, enquanto que JOAO, ANTONIO, ZE e LUIS não vão conseguir acessar as tabelas do schema WXYZUSER.
Neste caso, como seria possível todos acessarem as tabelas de todos? Eu teria que entrar no banco como XPTOUSER e dar as permissões de acesso aos objetos de banco dele para o usuário de banco WXYZUSER. E deveria repetir o mesmo processo em WXYZUSER, atribuindo as permissões de acesso às tabelas dele para o XPTOUSER. Fora isso, deveria criar sinônimos privados em XPTOUSER e WXYZUSER, para que um pudesse consultar as tabelas um do outro sem a necessidade de informar o schema
ex:
SELECT * FROM XPTOUSER.TABELA_ATalvez este artigo abaixo (da oracle) lhe permita entender um pouco sobre permissões de BANCO de DADOS:
http://www.oracle.com/technetwork/pt/ar ... 6-ptb.html
Fora isso, seria interessante dar uma lida nos manuais do Oracle APEX, para verificar como seria possível você organizar as workspaces.
Abraços e tudo de bom,
Sergio Coutinho
Sérgio, você foi muito claro e me ajudou bastante.
Somente uma coisa não ficou clara, nem mesmo depois de ler o link enviado. Quando você fala em tablespace, está se referindo ao schema (usuário)?
Somente uma coisa não ficou clara, nem mesmo depois de ler o link enviado. Quando você fala em tablespace, está se referindo ao schema (usuário)?
Eu não consigo editar, então vou corrigir a minha pergunta acima.milhorini escreveu:Sérgio, você foi muito claro e me ajudou bastante.
Somente uma coisa não ficou clara, nem mesmo depois de ler o link enviado. Quando você fala em tablespace, está se referindo ao schema (usuário)?
tablespace é como se fosse um "pacote" (package Java) ou uma localização onde as suas tabelas serão colocadas após criadas? Se eu não especificar uma, por default, será usada USERS?
-
stcoutinho
- Moderador
- Mensagens: 850
- Registrado em: Qua, 11 Mai 2011 5:15 pm
- Localização: são Paulo - SP
Oi milhorini,
Um banco de dados é composto de DATAFILES, que são os arquivos do ORACLE no sistema operacional.
Abra uma sessão de banco como SYSTEM e execute este comando para ver os datafiles de seu banco:
Agora, uma TABLESPACE seria o conjunto de um ou mais DATAFILES.
É nas tablespaces que você armazena as TABELAS e os INDICES, por exemplo.
Abra uma sessão de banco como SYSTEM e execute este comando para ver os datafiles de seu banco:
Quando você cria um usuário no banco de dados, você pode atribuir a ele uma tablespace temporaria (geralmente de nome TEMP, onde o oracle pode fazer ordenações de registros) e uma tablespace DEFAULT, onde o usuário poderá criar as suas tabelas e índices. Estas informações você pode fornecer no momento da criação do usuário. Exemplo:
Você também pode criar o usuário sem estes parâmetros, mas tanto a área temporária como a tablespace DEFAULT para este usuário serão a tablespace SYSTEM (o que é uma péssima prática). A situação que eu lhe passei agora aconteceria se você fizesse:
No exemplo acima, você poderia alterar as propriedades deste usuário, atribuindo ao mesmo a tablespace temporária e a default. Exemplo:
Todos os comandos acima não bastam para você ter permissão para criar objetos no banco. Você precisa por exemplo dar permissões de CREATE SESSION, ALTER SESSION, QUOTA UNLIMITED ON, RESOURCE para o usuário XPTOUSER poder criar e gerenciar tabelas. É neste ponto que entra o artigo do link, que eu repassei para você.
Talvez eu não tenha lhe explicado de uma forma didática e no final desta conversa a quantidade de dúvidas que eu lhe proporcionei seja maior do que antes das aplicações. Seria legal verificar se consegue um livro introdutório em português sobre o ORACLE, onde estes conceitos de TABLESPACE, USER, ROLES, GRANTS são explicados em maiores detalhes. Você não precisa se aprofundar muito no entendimento destes temas .. somente o suficiente para conseguir interagir o APEX com o banco de dados.
O próprio APEX tem também os seus conceitos de USERS, WORKSPACES, que são somente formas de se permitir uma melhor organização de seus projetos no APEX. Se você criou uma WORKSPACE no APEX apontando para um usuário de banco de dados, abra uma sessão de banco com este usuário e consulte estas informações do dicionário de dados do APEX:
Enquanto que - para o banco de dados -você possui um outro dicionário de dados:
O APEX, se você for ver mais a fundo, é composto de uma série de tabelas de metadados onde seus projetos ficam armazenados. Ao executar o APEX, estes metadados são lidos, interpretados pelo APEX e transformados nas telas, relatórios e gráficos que você vê em suas aplicações.
Fique à vontade para continuar perguntando, se achar que precisa de mais alguma orientação.
Abraços,
Sergio Coutinho
Um banco de dados é composto de DATAFILES, que são os arquivos do ORACLE no sistema operacional.
Abra uma sessão de banco como SYSTEM e execute este comando para ver os datafiles de seu banco:
SELECT * FROM DBA_DATA_FILESÉ nas tablespaces que você armazena as TABELAS e os INDICES, por exemplo.
Abra uma sessão de banco como SYSTEM e execute este comando para ver os datafiles de seu banco:
SELECT * FROM DBA_TABLESPACESCREATE USER XPTOUSER IDENTIFIED BY Q1234R
TEMPORARY TABLESPACE TEMP
DEFAULT TABLESPACE USERS;CREATE USER XPTOUSER IDENTIFIED BY Q1234R; ALTER USER XPTOUSER TEMPORARY TABLESPACE TEMP;
ALTER USER XPTOUSER DEFAULT TABLESPACE USERS;Talvez eu não tenha lhe explicado de uma forma didática e no final desta conversa a quantidade de dúvidas que eu lhe proporcionei seja maior do que antes das aplicações. Seria legal verificar se consegue um livro introdutório em português sobre o ORACLE, onde estes conceitos de TABLESPACE, USER, ROLES, GRANTS são explicados em maiores detalhes. Você não precisa se aprofundar muito no entendimento destes temas .. somente o suficiente para conseguir interagir o APEX com o banco de dados.
O próprio APEX tem também os seus conceitos de USERS, WORKSPACES, que são somente formas de se permitir uma melhor organização de seus projetos no APEX. Se você criou uma WORKSPACE no APEX apontando para um usuário de banco de dados, abra uma sessão de banco com este usuário e consulte estas informações do dicionário de dados do APEX:
SELECT * FROM APEX_WORKSPACES
SELECT * FROM APEX_WORKSPACE_SCHEMAS
SELECT * FROM APEX_WORKSPACE_APEX_USERS
SELECT * FROM APEX_WORKSPACE_DEVELOPERS
SELECT * FROM APEX_WORKSPACE_GROUPS
SELECT * FROM APEX_WORKSPACE_GROUP_USERS
SELECT * FROM DBA_DATA_FILES
SELECT * FROM DBA_TABLESPACE
SELECT * FROM DBA_USERS
Fique à vontade para continuar perguntando, se achar que precisa de mais alguma orientação.
Abraços,
Sergio Coutinho
Entendi tudo o que você disse, Sérgio!
Antes de sua explicação, eu já tinha realizado muitos dos comandos que você passou. Anteriormente, eu tinha criado usuários no SQL PLUS sem passar o tablespace. Tinha tudo ficado no SYSTEM. Salvei todo o meu banco e fiz novamente. Aprendi ainda muita coisa no APEX.
Com relação às concessões, estou aplicando manualmente uma a uma. Às vezes, aplico connect e resource, revogando o unlimited tablespace.
Muito obrigado!
Wilson
Antes de sua explicação, eu já tinha realizado muitos dos comandos que você passou. Anteriormente, eu tinha criado usuários no SQL PLUS sem passar o tablespace. Tinha tudo ficado no SYSTEM. Salvei todo o meu banco e fiz novamente. Aprendi ainda muita coisa no APEX.
Com relação às concessões, estou aplicando manualmente uma a uma. Às vezes, aplico connect e resource, revogando o unlimited tablespace.
Muito obrigado!
Wilson
Sérgio...
Uma coisa que está me intrigando é o seguinte:
Criei dois usuários distintos em dois tablespaces também distintos no sql plus. No APEX, criei as áreas de trabalho baseados nesses tablespaces. Criei dois usuários APEX.
Um dos usuários possui o dba granted. O outro, não. Com isso, o primeiro usuário consegue acessar as tabelas do segundo, mas o segundo não consegue ver as tabelas do primeiro.
No SQL Developer, criei duas conexões baseados nos usuários que criei no banco. O problema é que o usuário do banco que não é dba está conseguindo acessar as tabelas do outro usuário.
Enquanto no APEX o comportamento é o desejado, no SQL Developer não o é. Por que isso está ocorrendo?
Loguei como DBA no APEX para lhe mostrar os privilégios que dei às contas na sua criação:
Esquemas do Espaço de Trabalho
Esquemas: WILSON
Tablespaces: WILSON, SYSTEM
Privilégios: create any directory, create materialized view, create procedure, create sequence, create session, create synonym, create table, create tablespace, create trigger, create user, create view, drop user
Privilégios de Atribuição do Banco de Dados: connect, dba, resource
Esquemas do Espaço de Trabalho
Esquemas: MILHORINI
Tablespaces: MILHORINI
Privilégios: create any directory, create materialized view, create procedure, create sequence, create session, create synonym, create table, create tablespace, create trigger, create user, create view, drop user
Privilégios de Atribuição do Banco de Dados: connect
Pode-se ver que o primeiro usuário está em dois tablespaces, mesmo eu tendo estabelecido a ele somente um. SYSTEM é por causa de ele ser dba?
PS: Em sublinhei uma das pergunta para ficar mais fácil de ver.
Wilson
Uma coisa que está me intrigando é o seguinte:
Criei dois usuários distintos em dois tablespaces também distintos no sql plus. No APEX, criei as áreas de trabalho baseados nesses tablespaces. Criei dois usuários APEX.
Um dos usuários possui o dba granted. O outro, não. Com isso, o primeiro usuário consegue acessar as tabelas do segundo, mas o segundo não consegue ver as tabelas do primeiro.
No SQL Developer, criei duas conexões baseados nos usuários que criei no banco. O problema é que o usuário do banco que não é dba está conseguindo acessar as tabelas do outro usuário.
Enquanto no APEX o comportamento é o desejado, no SQL Developer não o é. Por que isso está ocorrendo?
Loguei como DBA no APEX para lhe mostrar os privilégios que dei às contas na sua criação:
Esquemas do Espaço de Trabalho
Esquemas: WILSON
Tablespaces: WILSON, SYSTEM
Privilégios: create any directory, create materialized view, create procedure, create sequence, create session, create synonym, create table, create tablespace, create trigger, create user, create view, drop user
Privilégios de Atribuição do Banco de Dados: connect, dba, resource
Esquemas do Espaço de Trabalho
Esquemas: MILHORINI
Tablespaces: MILHORINI
Privilégios: create any directory, create materialized view, create procedure, create sequence, create session, create synonym, create table, create tablespace, create trigger, create user, create view, drop user
Privilégios de Atribuição do Banco de Dados: connect
Pode-se ver que o primeiro usuário está em dois tablespaces, mesmo eu tendo estabelecido a ele somente um. SYSTEM é por causa de ele ser dba?
PS: Em sublinhei uma das pergunta para ficar mais fácil de ver.
Wilson
-
stcoutinho
- Moderador
- Mensagens: 850
- Registrado em: Qua, 11 Mai 2011 5:15 pm
- Localização: são Paulo - SP
Oi milhorini ,
Eu lhe peço para fazer um teste no SQLPLUS.
Entendo que você criou dois usuários de BANCO. Só pra simplificar, vou chamar eles de USER_A e USER_B.
Vou também simplificar no tema tabelas: Usuário de banco USER_A tem a tabela TABELA_A e o usuário USER_B tem a tabela USER_B.
Desta forma, proceda com estes testes (que será feito exclusivamente no banco):
1) Abrir uma sessão no sql*plus como USER_A;
2) Execute o
3) Abrir uma sessão no sql*plus como USER_B;
4) Execute o
Se somente um deles é DBA e ou outro não, então um destes SELECT COUNT(*) daria algum erro.
Se este erro não acontecer no SQL*PLUS, então você precisa revisar as permissões atribuidas a cada um dos usuários.
Se este error ocorrer no SQL*PLUS, mas no SQL DEVELOPER não, então eu recomendo que revise as informações das conexões que você cadastrou no mesmo.
Publique os resultados destes testes neste tópico. Dependendo do caso, posso depois publicar aqui algumas queries para você revisar as permissões dos dois usuários.
Abraços,
Sergio Coutinho
Conecte-se como o usuário DBA e faça SELECT COUNT(*) em uma tabela
Eu lhe peço para fazer um teste no SQLPLUS.
Entendo que você criou dois usuários de BANCO. Só pra simplificar, vou chamar eles de USER_A e USER_B.
Vou também simplificar no tema tabelas: Usuário de banco USER_A tem a tabela TABELA_A e o usuário USER_B tem a tabela USER_B.
Desta forma, proceda com estes testes (que será feito exclusivamente no banco):
1) Abrir uma sessão no sql*plus como USER_A;
2) Execute o
SELECT COUNT(*) FROM USER_B.TABELA_B;4) Execute o
SELECT COUNT(*) FROM USER_A.TABELA_A;Se este erro não acontecer no SQL*PLUS, então você precisa revisar as permissões atribuidas a cada um dos usuários.
Se este error ocorrer no SQL*PLUS, mas no SQL DEVELOPER não, então eu recomendo que revise as informações das conexões que você cadastrou no mesmo.
Publique os resultados destes testes neste tópico. Dependendo do caso, posso depois publicar aqui algumas queries para você revisar as permissões dos dois usuários.
Abraços,
Sergio Coutinho
Conecte-se como o usuário DBA e faça SELECT COUNT(*) em uma tabela
Eu não estou conseguindo criar tabelas na conta que não é dba (conta milhorini).
Quando logo como system e atribuo à conta "milhorini" resources, a criação de tabelas é aceita. Quando revogo apenas o unlimited tablespace de "milhorini", dá o erro que o tablespace não há privilégios.
Tentei ver os privilégios dados à "milhorini" através de
e dá a mensagem de "tabela ou view não encontrada". O mesmo ocorre quando coloco 'CONNECT'. Com a conta "wilson" (dba) essas instruções funcionam.
Loguei como admin no APEX e vi que milhorini tem os privilégio connect e resource.
Não entendi esses erros. Você sabe por que eles estão ocorrendo?
Quando logo como system e atribuo à conta "milhorini" resources, a criação de tabelas é aceita. Quando revogo apenas o unlimited tablespace de "milhorini", dá o erro que o tablespace não há privilégios.
Tentei ver os privilégios dados à "milhorini" através de
select privilege from dba_sys_privs where grantee = 'RESOURCE'Loguei como admin no APEX e vi que milhorini tem os privilégio connect e resource.
Não entendi esses erros. Você sabe por que eles estão ocorrendo?
Estou conseguindo criar tabelas novamente. Li a documentação da Oracle e a 11g R2 tem uma peculiaridade. Quando eu crio um tablespace, eu lhe dou um tamanho. No caso do tablespace milhorini, eu lhe dei SIZE 25m AUTOEXTEND ON NEXT 25m EXTENT MANAGEMENT LOCAL;. Depois, atribuí o privilégio resource à "milhorini". Depois, revoguei esse privilégio.
De acordo com a documentação do R2, quando você atribui o privilégio resource, unlimited tablespace é dado também. Se você mais tarde remover resource, o tamanho do tablespace original (25M, no meu caso) se perde. Você tem que atribuir novamente através de alter user USUARIO quota QUOTA on TABLESPACE;
Por essa razão eu não estava conseguindo criar tabelas. Sei o que causou o impedimento de criação de tabelas, mas não sei o porquê.
Os comandos que geraram as mensagens de tabela ou view não encontrada se devem à conta "milhorini" não ser dba. Assim, dba_sys_privs não foi encontrada.
Se eu tiver falado algo errado, por favor, me corrija!
Wilson
De acordo com a documentação do R2, quando você atribui o privilégio resource, unlimited tablespace é dado também. Se você mais tarde remover resource, o tamanho do tablespace original (25M, no meu caso) se perde. Você tem que atribuir novamente através de alter user USUARIO quota QUOTA on TABLESPACE;
Por essa razão eu não estava conseguindo criar tabelas. Sei o que causou o impedimento de criação de tabelas, mas não sei o porquê.
Os comandos que geraram as mensagens de tabela ou view não encontrada se devem à conta "milhorini" não ser dba. Assim, dba_sys_privs não foi encontrada.
Se eu tiver falado algo errado, por favor, me corrija!
Wilson
-
stcoutinho
- Moderador
- Mensagens: 850
- Registrado em: Qua, 11 Mai 2011 5:15 pm
- Localização: são Paulo - SP
Olá milhorini ,
Eu recomendaria você a manter o GRANT de RESOURCE para os schemas onde você vai trabalhar com o APEX. Não se preocupe com a permissão de UNLIMITED TABLESPACE.
O importante é que seus usuários de banco consigam criar tabelas. Lembre-se que - para os usuários finais de sua aplicação APEX - não interessa como a WORKSPACE se encontrará organizada.
Eu recomendaria (por enquanto) adotar esta filosofia: crie uma WORKSPACE apontando para um único SCHEMA de banco de dados. Não sei se vale a pena você ficar criando uma série complexa de WORKSPACES e SCHEMAS neste momento.
Mantenha seu ambiente simples o suficiente, e que lhe permita desenvolver aplicações. Creio que isso seria o mais importante no momento, se o seu foco é desenvolver aplicações.
Você pode criar várias aplicações APEX na mesma WORKSPACE, todas elas acessando as tabelas do mesmo schema.
A aplicação APEX de uma WORKSPACE não entrará em conflito com outras aplicações da mesma WORKSPACE.
Se você quiser diferenciar as tabelas de um mesmo schema que servem a sistemas APEX diferentes, você pode adotar um tipo de nomenclatura para as tabelas.
Digamos que você tem um sistema de BACKUP e outro sistema de PERFORMANCE. Todas as tabelas estariam no mesmo schema, mas você poderia adotar o padrão "BAK_<nome_tabela>" para as do sistema de BACKUP e "PER_<nome_tabela>" para as do sistema de PERFORMANCE.
Com o tempo, você provavelmente vai avançar tanto em APEX como BANCO DE DADOS. Isso vai exigir de você um certo tempo para assimiliar todos estes conceitos. Geralmente estes conceitos de banco são obtidos em cursos de administração de banco de dados. Ou então, através de um pouco de auto-estudo, perguntas específicas neste forum, etc.
Então, em vez de quebrar a cabeça agora, você recomendaria que você focasse no desenvolvimento de aplicações APEX, deixando de lado - por um tempo - estas questões de organização de WORKSPACES, SCHEMAS e GRANTS. Mantenha seus ambientes simples neste momento. Mais tarde, você pode focar neste tema de organização.
Me desculpe se eu não entrar em detalhes sobre administração de banco de dados agora. Este assunto seria um pouco complexo de ser desbravado (em poucas palavras) neste tópico de APEX. Envolve alguns conceitos básicos para os quais são necessários um pouco de pesquisa, leitura de livros, etc.
Se tiver alguma questão pertinente de APEX que precise de explicações, por favor atualize o post.
Abraços e tudo de bom. Estou torcendo para você conseguir desenvolver suas primeiras aplicações em APEX. Como experiência pessoal, posso lhe dizer que penei um pouco no começo, mas com a vivência, constatei que o tempo de desenvolvimento para novas aplicações se reduziu consideravelmente.
Sergio Coutinho
Eu recomendaria você a manter o GRANT de RESOURCE para os schemas onde você vai trabalhar com o APEX. Não se preocupe com a permissão de UNLIMITED TABLESPACE.
O importante é que seus usuários de banco consigam criar tabelas. Lembre-se que - para os usuários finais de sua aplicação APEX - não interessa como a WORKSPACE se encontrará organizada.
Eu recomendaria (por enquanto) adotar esta filosofia: crie uma WORKSPACE apontando para um único SCHEMA de banco de dados. Não sei se vale a pena você ficar criando uma série complexa de WORKSPACES e SCHEMAS neste momento.
Mantenha seu ambiente simples o suficiente, e que lhe permita desenvolver aplicações. Creio que isso seria o mais importante no momento, se o seu foco é desenvolver aplicações.
Você pode criar várias aplicações APEX na mesma WORKSPACE, todas elas acessando as tabelas do mesmo schema.
A aplicação APEX de uma WORKSPACE não entrará em conflito com outras aplicações da mesma WORKSPACE.
Se você quiser diferenciar as tabelas de um mesmo schema que servem a sistemas APEX diferentes, você pode adotar um tipo de nomenclatura para as tabelas.
Digamos que você tem um sistema de BACKUP e outro sistema de PERFORMANCE. Todas as tabelas estariam no mesmo schema, mas você poderia adotar o padrão "BAK_<nome_tabela>" para as do sistema de BACKUP e "PER_<nome_tabela>" para as do sistema de PERFORMANCE.
Com o tempo, você provavelmente vai avançar tanto em APEX como BANCO DE DADOS. Isso vai exigir de você um certo tempo para assimiliar todos estes conceitos. Geralmente estes conceitos de banco são obtidos em cursos de administração de banco de dados. Ou então, através de um pouco de auto-estudo, perguntas específicas neste forum, etc.
Então, em vez de quebrar a cabeça agora, você recomendaria que você focasse no desenvolvimento de aplicações APEX, deixando de lado - por um tempo - estas questões de organização de WORKSPACES, SCHEMAS e GRANTS. Mantenha seus ambientes simples neste momento. Mais tarde, você pode focar neste tema de organização.
Me desculpe se eu não entrar em detalhes sobre administração de banco de dados agora. Este assunto seria um pouco complexo de ser desbravado (em poucas palavras) neste tópico de APEX. Envolve alguns conceitos básicos para os quais são necessários um pouco de pesquisa, leitura de livros, etc.
Se tiver alguma questão pertinente de APEX que precise de explicações, por favor atualize o post.
Abraços e tudo de bom. Estou torcendo para você conseguir desenvolver suas primeiras aplicações em APEX. Como experiência pessoal, posso lhe dizer que penei um pouco no começo, mas com a vivência, constatei que o tempo de desenvolvimento para novas aplicações se reduziu consideravelmente.
Sergio Coutinho
Sérgio...
Eu estou com uma conta que possui os seguintes privilégios: connect, resource e dba. Assim, essa conta é uma dba, correto? Com essa conta, eu não deveria ser capaz de acessar as tabelas dos demais usuários que se encontram em outras áreas de trabalho? Bem, eu não estou conseguindo acessar.
Abraço!
Wilson
Eu estou com uma conta que possui os seguintes privilégios: connect, resource e dba. Assim, essa conta é uma dba, correto? Com essa conta, eu não deveria ser capaz de acessar as tabelas dos demais usuários que se encontram em outras áreas de trabalho? Bem, eu não estou conseguindo acessar.
Abraço!
Wilson
O APEX não está permitindo que a conta dba acesse as tabelas da outra conta - que não é dba. Contudo, no SQL Developer e no SQL Plus o acesso está sendo permitido. Sabe o porquê?
Wilson
Wilson
-
stcoutinho
- Moderador
- Mensagens: 850
- Registrado em: Qua, 11 Mai 2011 5:15 pm
- Localização: são Paulo - SP
Oi milhorini,
Sinceramente não saberia, pois se um usuário de banco tem a permissão de DBA, então ele teria condições de ler qualquer tabela, DESDE que informe o OWNER da tabela
ex:
Caso deseje ver a tabela sem informar o OWNER, seria necessário criar um sinônimo privado.
Como expliquei anteriormente, tente criar um ambiente simples de desenvolvimento. Evite criar um ambiente complexo de muitos schemas ou workspaces. Ou você foca no desenvolvimento/estudo do APEX ou então você foca no estudo de administração de banco de dados (DBA).
Talvez outros foristas possam ter uma visão diferente deste problema.
Abraços,
Sergio Coutinho
Sinceramente não saberia, pois se um usuário de banco tem a permissão de DBA, então ele teria condições de ler qualquer tabela, DESDE que informe o OWNER da tabela
ex:
SELECT COUNT(*) FROM USER_B.TABELA_BComo expliquei anteriormente, tente criar um ambiente simples de desenvolvimento. Evite criar um ambiente complexo de muitos schemas ou workspaces. Ou você foca no desenvolvimento/estudo do APEX ou então você foca no estudo de administração de banco de dados (DBA).
Talvez outros foristas possam ter uma visão diferente deste problema.
Abraços,
Sergio Coutinho
-
stcoutinho
- Moderador
- Mensagens: 850
- Registrado em: Qua, 11 Mai 2011 5:15 pm
- Localização: são Paulo - SP
Olá milhorini,
Gostaria de sugerir dois livros bem interessante de administração de banco de dados:
ORACLE 10G
Autor: RAMALHO, JOSE ANTONIO ALVES
Editora: THOMSON PIONEIRA
http://www.livrariacultura.com.br
ORACLE DATABASE 10G EXPRESS EDITION - INTERATIVO
GUIA BASICO DE ORIENTAÇAO E DESENVOLVIMENTO
Autor: MANZANO, JOSE AUGUSTO N. G.
Editora: ERICA
O Ramalho vem editando livros de oracle desde a versão 8i. Pelos livros dele eu consegui aprender bastante coisa sobre a administração de banco de dados. Acho que seria útil para você avançar no tema de administração de banco e até mesmo programação PL/SQL, se este for o seu desejo.
Abraços,
Sergio Coutinho
Gostaria de sugerir dois livros bem interessante de administração de banco de dados:
ORACLE 10G
Autor: RAMALHO, JOSE ANTONIO ALVES
Editora: THOMSON PIONEIRA
http://www.livrariacultura.com.br
ORACLE DATABASE 10G EXPRESS EDITION - INTERATIVO
GUIA BASICO DE ORIENTAÇAO E DESENVOLVIMENTO
Autor: MANZANO, JOSE AUGUSTO N. G.
Editora: ERICA
O Ramalho vem editando livros de oracle desde a versão 8i. Pelos livros dele eu consegui aprender bastante coisa sobre a administração de banco de dados. Acho que seria útil para você avançar no tema de administração de banco e até mesmo programação PL/SQL, se este for o seu desejo.
Abraços,
Sergio Coutinho
-
- Informação
-
Quem está online
Usuários navegando neste fórum: Nenhum usuário registrado e 10 visitantes
