l'exécution du script Oracle

Question

J'utilise Oracle SQL Developer

J'ai un énorme script qui crée des tables, des index, des contraintes de clé primaire et autres.

mon nom de DB est: dbo_other

Je me suis connecté dans ce dbo_other comme sysdba.

Si je lance mon script, puis les tables ne se présentent pas sur le panneau gauche sous la rubrique « Tableaux »

Cependant, si je joins le script en ajoutant « dbo_other. » devant chaque nom de table, puis les tables apparaissent.

Ceci est très fastidieux et prend du temps.

Y at-il un moyen d'éviter cela? pourquoi l'habitude ils apparaissent dans dbo_other sans ajouter dbo_other. devant chaque nom de la table ?? Quand je lance la requête sur le coin supérieur droit de la chute a sélectionné vers le bas dbo_other !!

Je peux même faire un select * de la table créée (mais ne le voyez pas dans la barre latérale gauche) De plus, je peux voir la table développeur pl / sql.

Pourquoi veut développeur sql oracle moi de créer avec dbo_other. ??

Aussi, est-il un moyen d'éviter d'ajouter pour chaque table? peut-être quelque chose peut être fait sur le dessus du script il prend effet sur tout ce qui suit?

Answer 1

Pourquoi vous connectez à votre base de données en utilisant le compte SYSDBA? Ceci est très puissant, et il vous permettra de faire des dégâts terribles à votre base de données si vous ne savez pas ce que vous faites. Dans un environnement de développement, il y a une limite au mal que vous pouvez le faire, mais il est préférable d'entrer dans de bonnes habitudes avant de faire les choses dans la production.

La chose intéressante à propos de AS SYSDBA est qu'elle l'emporte sur la partie nom d'utilisateur de la connexion:. Si l'utilisateur du système d'exploitation a les privilèges, vous êtes dans SYS. Check it out:

SQL> conn apc
Enter password:
Connected.
SQL> show user
USER is "APC"
SQL> conn apc as sysdba
Enter password:
Connected.
SQL> show user
USER is "SYS"
SQL>

Alors, quand vous avez exécuté ce script que vous avez créé tous ces objets dans le schéma SYS. Ce qui se révélera être une douleur énorme dans le cou. J'espère que vous avez un script de réversion égale et opposée.

Pour exécuter le script correctement, tout ce que vous devez faire est de se connecter comme DBO_OTHER (normal - à savoir sans SYSDBA ou SYSOPER qui est la valeur par défaut après tout). Votre script crée des tables dans le schéma actuel.

Si vous avez besoin pour créer des objets dans plusieurs schémas, vous n'avez pas besoin de vous déconnecter et à nouveau. Le schéma est distinct de l'utilisateur et il est possible de changer de schéma en exécutant alter session set current schema = WHOEVR;. Ceci est tout à fait un truc à portée de main et je blogué en place il y a quelque temps. Pour en savoir plus .

Notez que votre utilisateur ne peut acquérir des privilèges supplémentaires en modifiant le schéma actuel: ils ne pourront faire ce qu'ils peuvent en faire. Donc, pour quelque chose comme la création d'objets dans plusieurs schémas à l'utilisateur d'exécution doit être un utilisateur de pouvoir, quelqu'un avec CREATE des privilèges comme un DBA (mais toujours pas SYSDBA).

Answer 2

Je viens de tombé sur ce petit bijou qui vous permet d'effectuer des actions sur un schéma / utilisateur par défaut pour lequel vous n'êtes pas connecté en tant que. C'est, par défaut, vos instructions select, etc fonctionneront sur ce nouveau schéma au lieu de votre propre.

modifier la session ensemble current_schema =

Exemple: Moi même + table1 + table2 Quelqu'un d'autre + SuperTable1 + SuperTable2

log in as "Myself" 
select * from SuperTable1

Error: ORA-00942: table or view does not exist

alter session set current_schema = SomeoneElse 
select * from SuperTable1 <This will work.>

Answer 3

Les « tableaux » arbre sur le panneau gauche ne comprend que les tables du utilisateur connecté possède dans Oracle SQL Developer. Si votre script crée des tables dans le schéma d'un autre utilisateur, vous devez cliquer sur le + à côté de « autres utilisateurs », trouver l'utilisateur approprié, puis cliquez sur le + sur leurs tables.

Comme d'autres l'ont dit, vous ne devriez pas utiliser SYSDBA sauf si vous avez besoin, et il ressemble beaucoup à votre script doit être exécuté en tant qu'utilisateur normal en fonction de sa description sommaire.