《OracleExada特性简介及应用指南.doc》由会员分享，可在线阅读，更多相关《OracleExada特性简介及应用指南.doc（26页珍藏版）》请在三一办公上搜索。
1、2012年8月1前言2一Exadata概述31Exadata简介32Exadata的配置及性能参数3二Exadata特性41SmartScan（智能扫描）42StorageIndex（存储索引）73FlashCache（智能闪存）124Compression（压缩）&EHCC（ExadataHybridColumnarCompression）145IORM（IO资源管理）16三Exadata监控181Exadata特性监控常用指标182如何查看指标18四如何应用Exadata191Exadata参数调整192在Exadata上开发注意事项193应用总结204Exadata总体总结201 前言1
2、.1 本文背景前期东软-甲骨文公司组织了一次针对社保系统的Exadata联合应用测试，本文内容是本次Exadata测试的经验总结，其中包含了与Oracle技术人员交流经验应用、Oracle相关技术文档应用及个人测试经验总结。1.2 本文简介本文是关于ORACLEExadata的一些特性介绍和应用Exadata的一些指南；本文不会涉及太多传统ORACLEDataBase已经具有的而非Exadata专有的一些特性介绍。通过本文，读者可以了解ORACLE推出Exadata的目的和初衷，简单了解Exadata架构体系，了解Exdata的一些设计思路，了解其特性及其原理；了解Exadata的适合应用场景
3、，不适合应用场景，以及在Exadata下开发的一些注意事项（尤其是做Exadata项目主要设计、开发人员一定要了解Exadata，不要把它完全当作传统ORACLE数据库）。1.3 读者范围l 已经熟悉ORACLE数据库l 有Exadata相关项目l 想了解一些Exadata的特性原理和其实现细节一 Exadata概述1 Exadata简介1.1 ORACLEExadataDatabaseMachine1. ORACLEExadata数据库云服务器，把服务器、存储、数据库合理的整合在一起。2. 为满足大型数据库存在的性能瓶颈而推出的，最初为DW系统应用，后来也同时支持OLTP系统，成为一个支持混
4、合应用的系统。3. 包含DatabaseServer、ExadataStorageServer2 Exadata的配置及性能参数2.1 性能优势1. 是ShareNothing（StorageServer）与ShareDisk（DataBaseServer）结合的系统，有优点也有缺点。2. 是软硬件结合的系统，也是一个Balance系统，通过多CPU、大内存、多磁盘、Flashcard、Infiniband等合理搭配，再结合强大的软件系统，减少单一性能瓶颈；其主要是软件提升系统性能，而不是主要靠硬件。其性能好最主要原因是通过Offload（存储节点卸载）减少存储层与数据库层之间的传输数据量。3
5、. 对于要求吞吐量批处理业务操作来说，通过Offload（如cellSmartfilecreation、SmartScan、StorageIndex等技术）方式减少无用数据的交互，通过Compression使数据存储空间更小，通过DirectPathRead数据直接放到PGA中，而不占用SGA。4. 对于要求响应速度的单笔并发查询业务来说，通过FlashCache提供更大的IOPS。FlashCache同时也为大查询提供更高的带宽。5. 通过Infiniband使数据传输带宽更高，也降低RAC间争用。6. 通过ASM打散数据，避免热点IO。7. 再通过ResourceManager协调管理各个
6、业务系统可使用的资源。8. 再加上Database11gR2的分区、并行、并发、ResultCache等增加系统处理性能和能力。二 Exadata特性1 SmartScan（智能扫描）1.1 SmartScan带来什么1. 感性认识SmartScanSQL（到帐查询）SELECTcount(DISTINCTAB14.BAE204)FROMAB14,AB13WHEREAB14.BAE204=AB13.BAE204ANDNVL(AB14.BAE205,0)=0ANDNVL(AB14.BAE171,0)=1;记录数结果数据量3860527基表数据量响应时间FullTable01:53.46Smart
7、Scan00:35.011.2 SmartScan介绍1. SmartScan是什么1) 其设计思路区别以往系统，将处理能力从DB层下移到Storage层2) SmartScan在Storage层由软件实现2. SmartScan作用1) 过滤无用数据，减少提交到数据库服务器的数据量2) 即减少对网络及DB服务器压力减小，利用了存储的CPU资源3. SmartScan原理1) 字段过滤：selectcolumn2) 谓词过滤：wherecolumnjoincolumn4. SQL启用SmartScan必要条件（非充分条件）1) 必须是全扫描(1) FullTableScan(2) IndexF
8、astFullScan(3) BitmapScan2) 必须直接路径读取（DirectPathRead到PGA，普通方式读取到SGA不可以）3) 对象必须存储在ExadataStorage上（其他普通存储不可以）5. ORACLE提供参数禁用或启用SmartScan（默认启用）1.3 SmartScan特点1. 自动和透明，随时可以使用，不需要特殊处理1) SQL第一次执行就可以使用2) 不像StorageIndex那样需要ORACLE先建立才能使用3) 不像FlashCache那样需要ORACLE先缓存4) Where子句也不是必须的2. 使用特点1) 只适用于Query，不适用于DML2)
9、 按普通索引查询则无法使用SmartScan3) 没有类似BufferCache共享的目的，非常适合每次查询都是不重复的数据。4) 只返回符合条件的row和column，多余数据不返回5) 数据按照集合（非ORACLE块）返回到PGA中，不放入SGA6) 如果所有字段都查，并且没有where子句，那么SmartScan就无作用了1.4 SmartScan应用SQLsetautotonSQLselect/*+no_index(t)*/count(1)fromac42twhereaac001=;COUNT(1)-28已用时间:00:00:09.80执行计划-Planhashvalue:-|Id|O
10、peration|Name|Rows|Bytes|Cost(%CPU)|Time|-|0|SELECTSTATEMENT|1|7|1558K(1)|05:11:37|1|SORTAGGREGATE|1|7|*2|TABLEACCESSSTORAGEFULL|AC42|17|119|1558K(1)|05:11:37|-PredicateInformation(identifiedbyoperationid):-2-storage(AAC001=)filter(AAC001=)Note-automaticDOP:skippedbecauseofIOcalibratestatisticsaremi
11、ssing统计信息-1recursivecalls0dbblockgets6122224consistentgets6122176physicalreads0redosize347bytessentviaSQL*Nettoclient360bytesreceivedviaSQL*Netfromclient2SQL*Netroundtripsto/fromclient0sorts(memory)0sorts(disk)1rowsprocessedSQLsetautotoffSQLselect*fromv_flash;NAMEVALUE-cellflashcachereadhits292celln
12、umsmartIOsessionsusingpassthrumodeduetocellsrv0cellnumsmartIOsessionsusingpassthrumodeduetouser0cellphysicalIObyteseligibleforpredicateoffload5.0153E+10cellphysicalIObytessavedbystorageindex0cellphysicalIOinterconnectbytesreturnedbysmartscan7285736dbblockgets185dbblockgetsdirect0dbblockgetsfromcache
13、185dbblockgetsfromcache(fastpath)8physicalreadIOrequests288282physicalreadrequestsoptimized292已选择12行。已用时间:00:00:00.061.5 SmartScan总结1. SmartScan性能1) 性能很快，一般在秒级/10、秒级、分钟级2) 比普通全表扫描快很多3) 没有中等性能的传统Index快，没有中等性能的StorageIndex快，和不好的Index/StorageIndex差不多4) 结合StorageIndex使用，性能更好2. 根据其机制和测试结果，个人感觉：1) 为DW而设计，
14、更适用于类似DW系统等大数据量应用。2) 不太适用于要求响应时间和并发量的OLTP单笔业务系统中。3. SmartScan适用场景1) 适用于后台手工大数据查询(1) 如现场后台手工分析、统计一些数据2) 报表统计(1) 各类大报表的统计3) 前台各类大查询(1) 大数据量的查询4) 前台大业务模块的待处理数据的查询(1) 批量核定业务的未核定单位（个人）数据查询(2) 批量征集业务的待征集数据查询(3) 批量实收业务的到帐未实收数据查询5) Where条件选择性非常不好的各种查询(1) （日期、类别、状态、人数、金额。）6) 非常不常用、不重要的OLTP单笔业务4. SmartScan不适用
15、场景1) 后台批量业务的循环大SQL单次查询(1) 不能在forloop中的SQL使用SmartScan2) 前台并发大的小业务(1) 对于前台并发操作多，但很小的业务，如停续保、基本信息修改等5. SmartScan给系统设计开发带来的好处1) 对OLTP小业务无影响（不必考虑此特性，按原先方式设计开发）2) 减少大SQL过度优化3) 对于复杂大SQL直接用SmartScan，不用非要走各种索引4) 减少选择性非常不好的传统索引的建立2 StorageIndex（存储索引）2.1 StorageIndex带来什么1. 感性认识StorageIndexSQL（到帐查询）SELECTcount(
16、DISTINCTAB14.BAE204)FROMAB14,AB13WHEREAB14.BAE204=AB13.BAE204ANDNVL(AB14.BAE205,0)=0ANDNVL(AB14.BAE171,0)=1;记录数结果数据量3860527基表数据量响应时间FullTable01:53.46SmartScan00:35.01StorageIndex00:21.352.2 StorageIndex介绍1. StorageIndex是什么1) 不同于传统Index，非find需要的数据，而是filter不要的数据2) 在Storage层实现，非Server层3) StorageIndex保存
17、在cell节点内存中4) StorageIndex为每个存储单元（1m）数据块建立最大值和最小值2. StorageIndex作用1) 消除不必要的磁盘I/O3. StorageIndex原理1) 比较where条件与cell内存中的StorageIndex，不符合匹配条件的存储区间直接被跳过，由于被跳过部分数据不产生IO，因此大大减少磁盘I/O2) 类似Partition，不过是更小范围的分区4. StorageIndex如何管理1) StorageIndex由ORACLE内部来自动维护（包括建立、更新、清除等）(1) 第一次智能扫描(2) Ctas(3) InsertAppend(4) U
18、pdate2) 不需要也不能人工干预（内部机制不是特别清楚）3) 经常使用的列会有建立StorageIndex5. SQL启用StorageIndex启用必要条件（非充分条件）1) 必须是SmartScan方式2) 必须有where子句3) 并行查询6. ORACLE提供参数禁用或启用StorageIndex（默认启用）2.3 StorageIndex特点1. 特点1) 在内存中，速度快，也意味着重启即丢失2) 不同于传统Index，非find数据，而是filter不要的数据3) 自动和透明，返回的数据是完全一致的和事务级的4) 与普通索引机制不一样，不针对表建立，针对数据块建立,每1m数据块
19、建立最大最小值，空间小5) 最多8列6) 根据其过滤方式，表字段数据越有序，则存储索引效果越好2. 原则1) 只适合Query，不适合DML2) 按普通索引查询则无法使用StorageIndex3) 一般第二次查询可用上StorageIndex（首次查询用不上，因为StorageIndex还没有建立），查询后会重建StorageIndex4) 数据修改，ORACLE会维护存储索引（机制不清），有时可能会失效（不会导致错误）5) 字段值（非字段类型）为数字的可以使用存储索引，字段值存在字符型不使用2.4 StorageIndex应用SQLsetautotonSQLselect/*+no_inde
20、x(t)*/count(1)fromac42twhereaac001=;COUNT(1)-28已用时间:00:00:09.43执行计划-Planhashvalue:-|Id|Operation|Name|Rows|Bytes|Cost(%CPU)|Time|-|0|SELECTSTATEMENT|1|7|1558K(1)|05:11:37|1|SORTAGGREGATE|1|7|*2|TABLEACCESSSTORAGEFULL|AC42|17|119|1558K(1)|05:11:37|-PredicateInformation(identifiedbyoperationid):-2-sto
21、rage(AAC001=)filter(AAC001=)Note-automaticDOP:skippedbecauseofIOcalibratestatisticsaremissing统计信息-143recursivecalls0dbblockgets6122354consistentgets6122225physicalreads2088redosize347bytessentviaSQL*Nettoclient360bytesreceivedviaSQL*Netfromclient2SQL*Netroundtripsto/fromclient6sorts(memory)0sorts(di
22、sk)1rowsprocessedSQLsetautotoffSQLselect*fromv_flash;NAMEVALUE-cellflashcachereadhits80cellnumsmartIOsessionsusingpassthrumodeduetocellsrv0cellnumsmartIOsessionsusingpassthrumodeduetouser0cellphysicalIObyteseligibleforpredicateoffload5.0153E+10cellphysicalIObytessavedbystorageindexcellphysicalIOinte
23、rconnectbytesreturnedbysmartscan7277832dbblockgets66dbblockgetsdirect0dbblockgetsfromcache66dbblockgetsfromcache(fastpath)0physicalreadIOrequests48240physicalreadrequestsoptimized132已选择12行。已用时间:00:00:00.13SQL2.5 StorageIndex总结查询方式查询数据量基表数据量SmartScanStorageIndexIndex性能比较大表大数据量00:04.1500:00.8401:06.63
24、StorageIndex好中等数据量9539800:01.7100:00.1600:00.22相近大表小数据量2800:09.8000:08.8300:00.01Index好大表无索引386052700:35.0100:21.35XXStorageIndex/SmartScan1. StorageIndex性能1) StorageIndex对大SQL性能提升很大（使用得当，至少提高10倍以上）2) StorageIndex返回速度根据基表数据量、返回数据量、所查询字段分布，一般在1/100秒级-分钟级，达不到0.000n秒，一般也不会达到小时级2. 根据其机制和测试结果，个人感觉：1) 主要为
25、DW而设计，更适用于类似DW系统等大数据量应用。2) 不太适用于要求响应时间、大并发量的OLTP单笔业务系统中（还需项目验证）。3) 好的StorageIndex比不好的普通索引性能好，StorageIndex比SmartScan性能要好(1) 在大表小数据量查询时（比如100条以下），StorageIndex没有普通索引快（即选择性好的索引，比StorageIndex好）(2) 在大表大数据量查询时（比如10万条以上），StorageIndex比普通索引快很多（即选择性不好的索引，没有StorageIndex好）3. StorageIndex适用场景1) 适用于后台手工大数据查询2) 报表统
26、计3) 前台各类大查询4) 前台大业务模块的待处理数据的查询(1) 同SmartScan场景5) Where条件选择性非常不好（批次、年月、日期、状态、空值等。）的各种查询(1) 这类查询，不用建立对应的索引，直接采用StorageIndex6) 非常不常用、不重要的OLTP单笔业务4. StorageIndex不适用场景1) 后台批量业务的大SQL单次查询（不能在forloop中的SQL使用SmartScan。）2) 前台并发大的小业务（有待正式系统验证）5. StorageIndex给系统设计开发带来的影响1) 对OLTP小业务无影响（不必考虑此特性，按原先方式设计开发）2) 减少大SQL
27、过度优化3) 对于各类查询，可以结合实际，应用StorageIndex(1) 尽量保证字段值为数值型、日期型(2) 不要对字段做函数处理，如trunc，to_char(3) 尽量按顺序存储数据（包括数据转换）(4) 保证使用StorageIndex的列值有规律，比如顺序增长，不要无规律或者由多个序列生成（这样每1M的最大最小值都接近一样，StorageIndex失去意义）(5) 减少普通索引的建立，一些不常用字段、非选择性字段的索引可以不建立(6) 对于日期字段不要建立普通索引，直接利用存储索引(7) 减少过度优化，一些大SQL不必非要调整为走索引（当然不是不需要优化）3 FlashCache
28、（智能闪存）3.1 FlashCache带来什么1. 感性认识SQLselect/*+no_index记录数结果数据量基表数据量方式FullTableSmartScanStorageIndexIndexNOFLASHCACHE时间01:19.4000:09.2400:01.4201:19.02FLASHCACHE时间00:40.6200:04.1500:00.8401:06.633.2 FlashCache介绍1. FlashCache是什么1) 硬件，Flashcard2) StorageServerDisk的缓存（类似内存的DBBufferCache）2. FlashCache作用1) 提
29、升Exadata在OLTP业务下的性能2) 对DW业务性能也有很大好处3. FlashCache原理1) 缓存热数据，通过增加IOPs解决随机的I/O瓶颈(1) 读：先看Cache，没有再看Disk（也可能同时读），之后再把Disk的数据放入Cache（小数据才放，大数据不放）(2) 写：先写Disk，后续再同步Cache4. FlashCache管理1) 当作缓存用时，类似DBBufferCache，算法由ORACLE控制2) 对象（表、索引）缓存在FlashCache中的方式有三种（Keep，Default，Recycle）3) ORACLE提供方法清除FlashCache5. Flash
30、Cache使用必要条件1) 对象已缓存到FlashCache中，ORACLE自动读取FlashCache2) 其中缓存方式为Keep的对象更容易使用FlashCache3.3 FlashCache特点1. 在DBServerMEM与StorageServerDisk之间一层缓存，主要目的是为OLTP系统加快读取，对DW/DSS系统也有很大好处2. 性能、容量介于内存和存储之间，可提供更快的响应时间，更高的随机I/O，更大的带宽3. 可以指定表及索引的Cache方式4. 也可作为存储使用，可把表直接存储到上面5. 智能缓存，ORACLE自动管理，有类似LRU的算法6. 更适合读，大量读小量并发读
31、都有好处，不适合写3.4 FlashCache总结1. FlashCache性能1) FlashCache对系统整体性能有一定的提升2) 单笔带来的性能提升没有StorageIndex和SmartScan那样令人惊讶，单笔非并发，提升不到1倍2. FlashCache适用场景1) 适用于各类OLTP和DW业务，都可以带来好处3. FlashCache不适用场景1) 只写不读的系统（同步了不用，浪费资源）2) 频繁修改的系统（对于数据频繁同步到FlashCache，会有一定的性能影响）4. FlashCache给系统设计开发带来的影响1) 当作Cache使用(1) 对开发透明，具体编码不必考虑F
32、lashCache是否存在(2) 可把常用基础表以Keep方式缓存到FlashCache中；(3) 非常用表、大表由ORACLE自动管理default；(4) 频繁修改的表不要keep（具体效果还需要在项目中真正验证）2) 当作Disk使用(1) 常用表放入FlashCache（需要实际项目验证）(2) RedoLog放入FlashCache（实际可能不适用，需要实际项目验证）4 Compression（压缩）&EHCC（ExadataHybridColumnarCompression）4.1 EHCC带来什么1. 感性认识ObjectNameSize(M)压缩倍数FEE_COMPRESS_A
33、RCHIVE_HIGH8066.0FEE_COMPRESS_ARCHIVE_LOW11247.2FEE_COMPRESS_QUERY_HIGH11247.2FEE_COMPRESS_QUERY_LOW27219.4FEE_COMPRESS_BASIC8406.3FEE_COMPRESS_OLTP9445.6FEE_NOCOMPRESS52831.04.2 EHCC介绍1. EHCC是什么1) 多块（32k/64k）数据组成一个压缩单元（CompressionUnit）2) 每个压缩单元内按列来组织3) 非行压缩、非列压缩，介于行存贮和列存贮之间2. EHCC作用1) 为减少非活动数据占用空间，
34、为能提供更大的压缩比、压缩效率2) 可以避免行压缩的压缩率不好，列式压缩的访问性能不好的缺点3. EHCC原理1) 数据在压缩单元内按列来组织和压缩，非行压缩、非列压缩，介于行存贮和列存贮之间2) 四种类型（四种算法）压缩类型压缩率压缩时间访问性能Querylow最低（好于basic，OLTP）最短最好QueryhighArchivelowArchivehigh最高最长最差4.3 EHCC特点1. EHCC特点1) 提供了极大的压缩比，非常有效的减少存储空间2) 数据的解压缩被卸载到Exadata节点有效的减少了数据,库服务器节点的CPU开销3) 混合列压缩的索引机制和普通表的机制不一样，混合
35、列压缩QUERY、ARCHIVE不太适用于OLTP系统，小数据走索引的查询没有优势，OLTP系统可用普通压缩OLTP4) block是以压缩单元进行存储的；一个CU由多个block组成；而且数据再block中是以列进行的存储；这能够提高查询速度，但是其缺点如果查询一个行的所有列则会访问所有的block；所以要注意系统的单行读情况2. 压缩解压时机1) 所有的压缩是在DB层完成的；2) 但是当访问数据时：(1) 如果是进行的SmartScan，那么在进扫描时会在Storagecell中解压缩，并且解压缩的是需要访问的列，返回的数据全部是需要的数据，而不再需要过滤；(如果Storagecell较忙
36、，会在DB层完成)(2) 如果进行的是非SmartScan，那么数据的解压缩就是在DB层完成的；3. EHCC压缩发生DML后处理方式操作类型处理方式普通InsertOLTP压缩AppendEHCC压缩UpdateOLTP压缩4.4 EHCC应用createtableFEE(BAZ001NUMBER(16)notnull,BAZ002NUMBER(16),AAC001NUMBER(16)notnull,AAB001NUMBER(16)notnull,AAE002NUMBER(6)notnull,AAE011VARCHAR2(50),AAE036DATE)partitionbyrange(AAE
37、002)(partitionFEE_P199412valueslessthan(199412)COMPRESSFORARCHIVEHIGH,partitionFEE_P199503valueslessthan(199503)COMPRESSFORARCHIVELOW,partitionFEE_P199506valueslessthan(199506)COMPRESSFORQUERYHIGH,partitionFEE_P199509valueslessthan(199509)COMPRESSFORQUERYLOW,partitionFEE_P199512valueslessthan(199512
38、)COMPRESSFOROLTP,partitionFEE_P201201valueslessthan(201201),partitionFEE_PMAXvalueslessthan(MAXVALUE)tablespaceUSERSnologging;4.5 EHCC总结ObjectNameSize(G)压缩倍数FEE2_COMPRESS_ARCHIVE_HIGH2.0777.3FEE2_NOCOMPRESS1601.01. 根据其机制和测试结果，个人感觉，1) 有效降低存储空间2) 适用与DW系统，尤其适用于系统历史查询数据、历史归档数据的管理3) 不适用于频繁处理的OLTP系统，对DML操
39、作性能不好（DML操作后会转为OLTP方式压缩）4) 对Query，按索引单行访问不好，批量访问性能也许会更好（降低IO）2. EHCC适用场景1) 尤其适用于系统历史数据不访问，不处理（或极少处理）的压缩2) 列重复值比较多，有规律的表适合压缩（压缩率非常大）3. EHCC不适用场景1) 历史数据有DML操作的不适合压缩（DML操作后要转为OLTP压缩，多次处理以后，反而存储和性能都不好）2) 历史数据经常按索引做单条数据访问的不适合压缩（因为其多个块为一个单元，查询一条也要访问多块数据，性能不好）3) 很多列为空值的不适合（原先就不占空间，所以压缩效果不好）4) 列很多，并且值都很唯一的表
40、压缩不适合（这样压缩率低）4. EHCC给系统设计开发带来的影响1) 对海量大表不需要修改的历史数据需要考虑结合分区利用好压缩，大大降低存储空间的同时对性能影响不大5 IORM（IO资源管理）1. IORM属于ResourceManager的一部分；2. ResourceManage包含DBRM、IORM；3. 普通ORACLE数据库也有DBRM功能；5.1 ResourceManager介绍1. ORACLE资源管理器（ORACLEDatabaseResourceManager，简称DBRM）1) 管理数据库资源，为不同的会话分配不同的数据库资源。2) DBRM管理的资源主要包括CPU时间。
41、3) 实现服务器资源（如CPU和I/O）在不同数据库/资源组/会话间的分配。4) 控制系统资源（CPU、IO、parallel）使用的优先级5) 可按需分配平衡多负载下的资源占用2. DBRM在DBServer层控制CPU、parallel等资源3. IORM是在cell层控制IO资源5.2 ResourceManager特点1. 资源管理器部件组成：1) 资源用户组（Resourceconsumergroup）:根据数据库资源处理需求，将用户会话的资源请求将它们分为一组。DBRM按组管理会话的资源分配，而不是按单个的会话。2) 资源规划（Resourceplan）:指定哪些资源分配给资源用户
42、的命令；3) 资源分配方法（Resourceallocationmethod）:数据库资源管理器分配特殊资源时采用的方法，由资源用户组和资源规划来使用。4) 资源规划命令(Resourceplandirectives):管理员使用这些命令将资源用户组与特殊规划连接起来，并在资源用户组之间分配资源。资源计划指令指定了资源计划和组之间的映射关系。5) 一个资源规划对应多个资源用户组，而一个资源用户组对应多个指令。2. ResourceManager控制方式1) 可按照用户、服务、终端、模块等各个类别控制2) 可以扩展自定义配置，可在应用层统一配置（类似ORACLEVPD配置），实现不同业务的不同资源级别3. 使用方式，两种方式1) 单级别的资源管理策略GroupLEVE1实际G_A6060%G_B3030%OTHERS1010%(1) 当G_A只使用20%，剩余40%（60%-20%）按照比例3:1(30%:10%)分配给
