Usuário novo não acessa.

#108236

Não uso essa GUI que vc mostra, então não faço Idéia do que representa essa tal “coluna com a password que fica cinza” – vou me ater ao core de banco, mesmo… Em cima disso : vc *** EXECUTOU *** no sql*plus, com um usuário privilegiado (pode ser o SYSDBA) o script que mostrei e que lista as permissões, uma vez para um usuário que “funciona” e uma vez para o usuário recém-criado em busca de Quaisquer diffs, e CONSULTOU a DBA_USERS pra ver qual o PROFILE assignado pros dois usuários e o status deles, tipo :

==> check do usuário HR :

SQL> select profile, account_status, lock_date, expiry_date, external_name, default_tablespace, temporary_tablespace from dba_users where username=’HR’;

PROFILE ACCOUNT_STATUS LOCK_DATE EXPIRY_DA EXTERNAL_NAME DEFAULT_TABLESPACE TEMPORARY_TABLESPACE


DEFAULT OPEN USERS TEMP

SQL> @D:dba_scriptsprivs_by_user
Enter Username : HR
Roles granted to user

GRANTED_ROLE ADM DEF


CONNECT NO YES
RESOURCE NO YES

Table Privileges granted to a user through roles

no rows selected

System Privileges assigned to a user through roles

GRANTED_ROLE PRIVILEGE


CONNECT CREATE SESSION
RESOURCE CREATE CLUSTER
RESOURCE CREATE INDEXTYPE
RESOURCE CREATE OPERATOR
RESOURCE CREATE PROCEDURE
RESOURCE CREATE SEQUENCE
RESOURCE CREATE TABLE
RESOURCE CREATE TRIGGER
RESOURCE CREATE TYPE

9 rows selected.

Table privileges assigned directly to a user

OWNER TABLE_NAME PRIVILEGE


SYS DBMS_STATS EXECUTE

System privileges assigned directly to a user

PRIVILEGE ADM


ALTER SESSION NO
CREATE DATABASE LINK NO
CREATE SEQUENCE NO
CREATE SESSION NO
CREATE SYNONYM NO
CREATE VIEW NO
UNLIMITED TABLESPACE NO

7 rows selected.

SQL>

==> check do usuário SCOTT :

SQL> select profile, account_status, lock_date, expiry_date, external_name, default_tablespace, temporary_tablespace from dba_users where username=’SCOTT’;

PROFILE ACCOUNT_STATUS LOCK_DATE EXPIRY_DA EXTERNAL_NAME DEFAULT_TABLESPACE TEMPORARY_TABLESPACE


DEFAULT OPEN 27-DEC-16 USERS TEMP

SQL>

SQL> @D:dba_scriptsprivs_by_user
Enter Username : SCOTT
Roles granted to user

GRANTED_ROLE ADM DEF


CONNECT NO YES
RESOURCE NO YES
RL_SIST NO YES

Table Privileges granted to a user through roles

no rows selected

System Privileges assigned to a user through roles

GRANTED_ROLE PRIVILEGE


CONNECT CREATE SESSION
RESOURCE CREATE CLUSTER
RESOURCE CREATE INDEXTYPE
RESOURCE CREATE OPERATOR
RESOURCE CREATE PROCEDURE
RESOURCE CREATE SEQUENCE
RESOURCE CREATE TABLE
RESOURCE CREATE TRIGGER
RESOURCE CREATE TYPE
RL_SIST CREATE ANY TABLE

10 rows selected.

Table privileges assigned directly to a user

no rows selected

System privileges assigned directly to a user

PRIVILEGE ADM


CREATE SESSION NO
UNLIMITED TABLESPACE NO

====> Com as consultas acima fica fácil de ver as diferenças em termos de permissão, como a ROLE DEFAULT chamada RL_SIST que o SCOTT tem e o HR não, o privilégio de ALTER SYSTEM que só um dos dois tem, etc….. AGORA, se vc *** EXECUTOU DIREITINHO *** as consultas e não achou NENHUMA DIFERENçA, posso te ASSEGURAR que não é NADA A VER com o banco de dados, os privilégios DO USUÀRIO no banco de dados estão OK – nesse caso vc vai ter que :

a) verificar se os objetos a nível de banco, como TRIGGERs e DBLINKs, estão corretamente criados nos dois bancos

E

b) DEBUGAR A APLICAÇÂO, para ver se há, digamos, alguma tabela de usuários que precise ser preenchida, ou coisa assim….

[]s

Chiappa

plugins premium WordPress