精华内容
下载资源
问答
  • oracle 内存优化

    2013-03-20 17:29:38
    oracle 内存分配和优化,充分利用资源
  • 该论文详细的描述了Oracle数据库内存优化配置策略、数据库缓冲区、重做日志缓冲区等。
  • oracle 内存优化

    千次阅读 2014-08-13 19:24:52
    oracle 内存优化 oracle内存可以按照共享和私有的角度分为系统全局区和进程全局区 SGA和PGA 对于SGA部分,我们通过sqlplus 中查询可以看到: SQL> select * from v$sga; NAME VALUE -------------------...
    

    oracle 内存的优化

    oracle 的内存可以按照共享和私有的角度分为系统全局区和进程全局区 SGA和PGA

    对于SGA部分,我们通过sqlplus 中查询可以看到:

    SQL> select * from v$sga;

    NAME                      VALUE

    -------------------- ----------

    Fixed Size              1222192

    Variable Size         289409488

    Database Buffers      545259520

    Redo Buffers            2969600

    其中:

    Fixed Size:存储了SGA 各部分组件的信息,可以看作引导建立SGA的区域。

    Variable Size:包含了shared_pool_size、java_pool_size、large_pool_size 等内存设置

    Database Buffers:

    指数据缓冲区,在8i 中包含db_block_buffer*db_block_size、buffer_pool_keep、

    buffer_pool_recycle 三部分内存。在9i 中包含db_cache_size、db_keep_cache_size、

    db_recycle_cache_size、db_nk_cache_size。

    Redo Buffers:

    指日志缓冲区,log_buffer。在这里要额外说明一点的是,对于v$parameter、v$sgastat、

    v$sga查询值可能不一样。v$parameter 里面的值,是指用户在初始化参数文件里面设置

    的值,v$sgastat是oracle 实际分配的日志缓冲区大小(因为缓冲区的分配值实际上是离

    散的,也不是以block 为最小单位进行分配的),v$sga 里面查询的值,是在oracle 分配

    了日志缓冲区后,为了保护日志缓冲区,设置了一些保护页,通常我们会发现保护页大小大

    约是11k(不同环境可能不一样)。参考如下内容

    SQL> select substr(name,1,10) name,substr(value,1,10) value

      2  from v$parameter where name = 'log_buffer';

    NAME                 VALUE

    -------------------- --------------------

    log_buffer           2923520

    SGA的大小:

    设置SGA时要问自己的几个问题

    一:物理内存多大

    二:操作系统估计需要使用多少内存

    三:数据库是使用文件系统还是裸设备

    四:有多少并发连接

    五:应用是OLTP 类型还是OLAP 类型

    1。物理内存好确定

    2。操作系统一般使用256m

    3。文件系统比较大,raw不用考虑

    4。并发数由pga决定

    5对于OLTP类型oracle 倾向于可使用MTS,对于OLAP 类型使用独立模式,同时OLAP 还可能涉及到大

    量的排序操作的查询,这些都影响到我们内存的使用。那么所有的问题综合起来,实际上主

    要反映在UGA的大小上。UGA主要包含以下部分内存设置

    SQL> show parameters area_size;

    NAME                                 TYPE        VALUE

    ------------------------------------ ----------- ------------------------------

    bitmap_merge_area_size               integer     1048576

    create_bitmap_area_size              integer     8388608

    hash_area_size                       integer     1048576

    sort_area_size                       integer     524288

    workarea_size_policy                 string      AUTO

    在1G 的内存的服务器上,我们能分配给SGA 的内存大约为400—500M。若是2G 的内存,大约可以分到1G

    的内存给SGA,8G 的内存可以分到5G的内存给SGA。当然我们这里是以默认的排序部分

    内存sort_area_size=64k进行衡量的,假如我们需要调大该参数和hash_area_size等参数,然

    后我们应该根据并发的进程的数量,来衡量考虑这个问题。

    注:事实上,通常我们更习惯通过直观的公式化来表达这样的问题:

    OS使用内存+SGA+并发执行进程数*(sort_area_size+hash_ara_size+2M) < 0.7*总内存

    在我们的实际应用中,假如采用的是裸设备,我们可适当的增大SGA(如果需要的话)。

    由于目前几乎所有的操作系统都使用虚拟缓存,所以实际上如果就算SGA 设置的比较大也

    不会导致错误,而是可能出现频繁的内存页的换入与换出(page in/out)。在操作系统一级如

    果观察到这个现象,那么我们就需要调整内存的设置。

    SGA参数说明

    Log_buffer

    对于日志缓冲区的大小设置,通常我觉得没有过多的建议,因为参考LGWR写的触发

    条件之后,我们会发现通常超过3M意义不是很大。作为一个正式系统,可能考虑先设置这

    部分为log_buffer=1—3M 大小,然后针对具体情况再调整。

    Large_pool_size(大型池)

    对于大缓冲池的设置,假如不使用MTS(Multi-Threaded Server),建议在20—30M 足够了。这部分主要用来

    保存并行查询时候的一些信息,还有就是RMAN 在备份的时候可能会使用到。如果设置了

    MTS,则由于UGA部分要移入这里,则需要具体根据server process数量和相关会话内存参

    数的设置来综合考虑这部分大小的设置。

    Java_pool_size(JAVA池)

    假如数据库没有使用JAVA,我们通常认为保留10—20M大小足够。事实上可以更少

    甚至最少只需要32k,但具体跟安装数据库的时候的组件相关(比如http server)。

    shared_pool_size(共享池)

    于是我们假定一个1G内存的系统,可能考虑设置该参数为100M,

    2G 的系统考虑设置为150M,8G 的系统可以考虑设置为200—300M。

    Data buffer

    现在我们来谈数据缓冲区,在确定了SGA 的大小并分配完了前面部分的内存后,其余

    的,都分配给这部分内存。通常,在允许的情况下,我们都尝试使得这部分内存更大。这部

    分内存的作用主要是缓存 DB BLOCK,减少甚至避免从磁盘上获取数据,在8i中通常是由

    db_block_buffers*db_block_size 来决定大小的。如果我们设置了buffer_pool_keep 和

    buffer_pool_recycle,则应该加上后面这两部分内存的大小。

    PGA 的调整

     关于内存参数的调整:

     对于内存的调整,相对来说简单一些,我们首先可以针对数据缓冲区的大小来看。首先

    观察命中率:

    SQL> select value from v$sysstat where name ='physical reads';

         VALUE

    ----------

          7086

    SQL> select value from v$sysstat where name ='physical reads direct';

         VALUE

    ----------

            15

    SQL> select value from v$sysstat where name ='physical reads direct (lob)';

         VALUE

    ----------

             0

    SQL> select value from v$sysstat where name ='consistent gets';

         VALUE

    ----------

         77894

    SQL> select value from v$sysstat where name = 'db block gets';

         VALUE

    ----------

         11138

    这里命中率的计算应该是

    令 x = physical reads direct + physical reads direct (lob)

    命中率 =100 - ( physical reads - x) / (consistent gets + db block gets - x)*100

    通常如果发现命中率低于90%,则应该调整应用可可以考虑是否增大数据缓冲区

    共享池的命中率:

    SQL> select sum(pinhits-reloads)/sum(pins)*100 "hit radio" from v$librarycache;

     hit radio

    ----------

    87.1601668

    假如共享池的命中率低于95%,就要考虑调整应用(通常是没使用bind var )或者增加内存

    show parameter shared_pool_size;

    调整shared_pool_size 大小

    关于排序部分:

    SQL> select name,value from v$sysstat where name like '%sort%';

    NAME                                                                  VALUE

    ---------------------------------------------------------------- ----------

    sorts (memory)                                                         3110

    sorts (disk)                                                              0

    sorts (rows)                                                          15703

    假如我们发现sorts (disk)/ (sorts (memory)+ sorts (disk))的比例过高,则通常意味着

    sort_area_size 部分内存较小,可考虑调整相应的参数。

    关于log_buffer:

    SQL> select name,value from v$sysstat

      2  where name in('redo entries','redo buffer allocation retries');

    NAME                                                                  VALUE

    ---------------------------------------------------------------- ----------

    redo entries                                                            668

    redo buffer allocation retries                                            0

    假如 redo buffer allocation retries/ redo entries 的比例超过1%我们就可以考虑增大log_buffer

     32bit 和 64bit 的问题

    对于oracle 来说,存在着32bit与64bit的问题。这个问题影响到的主要是SGA的大小。

    在32bit的数据库下,通常oracle只能使用不超过1.7G的内存,即使我们拥有12G的内存,

    但是我们却只能使用1.7G,这是一个莫大的遗憾。假如我们安装64bit的数据库,我们就可以

    使用很大的内存,我们几乎不可能达到上限。但是64bit 的数据库必须安装在64bit 的操作

    系统上,可惜目前windows 上只能安装32bit的数据库,我们通过下面的方式可以查看数据

    库是32bit 还是64bit:

    SQL> select * from v$version;

    ————————————————————————————————————————————

    前言

    近来公司技术,研发都在问我关于内存参数如何设置可以优化oracle的性能,所以抽时间整理了这篇文档,以做参考.

    目的

    希望通过整理此文档,使大家对oracle内存结构有一个全面的了解,并在实际的工作中灵活应用,使oracle的内存性能达到最优配置,提升应用程序反应速度,并进行合理的内存使用.

    内容

    实例结构

    oracle实例=内存结构+进程结构

    oracle实例启动的过程,其实就是oracle内存参数设置的值加载到内存中,并启动相应的后台进程进行相关的服务过程。

    进程结构

    oracle进程=服务器进程+用户进程

    几个重要的后台进程:

    DBWR:数据写入进程.

    LGWR:日志写入进程.

    ARCH:归档进程.

    CKPT:检查点进程(日志切换;上一个检查点之后,又超过了指定的时间;预定义的日志块写入磁盘;例程关闭,DBA强制产生,表空间offline)

    LCKn(0-9):封锁进程.

    Dnnn:调度进程.

    内存结构(我们重点讲解的)

    内存结构=SGA(系统全局区)+PGA(程序全局区)

    SGA:是用于存储数据库信息的内存区,该信息为数据库进程所共享。它包含Oracle 服务器的数据和控制信息,它是在Oracle服务器所驻留的计算机的实际内存中得以分配,如果实际内存不够再往虚拟内存中写

    我们重点就是设置SGA,理论上SGA可占OS系统物理内存的1/2——1/3

    原则:SGA+PGA+OS使用内存<总物理RAM

    SGA=((db_block_buffers*blocksize)+(shared_pool_size+large_pool_size+java_pool_size+log_buffers)+1MB

    1、SGA系统全局区.(包括以下五个区)

    A、数据缓冲区:(db_block_buffers)存储由磁盘数据文件读入的数据。

    大小: db_block_buffers*db_block_size

    Oracle9i设置数据缓冲区为:Db_cache_size

    原则:SGA中主要设置对象,一般为可用内存40%。

    B、共享池:(shared_pool_size):数据字典,sql缓冲,pl/sql语法分析.加大可提速度。

    原则:SGA中主要设置对象,一般为可用内存10%

    C、日志缓冲区:(log_buffer)存储数据库的修改信息.

    原则:128K ---- 1M 之间,不应该太大

    D 、JAVA池(Java_pool_size)主要用于JAVA语言的开发.

    原则:若不使用java,原则上不能小于20M,给30M通常就够了

    E、 大池(Large_pool_size) 如果不设置MTS,主要用于数据库备份恢复管理器RMAN。

    原则:若不使用MTS,5---- 10M 之间,不应该太大

    SGA=. db_block_buffers*db_block_size+ shared_pool_size+ log_buffer+Java_pool+size+large_pool_size

    原则: 达到可用内存的55-58%就可以了.

    2、PGA程序全局区

    PGA:包含单个服务器进程或单个后台进程的数据和控制信息,与几个进程共享的SGA 正相反PGA 是只被一个进程使用的区域,PGA 在创建进程时分配在终止进程时回收.

    A、Sort_area_size 用于排序所占内存

    B、Hash_area_size 用于散列联接,位图索引

    这两个参数在非MTS下都是属于PGA ,不属于SGA,是为每个session单独分配的,在我们的服务器上除了OS + SGA,一定要考虑这两部分原则:OS 使用内存+SGA+并发执行进程数*(sort_area_size+hash_ara_size+2M) < 0.7*总内存

    实例配置

    一:物理内存多大

    二:操作系统估计需要使用多少内存

    三:数据库是使用文件系统还是裸设备

    四:有多少并发连接

    五:应用是OLTP 类型还是OLAP 类型

    基本掌握的原则是, db_block_buffer 通常可以尽可能的大,shared_pool_size 要适度,log_buffer 通常大到几百K到1M就差不多了

    A、如果512M RAM 单个CPU db_block_size 是8192 bytes

    SGA=0.55*512M=280M左右

    建议 shared_pool_size = 50M, db_block_buffer* db_block_size = 200M具体: shared_pool_size =52428800 #50M

    db_block_buffer=25600 #200M

    log_buffer = 131072 # 128k (128K*CPU个数)

    large_pool_size=7864320 #7.5M

    java_pool_size = 20971520 # 20 M

    sort_area_size = 524288 # 512k (65k--2M)

    sort_area_retained_size = 524288 # MTS 时 sort_area_retained_size = sort_area_size

    B、如果1G RAM 单个CPU db_block_size 是8192 bytes

    SGA=0.55*1024M=563M左右建议 shared_pool_size = 100M , db_block_buffer* db_block_size = 400M具体: shared_pool_size=104857600 #100M

    db_block_buffer=51200 #400M

    log_buffer = 131072 # 128k (128K*CPU个数)

    large_pool_size=15728640 #15M

    java_pool_size = 20971520 # 20 M

    sort_area_size = 524288 # 512k (65k--2M)

    sort_area_retained_size = 524288 # MTS 时 sort_area_retained_size = sort_area_size

    C、如果2G 单个CPU db_block_size 是8192 bytes

    SGA=0.55*2048M=1126.4M左右建议 shared_pool_size = 200M , db_block_buffer *db_block_size = 800M

    具体: shared_pool_size=209715200 #200M

    db_block_buffer=103192 #800M

    log_buffer = 131072 # 128k (128K*CPU个数)

    large_pool_size= 31457280 #30M

    java_pool_size = 20971520 # 20 M

    sort_area_size = 524288 # 512k (65k--2M)

    sort_area_retained_size = 524288 # MTS 时 sort_area_retained_size = sort_area_size

    假定64 bit ORACLE

    内存4G

    shared_pool_size = 200M , data buffer = 2.5G

    内存8G

    shared_pool_size = 300M , data buffer = 5G

    内存 12G

    shared_pool_size = 300M-----800M , data buffer = 8G

    参数更改方式

    oracle8i:

    主要都是通过修改oracle启动参数文件进行相关的配置

    参数文件位置:

    d:oracleadminDB_Namepfileinit.ora

    按以上修改以上参数值即可。

    Oracle9i:

    两种方式:第一种是修改oracle启动参数文件后,通过此参数文件再创建服务器参数文件

    第二种是直接运行oracle修改命令进行修改。

    SQL>alter system set db_cache_size=200M scope=spfile;

    SQL>alter system set shared_pool_size=50M scope=spfile;


    另附:

    内存优化:
    SGA包括三个部分组成。数据缓冲区、日志缓冲区及共享池

    数据缓冲区:大小由DB_Cache_Size参数决定。select name,value from v$parameter where name in('db_cache_size','db_block_size','shared_pool_size','sort_area_size');

    select name value from v$sysstat where name in ('db block gets','consistent gets','physical reads');
    其中理想的情况:physical reads接近为0 也就是说数据全部来自数据缓冲区。
    db block gets表示从内存读取数据  consistent gets表示读取一致性数据。

    select child#,sleeps/gets ratio from v$latch_children where name ='cache buffers lru chain';
    可以检测到数据缓冲区是否有空闲,得到的空闲冲突比例应该接近0

    数据缓冲区内存是否足够大,效率如何,可以通过计算命中率来确定。用磁盘物理读的数据与内在缓冲区的数据进行计算,就得出了命中率。一般要求在90%以上,否则必须增加数据缓冲区的大小。

    共享池大小由参数shared_pool_size决定。在共享池里,SQL区比数据缓存消耗较大的内存区域。
    select name ,bytes from v$sgastat order by name;
    select * from v$sgastat where name = 'free memory';

    free memory是空闲内存,是共享池中可以使用的字节数,dictionary cache 是数据字典缓冲区,library cache是库缓冲区,sql area是SQL缓冲区。
    空闲百分比 = (空闲内存/共享池字节数)×100% 如果小于20% 则应增大共享池参数Shared_Cache_size

    排序区调整:
    select name,value from v$sysstat wehre name like '%sort%";  sorts(memory)表示内存排序量, sorts(disk)表示磁盘序量。 
    失败率 = sort(disks)/sorts(memory)  ×100%  排序区的失败率不得小于5%,否则必须增加排序sort_area_size的大小,使得Oracle尽量使用内存排序。

    磁盘IO的调整就是把数据文件放在多个不同的磁盘上。

    减少了IO的操作次数就减少了CPU的需求。

    下面是我一些实际操作的过程:

    alter system set db_cache_size=4G scope=spfile;
    alter system set open_cursors=2048 scope=spfile;
    alter system set pga_aggregate_target=512M scope=spfile;
    alter system set sga_max_size=12G scope=spfile;
    alter system set shared_pool_size=1G scope=spfile;

    重启一下Oracle就可以了。注意这里配置的机器内存是24G。

    
    
    展开全文
  • Oracle内存调优及优化思路.pptx
  • Oracle彻底优化——优化内存

    千次阅读 2018-04-13 19:14:05
    Oracle数据库体系结构中内存优化也是性能优化的关键。优化内存主要是通过优化内存结构来提高系统性能。这里所说的内存结构主要由专用SQL及PL/SQL区、共享池、日志缓冲区和高速缓冲存储区构成。由于0racle的内存...
    内存的优化历来都是数据库或者操作系统优化的重中之重。在Oracle数据库体系结构中内存优化也是性能优化的关键。优化内存主要是通过优化内存结构来提高系统性能。这里所说的内存结构主要由专用SQL及PL/SQL区、共享池、日志缓冲区和高速缓冲存储区构成。
    
    由于0racle的内存结构需求与应用密切相关,所以内存结构优化应在SQL语句和应用程序优化之后以及输入/输出(I/O)优化之前进行。而且首先要优化操作系统,并在处理共享池前考虑私有SQL和PL/SQL区。

    优化SGA
    SGA是对数据库数据进行快速访问的一个系统全局区,其大小在实例启动时被确定。若SGA本身需要频繁地进行释放、分配,则不可能达到快速访问数据的目的。因此为了优化系统性能,应确保SGA全部被驻留在实际内存中,而不应采用虚拟内存,以免使整个系统性能下降。

    编辑提示:SGA小常识
    SGA是Oracle为一个实例分配的一组共享内存缓冲区。它包含该实例的数据和控制信息。如果有多个用户同时与同一个实例相连接时,则其SGA中的数据可为多个用户共享,所以也叫它共享全局区。SGA在实例启动时被自动分配,当实例关闭时被收回。SGA中的数据和控制信息可被多个进程所使用,但只能由几个持殊进程能对其进行写操作。SGA中所包含的存储区根据其存放的信息类型大致可分为“数据库缓冲存储区”、“日志缓冲区”、“共享池”和“请求和响应队列”四大区域。
    查看SGA大小
    用户可以通过两种命令方式来查看SGA的大小。
    (1)使用“SHOW SGA”命令
    说明:用户可以连接到Sever Manager和数据库,然后执行“SHOW SGA”命令来查看SGA的大小。如果数据库实例没有启动,那么使用“SHOW SGA”命令将会报错。
    (2)使用“SELECT * FROM V$SGA;”查询试图命令
    说明:使用“SELECT * FROM V$SGA;”要在“SVRMGR>”提示符下。
    预装SGA
    可以在init.ora文件中将参数PRE_PAGE_SGA的值设为“yes”,而将SGA预装到物理内存中,即设置PRE_PAGE_SGA=yes。

    优化专用SQL区及PL/SQL区
    要优化专用的SQL区及PL/SQL区,就必须知道是否有不必要的语法分析调用,用户必须尽量少的调用Parse。如果有过多的不必要的语法分析调用,就应当设法减少它。
    可用跟踪功能来为每个SQL语句输出跟踪信息,以检测其语法分析步的统计数字count。若分析步的count统计值与执行步的count统计值非常接近,则应减少语法分析调用。
    减少语法分析调用的方法是通过所用的应用开发工具(如PRO*C、OCI和SQL*Forms等)来控制语法分析调用以及分配和释放专用的SQL区的频率,例如:在用PRO*C时,可用HOLD_CURSOR、RELEASE_CURSOR以及MAX_OPENCURSOR参数来控制专用SQL区。在使用OCI时,可使用OSQL3或OPARSE调用来为SQL语句分配专用SQL区,用OCLOSE调用关闭光标和释放专用SQL区。在使用SQL *Forms时,同样也可控制是否重用专用SQL区:可在触发器级、Form级或在运行时减少语法分析调用,以减少或重用专用SQL区。

    优化日志缓冲区
    日志缓冲区也称为重做日志缓冲区,它包含所有变化了的数据块。这些变化的数据块通过Oracle日志书写进程以一种邻接的方式写到重做日志文件中。
    (1)获取缓冲区活动情况
    优化日志缓冲区时,首先应了解缓冲区的活动情况。这对通过查询动态性能表(需有SELECT  ANY TABLE特权)V$SYSSTAT来获得。
    SVRMGR> select sum(value)"Redo Buffer Waits" from v$sysstat
         2> where name='redo log space wait time';
    (2)计算日志缓冲区的申请失败率
    数据库管理员可以通过执行下述语句:
    SQL>select name,value from v$sysstat where name in ('redo entries','redo log space requests');查看日志缓冲区的使用情况。查询出的结果可以计算出日志缓冲区的申请失败率。
    申请失败率=requests/entries。申请失败率应该接近于0,否则说明日志缓冲区开设太小,需要增加ORACLE数据库的日志缓冲区。
    (3)优化日志缓冲区
    如果重做缓冲区的等待大于零,进程就要等待重做日志缓冲区的空间变成可用。此时就会影响数据库的性能。可以通过逐步提高init.ora中参数LOG_BUFFER的值来达到优化日志缓冲区的目的。在增加LOG_BUFFER的值时,可通过查询动态性能表来了解和检查日志缓冲区的活动情况。

    优化共享池
    共享池由库高速缓存、字典高速缓存和SQL区组成。整个共享池的大小由参数SHARED_POOL_SIZE确定。共享池的优化主要考虑库高速缓冲区、数据字典高速缓冲区以及会话期间信息的优化。

    优化库高速缓冲区
    要优化库高速缓冲区,必须首先了解该缓冲区的活动情况。库高速缓冲区的活动统计信息保留在动态性能表V$LIBRARYCACHE中。优化时应使数据字典高速缓存里的内存数据库块尽可能多。
    (1)确定库高速缓存的性能
    通过查询V$LIBRARYCACHE表(需有SELECT ANY TABLE特权)来了解其活动情况,以决定如何优化。例如:
    SQL>SELECT SUM(pins),SUM(reloads) FROM V$LIBRARYCACHE;
    说明:动态性能表V$LIBRARYCACHE中包含有NAMESPACE、PINS和RELOAD等列。其中NAMESPACE列反映了SQL语句及PL/SQL块的库缓冲区的活动,其值可能是‘SQL AREA’,‘TABLE/PROCEDURE’,‘BODY’和‘TRIGGER’等;而PINS和RELOADS列给出执行调用时的错误信息。PINS列给出SQL语句、PL/SQL块及被访问对象定义的总次数;RELOADS给出SQL语句或PL/SQL块的隐式分析或对象定义重装载时在库程序缓冲区中发生的错误。
    (2)查看reloads和pins的比率
    可以使用以下查询语句来查看reloads和pins的比率:
    SELECT(SUM(reloads)/SUM(pins))×100“Library Cache Ratio”FROM V$LIBRARYCACHE;
    用户必须保证reloads和pins的比率尽可能低,其值应低于1%,若RELOADS/PINS>1%,则应给缓冲区分配附加的存储及写等同的SQL语句,使SQL语句与PL/SQL块共享一个共享SQL区,这样可减少错误。如果库高速缓冲区无错误,则可设置初始化参数CUTSOR_SPACE_FOR_TIME为TRUE,以加速执行调用。这可使性能稍有改善。若每个用户可用的专用SQL区不足时,则不要将CUTSOR_SPACE_FOR_TIME设置为TRUE。
    (3)优化库高速缓存区
    优化库高速缓存时,可以通过增加init.ora文件中SHARED_POOL_SIZE或OPEN_CURSORS的参数值而达到满意的优化比率。

    优化数据字典缓冲区
    数据字典缓冲区在功能上与库高速缓存类似,但主要用于Oracle字典高速SQL语句。要优化数据字典缓冲区,也必须先查看数据字典缓冲区的使用情况及效果,然后依此来进行优化。数据字典缓冲区的使用情况记录在动态性能表V$ROWCHACHE中,其中有如下几列:
    PARAMETER:记录某类特写数据字典项的统计,其值以‘de_’开始,例如某文件描述的统计为‘de_files’。
    GETS:是对相应项请求次数的统计。
    GETTMISSES:是引起缓冲区出错的数据请求次数。
    可用如下语句来查询V$ROWCHACHE表:
    SQL>SELECT (SUM(getmisses)/SUM(gets))*100 ”DaTa Dictionary Cache Ratio”FROM V$ROWCHACHE; 
    对于贫繁访问的数据字典缓冲区,GETMISSES与GETS之比要小于10%到15%。若大于此百分数时,则应考虑增加数据字典缓冲区的容量,即要增加SHARED_POOL_SIZE或者DB_BLOCK_BUFFERS初始化参数的值。
    使用多线索服务器时共享池的优化
    在多线索服务器结构中,会话期信息被存放在共享池中,它包括SQL专用区和排序区。在使用多线索服务器时,要增大共享池,以满足需要。这也可通过增加SHARED_POOL_SIZE的参数值来实现。
    可通过查询(要求有SELECT ANY TABLE特权)动态性能表V$SESSTAT来衡量会话信息的多少。例如:
        SQL>SELEC SUM(value) ||’bytes’ ”Total memory for all session”
        2>FROM V$SESSTAT
        3>WHERK name=‘session memory’;
    SQL>SELECT UM(value)|| ‘bytes’ “Total max men for all sessions”
        2>FROM  V$SESSTAT
        3>WHERE  name=‘max session memory’;
    其中,“session memory”是分配给会话的内存字节数;“max session memory”是分配给会话的最大内存字节数。


    优化缓冲区
    (1)获取缓冲区活动情况
    为了优化缓冲区,首先应了解缓冲区的活动情况。这可以通过查询动态性能表(需有SELECT  ANY TABLE特权)V$SYSSTAT来获得。
    SVRMGR> select name ,value from v$sysstat
         2> where name in('db block gets','consistent gets','physical reads');
    NAME    VALUE
    db  blockgets   3437
    consistent gets   30500
    physica  reads   1963
    3 rows selected.
    其中,“db block gets”和“consistent gets”的值是请求数据缓冲区中读的总次数。“physical reads”为请求数据时引起从盘中读文件的次数。

    (2)缓冲区命中率
    从缓冲区读的可能性的高低称为缓冲区命中率。它可用如下公式计算:
    Hot Ratio=1-(physical reads/(db block gets+consistent gets)
    缓冲区命中率越高,其速度就越快。如果命中率低于60%或70%时。则应增加缓冲区(即DB_BLOCK_BUFFERS),以改进性能。根据公式可以计算出本例中的Hot Ratio=1-(1963/(3437+30500)=92%。 如果缓冲区的命中率很高,希望在保持良好性能下适当减少缓冲区,这时可减少DB_BLOCK_BUFFERS的值,其最小值为4。
    展开全文
  • Oracle数据库内存优化方法的研究和应用.pdf
  • 关于Oracle数据库内存优化的讨论与配置研究.pdf
  • 主要给大家介绍了关于Linux中大内存Oracle数据库优化的相关资料,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习学习吧
  • Oracle DBA 实战攻略 Oracle内存调优及优化思路 Oracle本质上是一个软件 Oracle停止当前版本支持时间 Oracle体系结构 Oracle实例组成 Oracle连接过程 监听的作用 监听是连接客户端和Oracle数据库的 桥梁远程客户端...
  • Oracle数据库内存优化的讨论与配置,希望对您有所帮助
  • Oracle性能优化

    2018-05-30 14:48:18
    本书作者凭借其20多年的丰富经验,为我们带来了一本系统的、全面的Oracle性能优化手册,用结构化方法帮助读者解决从数据库应用到数据库设计的所有问题。全书分为6部分、23章,实例丰富,兼具技术深度和广度,被读者...
  • oracle 内存全面分析

    2010-08-10 14:00:27
    oracle 内存全面分析 以及 怎样优化oracle内存 sga 等等
  • 在linux中内存分页的大小会影响到系统性能,如果...将oracle的所有实例都启动后,运行如下脚本 可以计算的最大内存分页的值 #------------------hugepages_settings.sh---------------------------- #!/bin

    在linux中内存分页的大小会影响到系统性能,如果内存够大(>8G)

    就需要调整内存分页的大小,如果分页太小过多的页面交换,回导致系统性能的下降

    将oracle的所有实例都启动后,运行如下脚本 可以计算的最大内存分页的值


    #------------------hugepages_settings.sh----------------------------


    #!/bin/bash
    #
    # hugepages_settings.sh
    #
    # Linux bash script to compute values for the
    # recommended HugePages/HugeTLB configuration
    #
    # Note: This script does calculation for all shared memory
    # segments available when the script is run, no matter it
    # is an Oracle RDBMS shared memory segment or not.
    #
    # This script is provided by Doc ID 401749.1 from My Oracle Support
    # http://support.oracle.com

    # Welcome text
    echo "
    This script is provided by Doc ID 401749.1 from My Oracle Support
    (http://support.oracle.com) where it is intended to compute values for
    the recommended HugePages/HugeTLB configuration for the current shared
    memory segments. Before proceeding with the execution please make sure
    that:
     * Oracle Database instance(s) are up and running
     * Oracle Database 11g Automatic Memory Management (AMM) is not setup
       (See Doc ID 749851.1)
     * The shared memory segments can be listed by command:
         # ipcs -m

    Press Enter to proceed..."

    read

    # Check for the kernel version
    KERN=`uname -r | awk -F. '{ printf("%d.%d\n",$1,$2); }'`

    # Find out the HugePage size
    HPG_SZ=`grep Hugepagesize /proc/meminfo | awk '{print $2}'`

    # Initialize the counter
    NUM_PG=0

    # Cumulative number of pages required to handle the running shared memory segments
    for SEG_BYTES in `ipcs -m | awk '{print $5}' | grep "[0-9][0-9]*"`
    do
       MIN_PG=`echo "$SEG_BYTES/($HPG_SZ*1024)" | bc -q`
       if [ $MIN_PG -gt 0 ]; then
          NUM_PG=`echo "$NUM_PG+$MIN_PG+1" | bc -q`
       fi
    done

    RES_BYTES=`echo "$NUM_PG * $HPG_SZ * 1024" | bc -q`

    # An SGA less than 100MB does not make sense
    # Bail out if that is the case
    if [ $RES_BYTES -lt 100000000 ]; then
       echo "***********"
       echo "** ERROR **"
       echo "***********"
       echo "Sorry! There are not enough total of shared memory segments allocated for
    HugePages configuration. HugePages can only be used for shared memory segments
    that you can list by command:

       # ipcs -m

    of a size that can match an Oracle Database SGA. Please make sure that:
     * Oracle Database instance is up and running
     * Oracle Database 11g Automatic Memory Management (AMM) is not configured"
       exit 1
    fi

    # Finish with results
    case $KERN in
       '2.4') HUGETLB_POOL=`echo "$NUM_PG*$HPG_SZ/1024" | bc -q`;
              echo "Recommended setting: vm.hugetlb_pool = $HUGETLB_POOL" ;;
       '2.6') echo "Recommended setting: vm.nr_hugepages = $NUM_PG" ;;
        *) echo "Unrecognized kernel version $KERN. Exiting." ;;
    esac

    # End

    执行结果:

    [root@dbo ~]# sh hugepagemem.sh
    hugepagemem.sh: line 1: ------------------hugepages_settings.sh----------------------------: command not found

    This script is provided by Doc ID 401749.1 from My Oracle Support
    (http://support.oracle.com) where it is intended to compute values for
    the recommended HugePages/HugeTLB configuration for the current shared
    memory segments. Before proceeding with the execution please make sure
    that:
     * Oracle Database instance(s) are up and running
     * Oracle Database 11g Automatic Memory Management (AMM) is not setup
       (See Doc ID 749851.1)
     * The shared memory segments can be listed by command:
         # ipcs -m

    Press Enter to proceed...
     
    Recommended setting: vm.nr_hugepages = 9222

    将vm.nr_hugepages = 9222添加到/etc/sysctl.conf中

    然后使其内核参数生效sysctl -p


    #######################################

    迷途小运维oracle优化 整理自网络

    作者:john

    转载请注明出处


    展开全文
  • Oracle 内存结构

    千次阅读 2015-07-02 11:19:20
    Oracle内存结构
    Oracle内存结构
    


    一、概述
    每当数据库启动,系统全局区(SGA)被分配,并启动了Oracle后台进程。
    系统全局区用于数据库用户共享数据库信的内存区域,
    后台进程和内存缓冲区称为Oracle实例,Oracle实例包含2种进程:用户进程和Oracle进程。
    用户进程执行应用操作的代码,Oracle进程是执行用户进程和后台进程,对Oracle进行维护的服务器进程。
    数据库拥有多个后台进程,其数量取决于数据库的配置。
    每个后台进程都有一个跟踪文件。可以设置init.ora文件的background_dump_dest参数来规定文件位置。

    Oracle内存结构分为系统全局区和程序全局区,下面逐一讲述。


    二、系统全局区(SYSTEM Global Area)SGA
    说明:SGA是Oracle数据库存放系统信息的一块内存区域。这样设计的主要原因是在内存中通信速度快、效率高。所有用户进程和服务进程均可访问这个内存结构。
    包含

    1、数据块缓冲存储区(Data Block Buffer Cache)
    1.1、一个高速缓存区,用来存储从数据库中读取数据段的数据块(如表、索引、簇)副本。所有并发的连接到实例上的用户进程都将共享同一个数据缓存区。
    1.2、块的大小由数据库服务器init.ora文件的DB_BLOCK_BUFFERS参数决定(用数据库块的个数表示),通常为数据库大小的1%~2%。
    1.3、缓冲区大小由init.ora文件的db_cache_size参数决定。Oracle使用LRU算法管理。(Least Recently Used最近最少使用算法)。
    1.4、当SGA大小不足以容纳最常用数据时会导致段争夺SGA的空间,数据缓冲区将出现较低命中率致使系统性能下降。

    缓冲区分为3个池:
    保持(keep)缓冲池 (长期保存在内存中,直到数据库被关闭为止。BUFFER_POOL_KEEP指定大小)
    再生(recycle)缓冲池 (数据一旦用毕后就被换出内存中。BUFFER_POOL_RECYCLE指定大小)
    默认(default)缓冲池 (数据使用LRU调度算法来换出。DB_CACHE_SIZE - BUFFER_POOL_REEP - BUFFER_POOL_RECYCLE 即为该缓冲池的大小)

    缓冲区分为3种块:
    数据高速缓存块由许多大小相等的缓存块组成,这些缓存块的大小和OS块大小相同。 这些缓存块分为 3 大类、
    脏缓存块( Dirty buffers ):
    脏缓存块中保存的时被修改过的缓存块。即当一条SQL语句对某个缓存块中的数据进行修改后,该缓存块就被标记为藏缓存块。
    最后该脏缓存块被DBWn进程写入到硬盘的数据文件中,永久保留起来。
    命中缓存块( Pinned buffers ):
    命中缓存块中保存的是最近正在被访问的缓存块。它始终被保留中数据高速缓存中,不会被写入数据文件。
    空闲缓存块(Free buffers):
    该缓存块中没有数据,等待被写入数据。oracle从数据文件中读取数据后,寻找空闲缓存块,以便写入其中。

    Oracle 通过 2 个列表(DIRTY、LRU)来管理缓存块
    DIRTY 列表中保存已经被修改但还没有被写入到数据文件中的脏缓存块。
    LRU 列表中保存所有的缓存块(还没有被移动到DIRTY列表中的脏缓存块、空闲缓存块、命中缓存块)。
    当某个缓存块被访问后,该缓存块就被移动到LRU列表的头部,其他缓存块就向LRU列表的尾部移动。
    放在最尾部的缓存块就最先被移出LRU列表。

    数据高速缓存的工作原理过程是:
    A、ORACLE在将数据文件中的数据块复制到数据高速缓存中之前,先在数据高速缓存中找空闲缓存块,以便容纳该数据块。Oracle 将从LRU列表的尾部开始搜索,直到找到所需的空闲缓存块为止。
    B、如果先搜索到的是脏缓存块,将将该脏缓存块移动到DIRTY列表中,然后继续搜索。如果搜索到的是空闲缓存块,则将数据块写入,然后将该缓存块移动到DIRTY列表的头部。
    C、如果能够搜索到足够的空闲缓存块,就将所有的数据块写入到对应的空闲缓存块中。则搜索写入过程结束。
    D、如果没有搜索到足够的空闲缓存块,则ORACLE就先停止搜索,而是激活DBWn进程,开始将DIRTY列表中的脏缓存块写入到数据文件中。
    E、已经被写入到数据文件中的脏缓存块将变成空闲缓存块,并被放入到LRU列表中。执行完成这个工作后,再重新开始搜索,直到找到足够的空闲缓存块为止。


    2、重做日志缓冲区
    为了加快访问和速度和工作效率,重做记录并不直接写入重做日志文件中,而是首先从数据高速缓存写入重做日志高速缓存。当重做日志高速缓存中的重做记录
    达到一定数量或某个时间点时,再由LGWR进程分批写入重做日志文件中(即ORACLE 总是先日志后文件或先内存后磁盘)。由于重做日志文件是循环使用的。
    所以当重做日志文件切换时,还会由ARCn(如果启用了归档日志模式)进程将即将要被覆盖的重做日志文件中的数据写入到归档日志文件中,作为备份。

    SGA内一块被循环使用的缓冲区,用于记录数据库内的数据变化信息。这些信息以重做条目的形式进行存储。
    Oracle利用重做条目内的信息就可以重做由INSERT,UPDATE,DELETE,DREATE,ALTER,DROP等操作对数据库进行的修改。
    重做项描述对数据库进行的修改。它们写到联机重做日志文件中,以便在数据库恢复过程中用于向前滚动操作。
    然而。在被写到联机重做日志文件之前,事务首先被记录在称作重做日志缓冲区的SGA中。
    数据库可以周期滴分批想联机重做日志文件中写重做项的内容,其大小(字节为单位)有init.ora的LOG_BUFFER参数决定,可以在运行期间修改该参数。

    SHOW PARAMETER LOG_BUFFER; ------查询重做日志缓存的大小

    3、SQL共享池(Shared Pool)

    工作原理:
      oracle将SQL语句提炼为两部分,一部分是SQL语句的静态部分,也就是SQL语句本身的关键词、所涉及的表名称以及表的列等。
    另一部分就是SQL语句的动态部分,也就是SQL语句中的值(即表里的数据)。很明显的,整个数据库中所包含的对象数量是有限的,而其中所包含的数据则是无限的。
    而正是这无限的数据导致了SQL语句的千变万化,也就是说在数据库运行的过程中,发生的所有SQL语句中,静态部分可以认为数量是有限的,而动态部分则是无限的。
    而实际上,动态部分对解析的影响相比静态部分对解析的影响来说是微乎其微,也就是说通常情况下,对于相同的静态部分的SQL语句来说,
    不同的动态部分所产生的解析结果(执行计划)基本都是一样的。这也就为oracle提高解析SQL语句的效率提供了方向。

      oracle会将用户提交来的SQL语句都缓存在内存中。每次处理新的一条SQL语句时,都会先在内存中查看是否有相同的SQL语句。
    如果相同则可以减少最重要的解析工作(也就是生成执行计划),从而节省了大量的资源;反之,如果没有找到相同的SQL语句,则必须重新从头到尾进行完整的解析过程。
    这部分存放SQL语句的内存就叫做共享池(shared pool)。当然,shared pool里不仅仅是SQL语句,还包括管理shared pool的内存结构以及执行计划、控制信息等等内存结构。

      当oracle在shared pool中查找相同的SQL语句的过程中,如果SQL语句使用了绑定变量(bind variable),那么就是比较SQL语句的静态部分,前面我们已经知道,静态部分是有限的,
    很容易就能够缓存在内存里,从而找到相同的SQL语句的概率很高。如果没有使用绑定变量,则就是比较SQL语句的静态部分和动态部分,而动态部分的变化是无限的,
    因此这样的SQL语句很难被缓存在shared pool里。毕竟内存是有限的,不可能把所有的动态部分都缓存在shared pool里,即便能够缓存,
    管理这样一个无限大的shared pool也是不可能完成的任务。不使用绑定变量导致的直接结果就是,找到相同的SQL语句的概率很低,导致必须完整的解析SQL语句,也就导致消耗更多的资源。
    从这里也可以看出,只有我们使用了绑定变量,才真正遵循了oracle引入shared pool的哲学思想,才能够更有效的利用shared pool.


    SQL共享池的内存结构:
    从一个物理的层面来看,shared pool是由许多内存块组成,这些内存块通常称为chunk.Chunk是shared pool中内存分配的最小单位,一个chunk中的所有内存都是连续的。
    这些chunk可以分为四类,这四类可以从x$ksmsp(该视图中的每个行都表示shared pool里的一个chunk)的ksmchcls字段看到:
    1) free:这种类型的chunk不包含有效的对象,可以不受限制的被分配。
    2) recr:意味着recreatable,这种类型的chunks里包含的对象可以在需要的时候被临时移走,并且在需要的时候重新创建。
    比如对于很多有关共享SQL语句的chunks就是recreatable的。
    3) freeabl:这种类型的chunks包含的对象都是曾经被session使用过的,并且随后会被完全或部分释放的。这种类型的chunks不能临时从内存移走,
    因为它们是在处理过程中间产生的,如果移走的话就无法被重建。
    4) perm:意味着permanent,这种类型的chunks包含永久的对象,大型的permanent类型的chunks也可能含有可用空间,这部分可用空间可以在需要的时候释放回shared pool里。

      当chunk属于free类型的时候,它既不属于library cache,也不属于dictionary cache.如果该chunk被用于存放SQL游标时,则该chunk进入library cache;
    同样,如果该chunk被用于存放数据字典的信息时,则该chunk进入dictionary cache.

      在shared pool里,可用的chunk(free类型)会被串起来成为可用链表(free lists)或者也可以叫做buckets(一个可用链表也就是一个bucket)。
    我们可以使用下面的命令将shared pool的内容转储出来看看这些bucket.
      alter session set events 'immediate trace name heapdump level 2';

    然后打开产生的转储文件,找到“FREE LISTS”部分,这是在9i下产生的bucket列表,9i以前的可用chunk的管理方式是不一样的。
    我们可以看到,可用的chunk链表(也就是bucket)被分成了254个,每个bucket上挂的chunk的尺寸是不一样的,有一个递增的趋势。
    我们可以看到,每个bucket都有一个size字段,这个size 就说明了该bucket上所能链接的可用chunk的大小尺寸。

      当一个进程需要shared pool里的一个chunk时,假设当前需要21个单位的空间,则该进程首先到符合所需空间大小的bucket(这里就是bucket 2)上去扫描,
    以找到一个尺寸最合适的chunk,扫描持续到bucket的最末端,直到找到完全符合尺寸的chunk为止。
    如果找到的chunk的尺寸比需要的尺寸要大,则该chunk就会被拆分成两个chunk,一个chunk被用来存放数据,
    而另外一个则成为free类型的chunk,并被挂到当前该bucket上,也就是bucket 2上。
    然而,如果该bucket上不含有任何需要尺寸的chunk,那么就从下一个非空的bucket上(这里就是bucket 3)获得一个最小的chunk.
    如果在剩下的所有bucket上都找不到可用的chunk,则需要扫描已经使用的recreatable类型的chunk 链表,从该链表上释放一部分的chunk出来,
    因为只有recreatable类型的chunk才是可以被临时移出内存的。
    当某个chunk正在被使用时(可能是用户正在使用,也可能是使用了dbms_shared_pool包将对象钉在shared pool里),该chunk是不能被移出内存的。
    比如某个SQL语句正在执行,那么该SQL语句所对应的游标对象是不能被移出内存的,该SQL语句所引用的表、索引等对象所占用的chunk也是不能被移出内存的。
    当shared pool中无法找到足够大小的所需内存时,报ORA-4031错。当出现4031错的时候,你查询v$sgastat里可用的shared pool空间时,
    可能会发现name为“free memory”的可用内存还足够大,但是为何还是会报4031错呢?事实上,在oracle发出4031错之前,已经释放了不少recreatable类型的chunk了,
    因此会产生不少可用内存。但是这些可用chunk中,没有一个chunk是能够以连续的物理内存提供所需要的内存空间的,从而才会发出 4031的错。

      对bucket的扫描、管理、分配chunk等这些操作都是在shared pool latch的保护下进行的。如果shared pool含有数量巨大的非常小的free类型的chunk的话,
    则扫描bucket时,shared pool latch会被锁定很长的时间,这也是8i以前的shared pool latch争用的主要原因。而如果增加shared pool尺寸的话,
    仅仅是延缓shared pool latch的争用,而到最后,就会因为小的free chunks的数量越来越多,争用也会越来越严重。
    而到了9i以后,由于大大增加了可用chunk链表(也就是bucket)的数量,同时,每个 bucket所管理的可用chunk的尺寸递增的幅度非常小,
    于是就可以有效的将可用的chunk都均匀的分布在所有的bucket上。这样的结果就是每个bucket上所挂的free类型的chunk都不多,
    所以在查找可用chunk而持有shared pool latch的时间也可以缩短很多。

    对于非常大的对象,oracle会为它们单独从保留区域里分配空间,而不是从这个可用chunk链表中来分配空间。
    这部分空间的大小尺寸就是由初始化参数 shared_pool_reserved_size决定的,缺省为shared_pool_size的5%,这块保留区域与正常的chunk的管理是完全分开的,
    小的chunk不会进入这块保留区域,而这块保留区域的可用chunk也不会挂在bucket上。这块保留区域的使用情况可以从视图v$shared_pool_reserved中看到,
    通常来说,该视图的request_misses字段显示了需要从保留区域的可用链表上上获得大的 chunk而不能获得的次数,该字段应该尽量为0.


    说明:
    (1)、SQL共享池包括数据字典缓冲区、库缓冲区、其他控制结构区。
    (2)、其中库缓冲区又分为共享SQL区、PL/SQL过程与包区、锁与他控制结构区,当是共享服务器模式时还会多出私有SQL区、排序区。
    (1)、其大小(字节为单位)由init.ora的SHARED_POOL_SIZE决定。默认80MB,可以在运行期间手动修改该参数,10g以后可以不用设定该参数,而只需要指定sga_target,
    从而oracle 将自动决定shared pool的大小尺寸。
    (2)、当数据块缓冲区和字典缓存区能够共享数据库用户间的结构及数据信息时,库缓存区允许共享常用的SQL语句。
    (3)、包含执行计划及运行数据库的sql语句的语法分析树。在第二次运行(由任何用户)相同的sql语句时,可利用sql共享池中可用的语法分析信息来加快执行速度。
    (4)、SQL共享池的置换规则由LRU算法管理,如果SQL共享池太小,将连续不断再装入到库缓存区,从而降低性能。
    共享池中保存了最近执行的SQL语句、PL/SQL过程与包、数据字典信息、锁、以及其他控制结构的信息。
    共享池是对SQL语句、PL/SQL程序进行语法分析、编译、执行的内存区。
    认出的过程叫做解析SQL语句的过程,响应的过程叫做执行SQL语句的过程。解析的最终结果是要产生oracle自己内部的执行计划,从而指导SQL的执行过程。

    3.1、字典缓存区(dictionary cache)
    当数据库需要字典信息时,将读取数据字典表并将返回的数据存储在字典缓存区的SGA中。
    字典缓冲区大小由数据库内部管理。置换规则由LRU算法管理。
    如果字典缓冲区太小,数据库就不得不反复查询数据字典表以访问数据库所需的信息,这些查询称为循环调用,循环调用会导致查询速度更低。
    用于存储经常使用的数据字典信息。比如(表的定义、用户名、口令、权限、数据库的结构等)。
    Oracle运行过程中经常访问该缓存以便解析SQL语句,确定操作的对象是否存在,是否具有权限等。如果不在数据字典缓存中,服务器进程就从保存数据字典信息的
    数据文件中将其读入到数据字典缓存中。数据字典缓存中保存的是一条一条的记录(就像是内存中的数据库),而其他缓存区中保存的是数据块信息。
    dictionary cache则存放了在执行SQL语句过程中,所参照的数据字典的信息,包括SQL语句所涉及的表名、表的列、权限信息等。
    dictionary cache也叫做row cache,因为这里面的信息都是以数据行的形式存放的,而不是以数据块的形式存放的。
    对于dictionary cache来说,oracle倾向于将它们一直缓存在shared pool里,不会将它们交换出内存,因此我们不用对它们进行过多的关注。

    3.2、库缓存区(library cache)
    (大小与OPEN_CURSOR初始化参数相关,ORACLE中每条查询语句都需要打开一个游标,OPEN_CURSOR默认值为300)
    库缓存的目的就是保存最近解析过的SQL语句、PL/SQL过程和包。
    这样一来,Oracle在执行一条SQL语句、一段PL/SQL 过程和包之前,首先在“库缓存”中搜索,如果查到
    它们已经解析过了,就利用“库缓存”中解析结果和执行计划来执行,而不必重新对它们进行解析,显著提高执行速度和工作效率。
    ORACLE将每一条SQL语句分解为可共享、不可共享的两部分。
    Library cache存放了最近执行的SQL语句、存储过程、函数、解析树以及执行计划等。
    library cache是shared pool里最重要的部分,也是在shared pool中进进出出最活跃的部分,需要我们仔细研究。
    所以,我们在说到shared pool实际上就可以认为是在指library cache.

    当SQL语句(select object_id,object_name from sharedpool_test)进入library cache时,
    oracle会到dictionary cache中去找与sharedpool_test表有关的数据字典信息,比如表名、表的列等,以及用户权限等信息。
    如果发现dictionary cache中没有这些信息,则会将system表空间里的数据字典信息调入buffer cache内存,读取内存数据块里的数据字典内容,
    然后将这些读取出来的数据字典内容按照行的形式放入dictionary cache里,从而构造出dc_tables之类的对象。
    然后,再从dictionary cache中的行数据中取出有关的列信息放入library cache中。

      library cache最主要的功能就是存放用户提交的SQL语句、SQL语句相关的解析树(解析树也就是对SQL语句中所涉及到的所有对象的展现)、执行计划、
    用户提交的PL/SQL程序块(包括匿名程序块、存储过程、包、函数等)以及它们转换后能够被oracle执行的代码等。为了对这些内存结构进行管理,
    还存放了很多控制结构,包括lock、pin、dependency table等。

      library cache还存放了很多的数据库对象的信息,包括表、索引等等。有关这些数据库对象的信息都是从dictionary cache中获得的。
    如果用户对library cache中的对象信息进行了修改,则这些修改会返回到dictionary cache中。

      在library cache中存放的所有的信息单元都叫做对象(object),这些对象可以分成两类:一类叫存储对象,也就是上面所说的数据库对象。
    它们是通过显式的 SQL语句或PL/SQL程序创建出来的,如果要删除它们,也必须通过显示的SQL命令进行删除。这类对象包括表、视图、索引、包、函数等等;
    另一类叫做过渡对象,也就是上面所说的用户提交的SQL语句或者提交的PL/SQL程序块等。这些过渡对象是在执行SQL语句或PL/SQL程序的过程中产生的,并缓存在内存里。
    如果实例关闭则删除,或者由于内存不足而被交换出去,从而被删除。

      当用户提交SQL语句或PL/SQL程序块到oracle的shared pool以后,在library cache中生成的一个可执行的对象,这个对象就叫做游标(cursor)。
    不要把这里的游标与标准SQL(ANSI SQL)的游标混淆起来了,标准SQL的游标是指返回多条记录的SQL形式,需要定义、打开、关闭。
    下面所说到的游标如无特别说明,都是指library cache中的可执行的对象。游标是可以被所有进程共享的,也就是说如果100个进程都执行相同的SQL语句,
    那么这100个进程都可以同时使用该SQL 语句所产生的游标,从而节省了内存。每个游标都是由library cache中的两个或多个对象所体现的,至少两个对象。
    一个对象叫做父游标(parent cursor),包含游标的名称以及其他独立于提交用户的信息。从v$sqlarea视图里看到的都是有关父游标的信息;
    另外一个或多个对象叫做子游标(child cursors),如果SQL文本相同,但是可能提交SQL语句的用户不同,或者用户提交的SQL语句所涉及到的对象为同名词等,都有可能生成不同的子游标。
    因为这些SQL语句的文本虽然完全一样,但是上下文环境却不一样,因此这样的SQL语句不是一个可执行的对象,必须细化为多个子游标后才能够执行。
    子游标含有执行计划或者PL/SQL对象的程序代码块等。

    library cache的内部管理机制:

      oracle内部在实现管理的过程中大量用到了hash算法。hash算法是为了能够进行快速查找定位所使用一种技术。所谓hash算法,就是根据要查找的值,
    对该值进行一定的hash算法后得出该值所在的索引号,然后进入到该值应该存在的一列数值列表(可以理解为一个二维数组)里,通过该索引号去找它应该属于哪一个列表。
    然后再进入所确定的列表里,对其中所含有的值,进行一个一个的比较,从而找到该值。这样就避免了对整个数值列表进行扫描才能找到该值,
    这种全扫描的方式显然要比hash查找方式低效很多。其中,每个索引号对应的数值列在oracle里都叫做一个hash bucket.

    我们来列举一个最简单的hash算法。假设我们的数值列表最多可以有10个元素,也就是有10个hash buckets,每个元素最多可以包含20个数值。则对应的二维数组就是t[10][20].
    我们可以定义hash算法为n MOD 10.通过这种算法,可以将所有进入的数据均匀放在10个hash bucket里面,hash bucket编号从0到9.比如,我们把1到100都通过这个hash函数均匀放到这10个hash bucket里,当查找32在哪里时,只要将32 MOD 10等于2,这样就知道可以到2号hash bucket里去找,也就是到t[2][20]里去找,2号hash bucket里有10个数值,逐个比较2号hash bucket里是否存在32就可以了。

      library cache就是使用多个hash bucket来管理的,其hash算法当然比我们前面列举的要复杂多了。每个hash bucket后面都串连着多个句柄(该句柄叫做library cache object handle),这些句柄描述了library cache里的对象的一些属性,包括名称、标记、指向对象所处的内存地址的指针等。可以用下图一来描述library cache的整体结构。
    当一条SQL语句进入library cache的时候,先将SQL文本转化为对应ASCII数值,然后对该这些ASCII数值进行hash函数的运算,传入函数的是SQL语句的名称(name,对于SQL语句来说其name就是SQL语句的文本)以及命名空间(namespace,对于SQL语句来说是“SQL AREA”,表示共享游标。可以从视图v$librarycache里找到所有的namespace)。运用hash函数后得到一个值,该值就是hash bucket的号码,从而该SQL语句被分配到该号的hash bucket里去。实际上,hash bucket就是通过串连起来的对象句柄才体现出来的,它本身是一个逻辑上的概念,是一个逻辑组,而不像对象是一个具体的实体。oracle根据 shared_pool_size所指定的shared pool尺寸自动计算hash buckets的个数,shared pool越大,则可以挂载的对象句柄就越多。
      当某个进程需要处理某个对象时,比如处理一条新进入的SQL语句时,它会对该SQL语句应用hash函数算法,以决定其所在的hash bucket的编号,然后进入该hash bucket进行扫描并比较。有可能会发生该对象的句柄存在,但是句柄所指向的对象已经被交换出内存的情况出现。这时对应的对象必须被再次装载(reload)。也可能该对象的句柄都不存在,这时进程必须重新构建一个对象句柄挂到hash bucket上,然后再重新装载对象。SQL语句相关的对象有很多(最直观的就是SQL语句的文本),这些对象都存放在library cache里,它们都通过句柄来访问。可以把library cache理解为一本书,而SQL语句的对象就是书中的页,而句柄就是目录,通过目录可以快速定位到指定内容的页。
      对象句柄存放了对象的名称(name)、对象所属的命名空间(namespace)、有关对象的一些标记(比如对象是否为只读、为本地对象还是远程对象、是否被pin在内存中等等)以及有关对象的一些统计信息等。而且,对象句柄中还存放了当前正在lock住和pin住该对象的用户列表、以及当前正在等待 lock和pin该对象的用户列表。对象句柄中存放的最重要的内容就是指向Heap 0对象的指针了。Heap 0用来存放与对象有直接关系的一些信息,比如对象类型、对象相关的表(比如依赖表、子表等)、指向对象的其他数据块的指针(这些数据块指向了实际存放 SQL文本、PL/SQL代码、错误信息等的大内存块,这些大内存块依次叫做Heap 1、2、3、4等)等信息。
    Heap是通过调用服务器进程进行分配的,任何对象都具有heap 0,至于还应该分配哪些其他的heap则是由对象的类型决定的,比如SQL游标具有heap 1和 6,而PL/SQL程序包则具有heap 1、2、3和4.按照heap的使用情况,oracle会在SGA(library cache)、PGA或UGA中分配heap,但是heap 0始终都是在library cache中进行分配的。如果所请求的heap已经在SGA中分配了,则不会在PGA中再次分配heap.Heap是由一个或多个chunk组成的,这些 chunk可以是分散的分布在library cache中的,不需要连续分布。
      如上图三中所看到的heap 0实际上是指heap 0的句柄,其中包含的对象包括:
    1) object type:library cache中的对象类型包括:表、视图、索引、同名词等等。每个对象只能有一个object type,根据object type将对象归类到不同的namespace里。
    一个object type对应一个namespace,但是一个namespace可能对应多个object type.这样的话,查找一个对象时,只要在该对象所属的namespace中去找就可以了。
    比较常见的namespace包括:
      a) SQL AREA:也可以叫做CRSR,表示shared cursor,存放共享的SQL语句。
      b) TABLE/PROCEDURE:存放的object type包括:table、view、sequence、synonym、 procedure的定义、function的定义以及package的定义。
      c) BODY:存放procedure的实际代码、function的实际代码以及package的实际代码。
      d) TRIGGER:存放的object type为trigger.
      e) INDEX:存放的object type为index.
    2) object name:对象名称由三部分组成:
      a) Schema的名称,对于共享游标(SQL语句或PL/SQL程序块)来说为空。
      b)对象名称。分为两种情况:对于共享游标(SQL语句或PL/SQL程序块)来说,其对象名称就是SQL的语句本身;而对于其他对象(比如表、视图、索引等)就是其在数据字典中的名称。
      c) Database link的名称。这是可选的,如果是本地对象,则为空。
      这样,对象的名称的格式为:SCHEMA.NAME@DBLINK.比如,可以为hr.employees@apac.com,也可以为hr.employees等。
    3) flags:flags主要用来描述对象是否已经被锁定。对象具有三种类型的flag:
      a) public flag:表示对象上没有锁定(pin)或者latch.
      b) status flag:表示对象上存在锁定(pin),说明对象正在被创建或删除或修改等。
      c) specitial flag:表示对象上存在library cache latch.
    4) tables:对每个对象,都会维护以下一串tables中的若干个:
      a) dependency table:含有当前对象所依赖的其他对象。比如一个视图可能会依赖其组成的多个表、一个存储过程可能依赖其中所调用的其他存储过程、一个游标可能依赖其中所涉及到的多个表等。Dependency table中的每个条目都指向一块物理内存,该物理内存中含有当前对象所依赖的对象的句柄。
      b) child table:含有当前对象的子对象,只有游标具有child table.Child table中的每个条目都指向一个可执行的SQL命令所对应的句柄。
      c) translation table:包含当前对象所引用的名称是如何解释为oracle底层对象的名称,只有游标具有translation table.
      d) authorization table:包含该对象上所对应的权限,一个条目对应一个权限。
      e) access table:对于dependency table中的每一个条目,都会在access table中存在对应的一个或多个条目。比如,假设对象A依赖对象B,那么在A的dependency table和access table中都会存在一个条目指向B.位于access table中的指向B的条目说明了对B具有什么样的访问类型,从而也就说明了用户要执行A则必须具有对B的权限。
      f) read-only dependency table:类似于dependency table,但是存放只读的对象。
      g) schema name table:包含authorization table中的条目所属的schema.
    5) data blocks:对象的其他信息会存放在不同的heap中,为了找到这些heap,会在heap 0中存放多个(最多16个,但是这16个data block不会都用到)data blocks结构,每个data block含有指向这些实际heap内存块的指针。
      
    除了heap 0以外,还有11个heap,根据对象的不同进行分配,并存放了不同的内容:
      1) Heap 1:存放PL/SQL对象的源代码。
      2) Heap 2:存放PL/SQL对象的解析树,这有个好听的名字: DIANA.
      3) Heap 3:存放PL/SQL对象的伪代码。
      4) Heap 4:存放PL/SQL对象的基于硬件的伪代码。
      5) Heap 5:存放了编译时的错误信息。
      6) Heap 6:存放了共享游标对象的SQL文本。
      7) Heap 7:可用空间。
      8) Heaps 8–11:根据对象的不同而使用的子heap.
      我们可以通过查询v$db_object_cache来显示library cache中有哪些对象被缓存,以及这些对象的大小
      尺寸。比如,我们可以用下面的SQL语句来显示每个namespace中,大小尺寸排在前3名的对象:
      select *
      from (select row_number() over(partition by namespace order by sharable_mem desc) size_rank,
      namespace,
      sharable_mem,
      substr(name, 1, 50) name
      from v$db_object_cache
      order by sharable_mem desc)
      where size_rank <= 3
      order by namespace, size_rank;


    3.2.1、共享SQL区(shared SQL area)
    存储的是最近执行的SQL语句、SQL解析后的语法树(parse tree)和优化后的执行计划(execution plan)。
    这样以后执行相同的SQL语句就直接利用在共享SQL区中的缓存信息,不必重复语法解析了。
    令多次运行的 SQL 语句使用同一个共享SQL区可以为Oracle节约大量的内存开销,这在大量用户运行相同应用的环境里尤为明显。
    Oracle在执行一条新的SQL语句时,会为它在共享SQL区中分配空间,分配的大小取决于SQL语句的复杂度。
    如果共享SQL区中没有空闲空间,就利用LRU算法,释放被占用的空间。

    Oracle 处理各种 PL/SQL程序结构( program unit)(过程,函数,包,匿名块,及数据库触发器)的方式与处理单独的 SQL 语句类似。
    Oracle 为每个程序结构分配一块公共内存区以保存其解析及编译的结果。同时 Oracle 还要为程序结构创建私有内存区。
    当多个用户运行同一个程序结构时,所有用户都使用唯一的一个共享区,同时每个用户拥有一个私有区,存储此程序结构在用户会话内的独有信息。

    3.2.2、PL/SQL过程和包区
    工作原理同共享SQL区。但是嵌套在PL/SQL过程和包中的SQL语句、解析后的语法树和优化后的执行计划被存储中共享SQL区中。

    3.2.3、锁与其他控制结构
    存储ORACLE例程内部操作所需的信息。比如(各种锁、闩、寄存器值)。

    3.2.4、私用SQL区(私有内存区)
    存储在执行SQL语句、PL/SQL程序结构时,在其运行的会话中所独有的信息,每个会话或用户相关的私有信息。
    包括本地变量(local variable),全局变量(global variable),
    包变量(package variable)(也被称为包实例(package instantiation)),及SQL执行缓冲区(buffers for executing SQL)
    其他会话即使执行相同的SQL语句也不会使用这些信息。比如(绑定变量、环境和会话参数)。

    3.2.5、排序区
    当是共享服务器模式时会出现的区。

    4、大池
    (1)、大池是一个可选内存区。如果使用线程服务器选项或频繁执行备份/恢复操作,只要创建一个大池就可以有效管理这些操作
    (2)、大池将致力于支持sql大型命令。利用大池可以防止SQL大型命令把条目重写入SQL共享池中,从而减少再装入到库缓存区中的语句数量。
    (3)、大小(字节为单位)由init.ora文件的large_pool_size参数设置,用户可以通过large_pool_min_alloc参数设置大池中的最小位置。
    (4)、作为食用largepool的一种选择方案,可以用init.ora文件的shared_pool_reserved_size参数为sql大型语句保留一部分sql共享池。

    (由初始化参数LARGE_POOL_SIZE确定大小,可以使用ALTER SYSTEM语句来动态改变大池的大小)
    大池是可选项的,DBA可以根据实际业务需要来决定是否在SGA区中创建大池。如果没有创建大池,则需要大量内存空间的操作将占用共享池的内存。
    ORACLE 需要打理内存的操作有:A、数据库备份和恢复。B、具有大量排序操作的SQL语句。C、并行化的数据库操作。

    5、JAVA池(Java pool)
    1)、JAVA池为用户存放JAVA代码、JAVA语句的语法分析表、JAVA语句的执行方案和进行JAVA程序开发。
    大小(字节为单位)由init.ora文件的java_pool_size参数设置。默认为10MB。控制在30-50MB比较合适
    2)、供各会话内运行的 Java 代码及 JVM 内的数据使用的。Java 池的内存使用方式与 Oracle 服务器的运行模式有关。
    可以使用 ALTER SYSTEM SET JAVA_POOL_SIZE=0M SCOPE=SPFILE;语句在服务器初始化参数文件中修改该参数。必须重新启动数据库服务器才能使其生效。

    6、多缓存池
    (1)、可以在SGA中创建多个缓存池,能够用多个缓存池把大数据集与其他的应用程序分开,以减少它们争夺数据块存储区内相同资源的可能性。
    (2)、对于创建的每一个缓冲池,都要规定其LRU锁存器的大小和数量,缓冲区的数量必须至少比LRU锁存器的数量多50倍。
    (3)、创建缓存池时,需要规定保存区的大小和再循环区的大小。与SQL共享池的保留区一样,保存区保持条目,再循环区则被频繁地循环使用。
    (4)、保存区大小可通过BUFFER_POOL_KEEP参数设定。保存和再循环缓冲池的容量减少了数据块缓冲存储区中的可用空间。
    (5)、对于使用一个新缓冲池的表,通过表的storage子句中的buffer_pool参数来规定缓冲池的名字。
    (6)、如果需要从内存中快速删除一个表,就把它赋予RECYCLE池。默认池叫DEFAULT,这样就能在以后用altertable命令把一个表转移到default池。

    7、数据流池
    在数据库中,管理员可以在 SGA 内配置一个被称为数据流池(Streams pool)的内存池供 Oracle 数据流(Stream)分配内存。


    三、程序全局区(PGA)
    说明:程序全局区包括会话区、堆栈区、游标状态区、当是专用服务器模式时还会多出排序区、私有SQL区。
    程序全局区(PGA)是存储区的一个区域,由一个oracle用户进程所用,PGA中的内存不能共享。
    但对于多线程服务器因其允许多个用户进程使用同一服务器进程,所以PGA的一部分和用户对话信息存储在SGA中,此时应增加SQL共享池。
    PGA区是用户进程连接到数据库并创建一个对应的会话时,由ORACLE 为服务器进程分配的专门用于当前用户会话的内存区。该内存区是非共享、不可写的。
    只有服务器进程本身才可以访问它本身的PGA区。而PGA是所有服务器进程都可以共享的、可写的内存区。PGA的大小由操作系统决定,其内存取决于专用
    服务器还是共享服务器模式。会话结束时,ORACLE会自动释放PGA所占用的内存区。

    1、会话区
    存储会话所具有的权限、角色、性能统计信息。
    会话内存(session memory)用于存储会话的变量(登录信息)及其他与会话有关的信息。对于共享服务器(shared server)而言,会话内存是共享的而非为某个会话所私有。

    2、堆栈区
    存储的是会话中的绑定便利、会话变量、SQL语句运行的内存结构等信息。

    3、游标状态区
    运行SQL语句或使用游标的语句时,ORACLE会在共享池中为该语句分配上下文区,游标实际是指向该上下文区的指针。在PGA区中的游标状态区存储的是会话
    中当前使用的各个游标所处的状态。
    Oracle 预编译程序(precompiler program)及 OCI 程序的开发者可以显式地打开游标(cursor)(游标即私有 SQL 区的句柄(handle)),
    并在程序运行过程中依据游标名称使用相关资源。当 Oracle 执行某些 SQL 语句时隐式提交的递归游标(recursive cursor)还需使用共享 SQL 区(shared SQL area)。

    4、排序区
    用于存放排序操作产生的临时数据,排序区是影响PGA区大小的主要因素。排序区的大小由初始化参数SORT_AREA_SIZE 决定。而SORT_AREA_RETAINED_SIZE
    参数是决定排序区操作结束后排序区保留的内存大小。从排序区释放的内存仍然属于服务器进程,并不返回给操作系统。
    ORACLE利用内存比磁盘快的事实,将准备排序的数据先临时存储到排序区中,并在排序区中执行排序操作,然后将排序结果返回给用户。
    排序原理:如果要排序的数据在排序区中放不下,则ORACLE就将数据分割成较小的块放在排序区中,然后对每一小块进行排序。排序产生的临时数据就先
    放到临时表空间的临时段中。当每一小块都排序完成之后,再将这些排序完成的小块合并在一起,产生最终结果。

    5、私有SQL区
    私有 SQL 区(private SQL area)中包含绑定信息(bind information)及运行时内存结构(runtime memory structure)等数据。
    每个提交了 SQL 语句的会话都有一个私有 SQL 区。每个提交了相同 SQL 语句的用户都有自己的私有 SQL 区,但她们使用同一个共享 SQL 区(shared SQL area)。
    即多个私有 SQL 区可以和同一个共享 SQL 区相联系。

    ?软件代码区
    于存储可运行的或正在运行的程序代码的内存空间。Oracle 系统程序的代码也存储在软件代码区,但其在此区域内的位置与用户程序完全不同,
    系统程序代码所在的位置更独立,且保护更严密。
    软件代码区的容量一般是固定的,只有软件升级或重新安装时才会改变。在不同的操作系统下,此区域所需的容量也有所不同。 软件代码区是只读的,
    此区域既可以为共享的,也可以为非共享的。在某些情况下,Oracle 代码可以由所有用户共享,这避免了相同代码的重复复制。因而节约了内存的使用,
    提高了系统的整体性能。
    用户程序同样既可以为共享的,也可以为非共享的。有些 Oracle 工具(例如 Oracle Form 和 SQL*Plus)可以是共享的,但有些就不能共享。
    当不同数据库的实例运行在同一计算机上时,她们可以使用同一个系统程序代码区。


    展开全文
  • oracle性能优化

    2015-04-15 13:09:24
    详细介绍了oracle性能优化方案,优化的方法,包含了:Oracle 性能调整-工具篇 ; Oracle 性能调整-内存篇; wait event 的基本解决办法dbca写; Statspack-v3.0=======eygle;
  • Oracle内存结构

    千次阅读 2018-07-26 17:26:22
    1.概述 Oracle数据库:每个Oracle都由一个数据库实例和一系列物理文件组成。 即,Oracle数据库由一系列后台进程、内存及文件组成。...2.Oracle内存 2.1 Oracle内存作用 当用户请求数据库中的数据时,Oracle实...
  • oracle 性能优化

    2015-08-26 08:40:14
    oracle 内存、参数、sql语句、调碎片整理
  • oracle内存数据库

    2012-07-13 11:32:37
    oracle 内存数据库,运算速度、优化方面很OK。
  • Oracle性能优化,内存优化,适合于初级和中级DBA学者,也可用于数据库急救用。
  • ORACLE内存结构

    千次阅读 2019-04-06 23:19:16
    为了对ORACLE数据库有一个基本的了解,我们首先需要理解ORACLE内存结构。           可以大体上将ORALCE内存分为以下几类: System Global a...
  • 简单说明: Oracle 内存管理模式: AMM(Automatic Memory Management) 该模式对Oracle使用的总内存(SGA+PGA)进行统一... 该模式与HugePage大页内存优化冲突 ASMM(Automatic Shared Memory Management) 该模式是...
  • oracle 查询优化

    千次阅读 2019-01-10 14:45:21
    oracle查询优化(一) 1、IN 操作符 用 IN 写出来的 SQL的优点是比较容易写及清晰易懂,这比较适合现代软件开发的风格。 但是用 IN 的 SQL 性能总是比较低的,从 ORACLE 执行的步骤来分析用 IN 的 SQL 与不用 IN 的...
  • oracle语句优化.docx

    2020-03-24 13:10:01
    oracle语句优化:多表关联,exists ,in ORACLE对每个SQL都会对其进行分析,占用共享内存,服务器当前性能(共享内存、磁盘文件碎片)、数据库对象(表、索引)统计信息
  • Oracle性能优化-大内存页配置

    千次阅读 2020-04-09 19:55:05
    如果您有一个大的RAM和SGA,那么HugePages对于Linux上更快的Oracle数据库性能是至关重要的。如果您的组合数据库SGAs很大(比如超过8GB,甚至对于更小的数据库也很重要),则需要配置更大的页面。请注意,SGA的大小很...
  • Oracle 内存 架构

    千次阅读 2011-06-26 12:43:00
      Oracle 内存 架构 详解 Oracle的内存配置与oracle性能息息相关。关于内存的配置,是最影响Oracle性能的配置。... 先看Oracle内存存储的主要内容是什么:程序代码(PLSQL、Ja
  • 详解 Oracle 数据库优化方案与实践时间 :2010-02-26 14:04:51 来源:网络 作者:未知 点击 :817 次 一前言 二 ORACLE 数据库优化概述 1内存等参数配置的优化 2减少物理读写的优化 3批量重复操作的 SQL 语句及大表操作...
  • Linux大内存Oracle数据库优化

    千次阅读 2015-07-16 10:27:32
    PC Server发展到今天,在性能方面有着长足的进步。...同时随着制造工艺的发展,在PC Server上能够安装的内存容量也越来越大,现在随处可见数十G内存的PC Server。正是硬件的发展,使得PC Server的处理能力越来越

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 101,033
精华内容 40,413
关键字:

oracle内存优化