我的Oracle DBA需要root权限吗？

• 谁在服务器上安装Oracle？
  如果是DBA，则需要root权限。 如果是系统pipe理员，则DBA不会。

• 谁在数据库服务器closures时深夜被调用？
  如果您无法确保系统pipe理员全天候可用，则可能需要授予对数据库pipe理员的root权限。

请记住，如果您的DBA已经拥有作为普通用户的shell访问权限（有或没有某些命令，他可以通过sudo运行，无论是否被chrooted）足以混淆服务器（一个坏人窃取他的帐户可以叉炸弹，超过ulimit发送垃圾邮件，删除数据库，…）。

由于所有这些原因，我认为在一个理想的世界中DBA不应该有root权限 ; 但在现实世界中，至less应该始终能够在紧急情况下获得。

一般来说（而不是特定于DBA），任何需要root访问而没有提供有效理由的人都是：

1. 有人不知道他们在做什么。
2. 傲慢与不合作。
3. 以上两者。

现在，他们需要root权限来处理他们的任务可能有真正的原因，但是如果他们不能解释为什么写成，我就不会去处理它们。 处理服务器的专业人士理解和尊重边界。 谁知道足够的麻烦相信这些规则适用于每个人，除了他们。

如果我不得不与这样的人打架，我坚持提前安排时间，以便我可以在服务器上与他们一起处理问题。 这实际上运作良好。

另一个可能的select – 可能不实际 – 就是创build一个确切的服务器克隆，并为其提供root访问权限。 当然，请务必将密码更改为特定的密码。 让他们炸毁一个孤立的发展箱子。

但总的来说，如果你是深夜打电话来清理这个家伙可能造成的混乱，那么你完全有权利对root访问进行一揽子请求。

理论上DBA可以在没有root权限的情况下工作，但是双方都是PITA。 定义可通过sudo访问的命令列表实际上是不可能的。

如果出现以下情况，请授予DBA root权限

• 你不想在半夜醒来，只是重新启动服务器
• 你想快速顺利的事件pipe理
• 如果您的服务器仅用于数据库服务器

数据库pipe理员通常需要root权限：内核参数调整（sysctl），存储操作，问题调查。

正确的试镜确保了比严格定义的安全规则更好的运行条件。 如果你执行审计，你总是可以问为什么他们做了/改变了一些东西。 如果你没有审计，你也没有安全。

EDITED

这是一个独立的（非集群安装）

• 内核参数

  • 内存相关（大/巨大页面configuration，共享RAM（ipcs），不可交换（locking）RAM）
  • networking相关（发送/接收窗口大小，TCP保持活动）
  • 存储相关（打开文件的数量，asynchronousIO）

  可能有大约15-20个sysctl参数。 对于他们每个人来说，Oracle提供了一个推荐值或一个等式。 对于一些参数，推荐的方程可以随时间变化（aync io），或者在某些情况下，Oracle为相同的参数提供了多个方程。

• 存储：Linux的udev规则不能保证启动持久的设备名称。 因此Oracle提供了内核驱动程序和工具（AsmLib）。 这些允许你以root身份“标记”物理分区，然后在pipe理数据库存储时可以看到这些标签
• 问题调查：
  • 当数据库崩溃，因为它不能打开更多的文件句柄，那么唯一的解决办法是增加内核限制，执行“sysctl -p”，然后启动数据库。
  • 另外，当您发现物理RAM太碎片化，数据库无法分配大页面时，唯一的select是重启服务器。
  • （DCD） – 死连接检测。 例如在AIX上，netstat不打印PID。 如何将TCP连接与PID配对的唯一方法是内核debugging器。
  • 一目了然（在HP-UX上类似于顶级）需要root权限
  • 各种Veritas级别的调查
  • 和许多其他许多人

这个由你决定，在这个问题解决之前，你会浪费多less时间。 我只是想指出，强有力的angular色分离可以是非常昂贵的一些情况。 所以不要把“安全”的重点放在减less风险和危险上。 这是不一样的。 像ttysnoop或shell spy这样的工具允许你“logging”整个ssh会话，因此它们被授予了不可否认的地位。 这可以比sudo更好地服务。