当前位置：文江博客话题详情

Oracle运行脚本

发布于 2024-08-06 13:28:24 字数 519 浏览 9 评论 0原文

我正在使用 Oracle Sql Developer

我有一个巨大的脚本，可以创建表、索引、主键约束等。

我的数据库名称是：dbo_other

我以 sysdba 身份登录到此 dbo_other。

如果我运行脚本，则表格不会显示在左侧面板的“表格”下，

但是，如果我通过添加“dbo_other”来附加脚本。在每个表名称的前面，然后表就会显示出来。

这是非常乏味且耗时的。

有办法避免这种情况吗？为什么在不添加 dbo_other 的情况下它们不会出现在 dbo_other 中？每个表名前面？？当我在右上角运行查询时，下拉菜单已选择 dbo_other！

我什至可以从创建的表中执行 select * （但在左侧边栏中看不到它）此外，我可以在 pl/sql Developer 中看到该表。

为什么oracle sql开发人员希望我用dbo_other创建它？？

另外，有没有办法避免为每个表添加它？也许可以在脚本之上做一些事情，以便它对接下来的所有内容生效？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

╰◇生如夏花灿烂 2024-08-13 13:28:24

为什么使用SYSDBA帐户登录数据库？这是非常强大的，如果您不知道自己在做什么，它将使您对数据库造成严重损坏。在开发环境中，您所能造成的危害是有限的，但最好在生产环境中进行操作之前养成良好的习惯。

AS SYSDBA 的有趣之处在于它会覆盖登录的用户名部分：如果您的操作系统用户具有权限，那么您就可以登录。检查一下：

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>

因此，当您运行该脚本时，您在 SYS 模式中创建了所有这些对象。这将证明是颈部的巨大疼痛。我希望你有一个相等且相反的回归脚本。

要正确运行脚本，您所需要做的就是以 DBO_OTHER 身份连接（正常 - 即没有 SYSDBA 或 SYSOPER，毕竟这是默认设置）。您的脚本将在当前架构中创建表。

如果您需要在多个模式中创建对象，则无需注销并再次登录。该架构与用户不同，可以通过执行alter session set current schema = WHOEVR;来切换架构。这是一个非常方便的技巧，我不久前将其发布在博客上。了解更多。

请注意，您的用户不会通过更改当前架构来获得任何额外的权限：他们将只能执行当前可以执行的操作。因此，对于在多个模式中创建对象之类的操作，执行用户应该是高级用户，即具有 CREATE ANY 权限的人，例如 DBA（但仍然不是 SYSDBA）。

Why are you logging in to your database using the SYSDBA account? This is very powerful, and it will allow you to do terrible damage to your database if you don't know what you're doing. In a development environment there's a limit to the harm you can do but it's best to get into good habits before doing things in Production.

The interesting thing about AS SYSDBA is that it overrides the username part of the login: if your OS user has the privileges, you're in. As 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>

So, when you ran that script you created all those objects in the SYS schema. Which will prove to be a massive pain in the neck. I hope you have an equal and opposite reversion script.

To run the script properly, all you need to do is connect as DBO_OTHER (normal - i.e. without SYSDBA or SYSOPER which is the default after all). Your script will create tables in the current schema.

If you need to create objects in several schemas, you don't need to log out and in again. The schema is distinct from the user and it is possible to switch schema by executing alter session set current schema = WHOEVR;. This is quite a handy trick and I blogged it up some time back. Find out more.

Note that your user will not acquire any additional privileges by changing the current schema: they will only be able to do what they currently can do. So for something like creating objects in multiple schemas the executing user should be a power user, somebody with CREATE ANY privileges such as a DBA (but still not SYSDBA).

回复收藏 0 原文

心是晴朗的。 2024-08-13 13:28:24

我刚刚偶然发现了这个小 jem，它允许您默认对您未登录的模式/用户执行操作。也就是说，默认情况下，您的 select 语句等将在这个新模式而不是您自己的模式上运行。

更改会话集 current_schema =

示例：
我
+ 表1
+ 表2
别人
+ 超级表1
+ 超级表2

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.>

I just stumbled upon this little jem which lets you perform actions on a schema/user by default for which you are not logged in as. That is, by default your select statements, etc will operate on this new schema instead of your own.

alter session set current_schema =

Example:
Myself
+ table1
+ table2
SomeoneElse
+ 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.>

回复收藏 0 原文