1511g新特性可管理性.docx
- 文档编号:11357801
- 上传时间:2023-02-28
- 格式:DOCX
- 页数:27
- 大小:236.89KB
1511g新特性可管理性.docx
《1511g新特性可管理性.docx》由会员分享,可在线阅读,更多相关《1511g新特性可管理性.docx(27页珍藏版)》请在冰豆网上搜索。
1511g新特性可管理性
OracleDatabase11g:
面向DBA和开发人员的重要新特性
可管理性
将所有内存管理工作交给Oracle;自动获取仅针对您所使用的特性的可用补丁;收集优化程序统计信息并且在公布它们之前进行检查;让优化程序知道不同列之间的关系,等等。
内存管理
实质上,Oracle数据库实例是进程(如PMON和SMON)和内存区域(如系统全局区域(SGA)和程序全局区域(PGA))的集合。
SGA内还有若干子区域,如数据库缓存和大型池等。
您如何确定各个区域的大小呢?
主机内存有一个上限,同时内存的一些部分必须用于操作系统。
决定内存的分配是一件很难的事。
OracleDatabase10g为SGA_TARGET设置了一个值,而SGA_TARGET则为整个的SGA内存区域分配一个指定值,从而大大简化了这一问题。
各个子区域(如缓存和共享池)会随之自动调整。
不过,10g中的某些组件(如db_cache_keep_size)不会自动调整,您仍然需要手动调整。
内存区域PGA完全处于SGA之外,因此PGA根本不受自动SGA管理特性的影响。
因此您仍然需要作一些决定,如SGA和PGA的大小。
如果PGA的大小分配过多会发生什么情况,会使SGA极度缺乏吗?
如果这样的话,您会导致内存浪费,同时会因为SGA过小而导致性能降低。
但是,如果PGA和SGA之间的边界是不固定的,同时内存可以根据需要或者在需要时在二者间自由流动,那么会出现什么情况呢?
这的确会是一个非常有用的特性。
OracleDatabase11g提供了这一功能。
您可以指定MEMORY_TARGET,而不必设置SGA_TARGET和PGA_AGGREGATE_TARGET。
在EnterpriseManagerDatabase主页上,选择AdvisorCentral>MemoryAdvisor:
单击Enable启用AutomaticMemoryManagement:
单击OK。
您将需要重新启动数据库,因为MaxMemoryTarget的参数是静态的。
您也可以通过命令行来进行此操作:
SQL>altersystemsetmemory_max_target=1Gscope=spfile;
Systemaltered.
SQL>altersystemsetmemory_target=1Gscope=spfile;
Systemaltered.
在基于UNIX的系统中,最大内存应当小于/dev/shm共享内存文件系统的大小。
Linux、Solaris、HPUX、AIX和Windows已实现了此功能。
[oracle@oradba3dbs]$df-k
Filesystem1K-blocksUsedAvailableUse%Mountedon
/dev/mapper/VolGroup00-LogVol00
36316784194566841501526457%/
/dev/hda110108696328623511%/boot
none51744813144838600026%/dev/shm
此示例显示您仅有大约500MB可用,因此您将使用404MB作为MEMORY_TARGET。
在设置完该值并重复利用数据库后,您将会注意到屏幕发生了如下变化:
该屏幕显示了一段时间内SGA和PGA之间的详细划分。
屏幕的第二部分显示了SGA中子池的分配方式,以及它们的分配是如何随着时间变化的。
由于应用程序不断向数据库提出需求,这一分配会不断发生变化。
这样您可以从内存管理工作中解脱出来,但这可能只是最好的猜测。
和SGA组件的情况相同,如果单个组件也进行了指定,内存组件会受到最小值规则的约束。
例如,如果您作了如下指定:
memory_target=10G
sga_target=2G
pga_aggregate_target=1G
此时,memory_target设置值为10GB。
由于您已经指定了另外两个参数,它们将用作最小值。
这样,SGA和PGA的最小值将分别是2G和1G。
当内存需求上下波动时,内存区域也会缩小或扩大。
您可以在视图V$MEMORY_DYNAMIC_COMPONENT中检查它。
select
component,
current_size,
min_size,
max_size,
user_specified_sizeuser_spec,
oper_count,
last_oper_type,
last_oper_mode,
last_oper_time
fromv$memory_dynamic_components;
输出如下:
COMPONENTCURRENT_SIZEMIN_SIZEMAX_SIZEUSER_SPECOPER_COUNTLAST_OPER_TYPLAST_OPERLAST_OPER
------------------------------------------------------------------------------------------------------------
sharedpool1174405124194304117440512027GROWIMMEDIATE28-AUG-07
largepool41943040419430401GROWIMMEDIATE28-AUG-07
javapool1258291241943041258291204GROWIMMEDIATE28-AUG-07
streamspool00000STATIC
SGATarget134217728209715201342177280548GROWDEFERRED29-AUG-07
DEFAULTbuffercache4194304419430416777216012SHRINKIMMEDIATE28-AUG-07
KEEPbuffercache00000STATIC
RECYCLEbuffercache00000STATIC
DEFAULT2Kbuffercache00000STATIC
DEFAULT4Kbuffercache00000STATIC
DEFAULT8Kbuffercache00000STATIC
DEFAULT16Kbuffercache00000STATIC
DEFAULT32Kbuffercache00000STATIC
SharedIOPool00000STATIC
PGATarget0010485760010485760029GROWIMMEDIATE28-AUG-07
ASMBufferCache00000STATIC
另一个很有用的视图是v$memory_resize_ops,它存储有关进行的大小调整操作的信息。
select
start_time,
end_time,
status,
component,
oper_typeOp,
oper_mode,
parameter,
initial_size,
target_size,
final_size
fromv$memory_resize_ops
orderby1,2
/
START_TIMEND_TIMESTATUSCOMPONENTOpOPER_MODEPARAMETERINITIAL_SIZETARGET_SIZEFINAL_SIZE
------------------------------------------------------------------------------------------------------------
28-AUG-0728-AUG-07COMPLETESGATargetGROWIMMEDIATEsga_target125829120130023424130023424
28-AUG-0728-AUG-07ERRORDEFAULTbufferSHRINKIMMEDIATEdb_cache_size167772161258291216777216
cache
28-AUG-0728-AUG-07ERRORsharedpoolGROWIMMEDIATEshared_pool_size9646899210066329696468992
28-AUG-0728-AUG-07ERRORDEFAULTbufferSHRINKIMMEDIATEdb_cache_size167772161258291216777216
cache
28-AUG-0728-AUG-07ERRORsharedpoolGROWIMMEDIATEshared_pool_size9646899210066329696468992
28-AUG-0728-AUG-07PENDINGsharedpoolGROWIMMEDIATEshared_pool_size96468992100663296100663296
28-AUG-0728-AUG-07COMPLETEPGATargetGROWIMMEDIATEpga_aggregate_targ000
et
28-AUG-0728-AUG-07PENDINGsharedpoolGROWIMMEDIATEshared_pool_size100663296104857600104857600
28-AUG-0728-AUG-07COMPLETESGATargetGROWIMMEDIATEsga_target130023424134217728134217728
适应式阈值
考虑如下情形:
您数据库中的解析到命中率通常是一个定值,比如为x。
现在它上升了50%,变为1.5x。
在进一步调查之后,您看到存在大量的DSS类型查询,这是导致该数值上升的原因。
您还了解到这一行为(在夜间运行DSS类型查询)是完全可接受的。
因此,1.5x在夜间是没有问题的,或许它甚至可以达到2x。
因此,您希望阈值具有某种时间感知能力—白天的活动主要是基于OLTP,此时的阈值应当是1.2x,夜间的活动不同,相应的阈值应当是2x。
如何达到这些相互对立的目标呢?
OracleDatabase11g提供了一个名为适应式阈值的特性,使得该任务成为小事一桩。
这样的阈值可以适应于具体的时间,其依据是过去的行为和之前计算出的AWR快照。
与OracleDatabase11g的很多特性一样,这一任务有两种完成方式:
通过命令行和Oracle企业管理器。
我们看一下如何在GUI中完成该任务。
首先,您需要定义一个AWR基线,它类似于OracleDatabase10g中的保留快照。
基线相当于建立一个性能量度起点。
您可以使用基线比较量度随着时间的变化。
从主数据库的主页选择Performance选项卡,向下滚动查看AdditionalMonitoringLinks:
在该页上,单击第三列中的AWRBaselines,出现类似下面的屏幕:
该屏幕已包含一条基线:
SYSTEM_MOVING_WINDOW,它在OracleDatabase11g中已默认为启用。
单击Edit查看与该基线有关的任何阈值的变化。
出现如下所示的屏幕:
该屏幕显示了如何为量度CumulativeLogonspersecond定义阈值。
您可以定义基线的关键阈值(此处定义为60%)。
该阈值一旦设定,当任一时间内的累计登录次数超过上周同一天同一时间内登录次数最大值的60%且这一情况发生至少两次时,就会触发严重警报。
(60%是一个很低的限制,该值仅用于演示。
)
用户数会随着时间的推移而增长,警报阈值也将自动进行调整。
您不但可以决定最大值的百分比,而且可以定义具体的值作为临界值和阈值。
另一个参数Occurrences允许您仅当阈值被突破该参数指定的次数时才触发告警。
右侧的小图是在一段时间内量度出现的地方。
注意,小方框是个缩放工具。
您可以将它移动和放置到图形的任意区域上以显示详细信息。
正在审核的统计信息
考虑这样一种情况:
您已经仔细收集了关于所有表、索引等的统计信息,同时所有查询都有完善的执行计划。
但现在有人参与了统计信息收集工作,执行计划一下子变得截然不同。
没错,这些计划可能更好(但也可能更糟,虽然概率低些)。
避免这种灾难的一种方法是使用SQL计划管理,您可以用它来创建SQL计划基线,从而为SQL语句锁定计划。
但这并不是一个通用的解决方案。
看不到的SQL语句不会有SQL计划基线,因此不会受到SQL计划管理的保护。
另外一个问题是何时收集统计信息。
统计信息收集是一个大量占用CPU和频繁进行I/O的过程,您可能希望在相对安静的时间段(如晚上)完成这一工作。
但当统计信息收集完毕后,计划立即会受到影响。
您可能不希望一大早就要首先完成一个新的计划。
相反,您希望统计信息在夜间就能准备好以供使用。
矛盾在于,您需要现在就收集好统计信息而使其在以后生效。
这一难题已在OracleDatabase11g中得到解决。
您可以将表索引的统计信息定义为处于正在审核状态,这意味着新收集的统计信息不会被发布或为优化程序所使用—这样您就有机会在发布之前对新的统计信息进行测试。
要实现这一目的,您需要通过提供的程序包dbms_stats中的set_table_prefs过程将表统计信息的publish属性设置为FALSE。
下面的例子说明了如何使ARUP模式中SALGRADE表的统计信息处于未发布状态:
begin
dbms_stats.set_table_prefs(
ownname=>'ARUP',
tabname=>'SALGRADE',
pname=>'PUBLISH',
pvalue=>'FALSE'
);
end;
一旦您将发布首选项设置为false,收集的统计信息就将被标记为正在审核。
下面是现在该表的统计信息:
SQL>selectnum_rows,to_char(last_analyzed,'mm/dd/yyhh24:
mi:
ss')
2fromuser_tables
3wheretable_name='SALGRADE';
NUM_ROWSTO_CHAR(LAST_ANAL
--------------------------
609/10/0722:
04:
37
今天是2007年9月21日,因此统计信息是刚刚收集的。
我们再次收集统计信息:
begin
dbms_stats.gather_table_stats(
ownname=>'ARUP',
tabname=>'SALGRADE',
estimate_percent=>100
);
end;
/
如果您再次查看统计信息:
NUM_ROWSTO_CHAR(LAST_ANAL
---------------------------
609/10/0722:
04:
37
您可以看到行数没变,同时last_analyzed值也没变。
那么,刚收集的统计信息发生了什么变化呢?
统计信息被标记为正在审核。
正在审核的统计信息可在视图USER_TAB_PENDING_STATS中看到:
selectnum_rows,to_char(last_analyzed,'mm/dd/yyhh24:
mi:
ss')
fromuser_tab_pending_stats
wheretable_name='SALGRADE';
输出如下:
NUM_ROWSTO_CHAR(LAST_ANAL
---------------------------
909/21/0711:
03:
35
现在表有9行,显示正在审核的统计信息。
同时显示有收集时间。
假定您想让优化程序看到这些正在审核的统计信息。
您可以发布它们:
begin
dbms_stats.publish_pending_stats('ARUP','SALGRADE');
end;
/
如果您检查视图user_tab_pending_stats,您会发现它现在是空的。
如果您现在检查USER_TABLES,您会看到最新的统计信息:
NUM_ROWSTO_CHAR(LAST_ANAL
---------------------------
909/21/0711:
03:
35
这种将统计信息的收集和发布相分开的方法也可用于分区的表。
假定您正在逐个分区地加载一个表。
您不希望只提供部分信息给优化程序,您更希望所有分区的统计信息能够同时被优化程序看到。
但是您还想在加载分区后立刻利用这一时间。
那么,您可以在加载分区后立即收集它的统计信息,但不发布这些信息。
分析完所有分区后,您可以一次性发布这些统计信息。
检查正在审核的统计信息然后发布
对正在审核的统计信息的一个妙用是,收集它们并测试查询,然后发布。
要使优化程序使用正在审核的统计信息而非已发布的信息,将会话参数optimizer_use_pending_statistics设为true。
考虑一个名为RES的表,同时假定列STATUS有一个索引。
SQL>createindexin_res_statusonres(status);
使用cascade选项收集该表的统计信息。
begin
dbms_stats.gather_table_stats(
ownname=>'ARUP',
tabname=>'RES',
estimate_percent=>100,
cascade=>true
);
end;
列STATUS的值按如下所示分布:
STATUSCOUNT
(1)
-----------------
INVALID6
VALID68858
如果您发出一个类似selectres_typefromreswherestatus='VALID';的查询并检查执行计划:
--------------------------------------------------------------------------
|Id|Operation|Name|Rows|Bytes|Cost(%CPU)|Time|
--------------------------------------------------------------------------
|0|SELECTSTATEMENT||68858|1075K|290(3)|00:
00:
04|
|*1|TABLEACCESSFULL|RES|68858|1075K|290(3)|00:
00:
04|
--------------------------------------------------------------------------
PredicateInformation(identifiedbyoperationid):
---------------------------------------------------
1-filter(STATUS='VALID')
像预期地那样,此操作会对表RES进行全表扫描,这是因为表中有很多的行都有该值。
假定这一组合在将来发生了变化:
STATUSCOUNT
(1)
----------------
CLOSED68857
OK6
VALID1
注意,包含VALID的行的个数降为1。
此时,查询不应采用全表扫描,而应使用索引。
但是如果您运行查询并检查执行计划:
--------------------------------------------------------------------------
|Id|Operation|Name|Rows|Bytes|Cost(%CPU)|Time|
--------------------------------------------------------------------------
|0|SELECTSTATEMENT||68858|1075K|290(3)|00:
00:
04|
|*1|TABLEACCESSFULL|RES|68858|1075K|290(3)|00:
00:
04|
--------------------------------------------------------------------------
您将看到该查询仍然会进行全表扫描。
原因在于统计信息没有更新(是旧的)。
优化程序仍然认为包含值VALID的行的数目占大多数,因此会生成一个全表扫描计划。
您可以重新生成统计信息,这样可以纠正优化程序之前想好的进程,转而使用索引。
但是,这带来一个比较棘手的问题:
这会破坏某些其他的查询吗?
先不要猜测,请使用提供的程序包dbms_stats中的set_table_prefs过程,将表RES的PUBLISH首选项更改为false。
然后照常收集该表的统计信息。
由于现在统计信息正在审核中,优化程序不会使用它们。
不过,您可以确定它们对优化程序的影响。
一个专用的参数可以使优化程序使用正在审核的统计信息,而非已发布的信息。
SQL>altersessionsetoptimizer_use_pending_statistics=true;
现在,如果您检查该计划:
---------------------------------------------------------------------------------------------
|Id|Operation|Name|Rows|Bytes|Cost(%CPU)|Time|
-------
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 1511 特性 可管理性
![提示](https://static.bdocx.com/images/bang_tan.gif)