【问题标题】:Optimizing Oracle instances优化 Oracle 实例
【发布时间】:2009-03-20 02:02:20
【问题描述】:

我正在与一个开发适用于 SQL Server 和 Oracle 的应用程序的团队合作。

SQL Server 有一个实例的概念,它可以容纳多个数据库。 Oracle 10g 需要每个数据库一个实例(并且可以允许更多实例以实现冗余),因此对于我们运行的每个数据库,我们都有一组完全独立的进程,因此内存使用量要大得多。

正因为如此,我们开始更多地转向拥有一个具有单独架构的实例。但是,我们仍然希望将单独的客户(或开发机器)数据分开。

我们的大多数实例都是使用本地开发的脚本创建的(例如,Windows 上的 oradim)。

如何减少 Oracle 实例的内存使用要求、占用空间等,以便多个实例可以在一台机器上安全运行? Linux 或 Windows 是更好的主机吗?我们可以通过禁用我们不需要的额外功能(数据挖掘、Oracle Text 等)轻松获得收益吗?

【问题讨论】:

    标签: oracle


    【解决方案1】:

    恕我直言,内存对于Oracle 的性能最重要。

    运行多个数据库意味着保留多组缓存的SQLPL/SQL,系统表的多个数据缓存等。

    如果您只是需要将数据分开,您可以为不同的用户创建不同的TABLESPACES。不过,您仍然需要分享 LOGFILES

    禁用Data Mining 等额外功能对您没有多大帮助,因为它们在不使用时不会消耗内存。

    您当然需要降低任何内存值,但是如果没有看到您的数据库设计,就很难判断应该保留哪些以及需要降低哪些。

    作为一个非常不精确的经验法则,如果您有OLTP 数据库,即小表和高并发性,您可能应该牺牲sort_area_sizehash_area_size,但保留db_block_buffers 尽可能高。

    如果您有使用HASH JOINSMERGE JOINS 的大型表,则需要sort_area_sizehash_area_size 以实现高效的连接和排序,但您可以减少db_block_buffers,因为您将无法做到无论如何都要缓存这些表。

    LinuxWindowsOracle 性能方面没有太大区别。 Linux,不过,优雅 LOCK_SGAWindows 也尝试这样做,但可以在严重的内存条件下换出。

    【讨论】:

    • 也许我从 OP 那里得到了错误的印象,但我认为他可能想从调整不太细粒度的 MEMORY_TARGET 与各种细粒度参数(sort_area_size、hash_area_size ...)开始。调整 MEMORY_TARGET 可能会让他走得够远。
    • 我可以减少内存限制,但我希望我能够减少内存使用量,这样它就不会达到限制。 :) 我对所有建议持开放态度,如果简单的方法不起作用,我很乐意进一步深入研究。
    • 您是否尝试过使用这些参数? Oracle 预分配的 SGA 可能比您实际需要的更大。
    【解决方案2】:

    MEMORY_TARGET 是您在使用 Oracle 11g 时要设置的参数。

    http://download.oracle.com/docs/cd/B28359_01/server.111/b28320/initparams133.htm

    当您向同一服务器添加更多数据库实例时,您需要在所有其他实例上向下调整此参数,以免在服务器上使用过多内存并导致其交换。在 Oracle 10g 上,您设置 PGA_AGGREGATE_TARGET 和 SGA_TARGET。

    http://download.oracle.com/docs/cd/B19306_01/server.102/b14237/initparams157.htm

    不幸的是,您添加的 Oracle 实例越多,调优就越困难,系统也会变得越慢。

    我并没有太多关于 Windows 与 Linux 的信息。

    【讨论】:

      【解决方案3】:

      内存消耗将来自以下几个方面:

      1. 每个实例的 SGA
      2. 每会话 UGA、PGA(排序等)
      3. 杂项。上面未涵盖的其他每个进程的内存要求(例如,每个 oracle 进程使用的堆栈和堆,实际可执行映像使用的内存等)

      为了防止开发人员和客户破坏彼此的缓冲区缓存,1 的成本是值得的。那些不关心这些事情的实例应该被合并。

      您可以假设所有 RDBMS 以一种或另一种形式支付 2 的成本(并且仅取决于您的 RDBMS 的配置),因此这不是一种权衡。

      我估计,由于fork and page sharing,3 对 Linux 的影响最好减少,因此您只需为使用的内容付费。在现代 *nix 系统上,从 CPU 和内存的角度来看,fork-instead-of-multithreaded 方法非常高效,同时提供了许多其他优势(您几乎不必担心内存泄漏。)


      已经说过了,不要忘记来自 Windows 任务管理器或 top 的内存读数可能会因为“重复计算”而误导进程的实际内存消耗:共享内存段以及实际的 oracle 可执行文件和动态链接库的大小可以为每个进程计算,而实际上所有涉及的进程共享内存(并且只使用一次)。在 Unix 下使用“pmem”或“cat /proc//maps”来查看进程实际使用了多少内存以及共享了多少。

      【讨论】:

        【解决方案4】:

        如果您的主要目标是分离客户端数据,则无需运行多个实例。您可以实现两种类型的分离。通过将每个客户端放在单独的模式中,您已经实现了第一个逻辑分离。要物理分离数据,请为每个客户端创建一个表空间。表空间是一组实际的数据库文件。通过使用它们,您可以控制数据的物理存储位置。当您为客户端创建模式时,将客户端的表空间分配为“默认表空间”。

        除非您想在同一台服务器上运行不同版本的 Oracle,否则很少有理由启动多个实例。要充分利用您的单个实例,请尽可能多地在内存中获取它,并使用 TOAD 等工具或随附的 Oracle 工具来优化对各种 Oracle 进程的内存分配。

        【讨论】:

        • 我假设他需要单独的实例是出于某种原因(例如,在代码中无偿使用公共同义词),但我同意,每台服务器一个实例是最佳的。
        【解决方案5】:

        如果您有单独的架构,则您可以将不同客户的数据分开。为什么需要更多实例?每台机器一个实例最适合生产环境。

        对于开发环境,您可以做出不同的选择。但是开发环境和生产环境应该分开。

        【讨论】:

        • 我在发布最简单的帖子时忽略的一个明显原因是,我们可以继续使用“标准”应用程序用户和角色名称,而不必担心一个应用程序中的密码更改会影响其他应用程序(不幸的是,我们还集成了一个遗留的没有服务器组件的应用程序 - 它使用 Oracle 用户)。
        • 我不明白你的意思。什么是“标准”应用程序用户名?
        • 默认用户(或架构/角色)名称。例如,我们的旧应用程序仍然需要像 DOC 这样的(硬编码)角色,因此我们的脚本在每个数据库中创建该角色。该角色的用户可以访问其他模式中的数据,也被授予访问权限。我们会尽量使用 SCHEMA_DOC 角色。
        【解决方案6】:

        同意“每台服务器一个实例”的概念。 如果您想给予某些用户优先于其他用户的待遇或确保每个应用程序获得数据库的公平部分,请查看资源管理和配置文件。

        http://download.oracle.com/docs/cd/B19306_01/network.102/b14266/admusers.htm#i1012785
        
        http://download.oracle.com/docs/cd/B19306_01/server.102/b14200/statements_2007.htm#sthref4352
        
        http://download.oracle.com/docs/cd/B19306_01/server.102/b14231/dbrm.htm#ADMIN027
        

        将数据保存在单独的架构(以及物理级别的表空间)中应确保客户数据的适当分离。只要您不在模式之间共享表空间,使用导出和可传输表空间来提取和分离单个模式就变得(相对)微不足道,因此您可以在随后需要时在数据库(以及实例)之间移动它们他们在自己的服务器上。

        【讨论】:

          【解决方案7】:

          你可以给服务器增加内存吗?您可以花不到 1000 美元购买 32 GB 的内存。

          【讨论】:

            猜你喜欢
            • 1970-01-01
            • 2016-02-29
            • 1970-01-01
            • 1970-01-01
            • 2018-02-26
            • 2015-02-26
            • 2011-01-30
            • 1970-01-01
            • 1970-01-01
            相关资源
            最近更新 更多