站内搜索
Oracle证书
分类目录
- ASM (30)
- Database (86)
- backup&recovery (21)
- expdp/impdp (5)
- Installation and Deinstall (31)
- network (7)
- ORA-600 or ORA-7445 (6)
- Performence Tuning (13)
- troubleshoooting (2)
- Dataguard (7)
- EBS (3)
- Exadata (120)
- FAQ (19)
- POC和性能调整 (11)
- 体系架构 (19)
- 内部机制 (22)
- 安装和升级 (14)
- 性能指标 (8)
- Exadata V1 (1)
- Exadata V2 (1)
- Exadata X2-2 (2)
- Exadata X3-2 (1)
- Exadata X4-2 (1)
- FAQ (1)
- 故障诊断 (3)
- 日常运维 (15)
- 硬件配置 (43)
- Exadata V1 (6)
- Exadata V2 (6)
- Exadata X2-2 (6)
- Exadata X3-2 (8)
- Exadata X4-2 (8)
- FAQ (1)
- FAQ (16)
- Internal (21)
- Linux (20)
- MYSQL (8)
- OGG (1)
- ORA-600/7445 (2)
- ORA-XXXXX (5)
- Oracle 11.1 & Oracle11.2 (6)
- ORACLE 12C (21)
- Oracle 8 & Oracle 8i (1)
- RAC (47)
- SAP (2)
- Scripts (6)
- 未分类 (1)
- 虚拟化 (1)
2024 年十一月 S M T W T F S « Nov 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 文章归档
-
近期文章
- 针对最近黑客攻击数据库的解决方案和预防建议
- CentOS7.2(RHEL 7.2)的CPU占用高(%system 占用高)
- Oracle 12.1 RAC 系列 – 配置第二个网络和相应的SCAN2
- Oracle 12.1 RAC 系列-安装新主机,识别老存储和恢复数据库
- Oracle 12.2的Sharding-1-基础概念
- 11.2 RAC 系列-安装新主机,识别老存储-3-配置老存储的数据库
- 11.2 RAC 系列-安装新主机,识别老存储-2-准备识别数据库
- 11.2 RAC 系列-安装新主机,识别老存储-1-识别ASM磁盘
- 2016年1月PSU列表
- 单实例数据库转换为RAC数据库–使用rconfig转换
近期评论
- tom 发表在《exadata巡检报告的模板》
- cyx 发表在《关于我》
- 李科胜 发表在《EBS克隆–db和app分开在两个服务器上》
- xiao 发表在《exadata巡检报告的模板》
- Chris Sun 发表在《使用Oracle 11.2的DBMS_RESOURCE_MANAGER.CALIBRATE_IO对Exadata X5(HC)进行测试》
分类目录归档:POC和性能调整
Exadata X5 上测试单进程impdp导入数据的效率
=========================================== 单进程,每分钟: 16G(每小时960G) 7分钟,导完LUNAR_P201404_1 请注意下面的过程 parallel=1,表示单进程测试 (只能测试单进程,是因为跟我同事的导出方式有关系,明天测试多进程……) =========================================== 导入过程中进行检测: 可以看到exadata聪明的选择了直接裸盘,没有走Flashcache,每秒钟吞吐量大概460MB左右(一起开始时候会有一个高峰大概有2倍的这个值,猜测是由于分配空间等等) 大概2~3分钟后,存储节点总的吞吐量稳定在每秒钟460MB: =========================================== 测试结果: 在数据库中实测的数据(按照每分钟这个表的增长大小来计算) 单进程,导入速度每分钟: 16G 7分钟,导完LUNAR_P201404_1,该表大概309GB(按照这个测试,每小时大概2.5TB左右) =========================================== =========================================== 注意上面: elapsed 0 00:07:02 也就是说,7分钟导入数据309GB
在Exadata X5-2(HC)测试创建31g各类文件和10Tbigfile的效率
本周要使用SwingBench对Exadata X5-2(HC)进行压测,因此,我提前准备了需要的表空间和redo等等。 1,首先看一下创建31g的数据文件的速度: 新增一个31g的数据文件,普通类型的数据文件,大概12秒左右: 对比一下EF550全闪存(可用空间也是20T,Exadata X5-2 QuarterRack也带了20T的闪存): 增加一个31g的临时表空间文件,大概不到20秒: 新增一个31g的undo表空间文件,大概不到30秒: 新增一个system的31g文件,时间比较长,大概不到80秒的样子: 新增一个SYSAUX表空间的文件大概20秒左右: 顺便测试了一下Exadata上创建10T bigfile的效率,具体命令如下: 这个过程执行了大概1小时,也就是在此环境下,创建10T的bigfile需要1小时时间,这个速度我感觉已经超快了: . 首先了解一下,offload和Smart Scan的关系。Offload在很多时候我们可以跟SmartScan理解为一致的东西。 它是指讲处理能力从数据库服务器下移到存储服务器的操作。 这一操作不仅转移了CPU的使用,更主要的是大大减少了返回到数据库层的IO: 1,减少存储系统和数据库服务器之间的传输数据量 2,减少数据库服务器上的CPU使用率(解压缩的操作发生在cell上) 3,减少存储层磁盘读取的时间 . 但是在某些情况下,还有一些其他非SmartScan类型的卸载(offload)操作: 1,智能文件创建(数据块在存储节点上被格式化) 2,Rman增量备份 . 在创建大表空间的时候,我们看到了等待事件“cell smart file creation” 这个正是我们期待看到的,这类IO走智能文件创建(Offload是Exadata的独门武器,而智能文件创建是非Smart Scan类型的一种IO卸载功能)。 整个创建bigtable的时间测算,测试期间,db节点和cell节点的CPU占用都很低: 每秒 6G 每分钟 360G 每小时 20T(既然是每小时20T,那么我的这个10T表空间为什么使用了1小时,而不是30分钟?) … 继续阅读
使用Oracle 11.2的DBMS_RESOURCE_MANAGER.CALIBRATE_IO对Exadata X5(HC)进行测试
之前测试的X3的flashcard的IOPS大概是满配200w左右(具体参见 《Exadata上的IOPS和MBPS》) 使用Exadata的calibrate命令测试X5-2的IOPS和MBPS 本次测试的机器是Exadata X5-2: CPU型号: 主机型号: . Oracle 11.2有一个DBMS_RESOURCE_MANAGER.CALIBRATE_IO,可以用来测试磁盘IO。 这里有几个需要注意的地方: 1,DBMS_RESOURCE_MANAGER.CALIBRATE_IO不能并行执行,否则会报错: 2,这个过程的测试,对于基准测试,我个人感觉非常不合适(数值严重偏低……不知道是不是需要调整什么参数,还是Exadata上就不应该用这个测试?) 3,测试中,指定延迟参数时,不能低于10秒(oracle的限制,估计是针对硬盘考虑的) 4,后面监控用的是Oracle已离职员工(凯耀,我的好兄弟)给的mon监控软件(底层基于开源的collect rpm包) 不过在新版本的exadata上貌似脚本还有些问题,因此,有些画图时丢失了(比如IOPS,比如flashcard的图) 5,测试脚本: 这里 102 是磁盘数量,10 是硬盘延迟 102的由来是因为,这个是一个Quarter Rack,使用onecommand安装后,缺省可用102个asmdisk,这个可以查询(V$ASM_DISK)。 下面是本次的测试结果: 这里看到IOPS大概1w多,吞吐量大概每秒3.5GB,最大延迟11秒。 这个数值跟使用mon(凯耀写的)监控的数量差不错: 这里看到磁盘的吞吐量大概每秒3.5GB/s,跟mon监控的差不多 IB的吞吐量大概是3.4GB/s 逻辑硬盘的IOPS是10000左右,跟使用cell上的calibrate的数值差不多 这是执行过程中的一个截图。
使用Exadata的calibrate命令测试X5-2的IOPS和MBPS
之前测试的X3的flashcard的IOPS大概是满配200w左右(具体参见 《Exadata上的IOPS和MBPS》) 使用Oracle 11.2的DBMS_RESOURCE_MANAGER.CALIBRATE_IO对Exadata X5(HC)进行测试 使用Exadata的calibrate命令测试时需要注意: 1,这个不能再业务高峰期操作,否则可能造成应用hang等。 2,一般测试的时候,是把cellsrv进程宕掉,否则就要带-force参数。 3,在老板上上,如果这个命令报错,还有一种可能的原因,就是它需要生成一些临时的lun配置文件,然后自己格式化。 如果报错,可以手工自己删除这些临时的lun文件。 新版本目前没有发发现这类问题,因为Oracle已经修改了脚本,所有的文件生成目录都是带日期的(启动测试的日期)。 因此,不会因为不能格式化lun等信息报错,如图 4,Exadata的calibrate命令底层采用orion的方法,根据自己预定义的lun组合,然后压测N轮 (不同的lun组合,压测好多次,自动的过程,无需手工干预) 5,Exadata的calibrate采用只读方式(保护数据安全) 6,不能再一个cell上并发两个calibrate,否则会报错的。 . 本次测试的机器是Exadata X5-2: CPU型号: 主机型号: 估算flash card的IOPS: 因此,理论上,这台X5-2 quarter rack的flash lun的IOPS总和超过 450万 . 而在之前测试的X3的flashcard的IOPS大概是满配200w左右(具体参见 《Exadata上的IOPS和MBPS》): 满配机器(14个cell)hard disk LUNs的MBPS推算: 1962*14个cell=27468 满配机器(14个cell)flash disk LUNs的MBPS推算: 4184*14个cell=58576 满配机器(14个cell)hard … 继续阅读
Exadata上的HCC测试(EHCC)—3—分区表的压缩
Exadata上的HCC测试(EHCC)—2—:DBMS_COMPRESSION.GET_COMPRESSION_RATIO Exadata上的HCC测试(EHCC)——1 在分区表内部,不同分区可以不同的压缩类型:建立测试表 (注意,还可以按照列选择不同分区,具体参见文档的语法) 对比插入普通的表(Basic Compress)的时间和插入分区表(不同分区类型)的时间: 检查分区表各个分区的分区类型: 检查每种分区中的记录数据: 还可以按照rowid来查看压缩情况,输出为一个数字,代表压缩类型,具体的含义上面都有了:
Exadata上的HCC测试(EHCC)—2—:DBMS_COMPRESSION.GET_COMPRESSION_RATIO
Exadata上的HCC测试(EHCC)——1 Exadata上的HCC测试(EHCC)—3—分区表的压缩 今天累了不多说了,官方文档都有: 使用DBMS_COMPRESSION时需要注意,不能两个会话同时使用,否则会报错,类似(2个会话会分别报下面的两个错误): 貌似从MOS还是哪里找到的脚本,很好用,其主要是利用了DBMS_COMPRESSION.GET_COMPRESSION_RATIO进行压缩率的测算: 上面的例子是Compress For Archive High,其他依此类推,测试用例参见:《Exadata上的HCC测试(EHCC)——1》 –Compress For Archive Low: –COMP_FOR_OLTP: –Compress For Query High: –Compress For Query Low: –COMP_NOCOMPRESS:
Exadata上的HCC测试(EHCC)——1
Exadata上的HCC测试(EHCC)—2—:DBMS_COMPRESSION.GET_COMPRESSION_RATIO Exadata上的HCC测试(EHCC)—3—分区表的压缩 Oracle 从8.1.5开始引入了“Index key compression”压缩,也就是重复的索引键值可以被压缩。 . 从9.2开始引入了“Data segment compression”,也就是我们说的“Basic compression”,但是该功能只有在批量数据加载时才生效(比如直接路径装载,CTAS等)。 . 从Oracle11.1版本引入了Advanced Compression,支持OLTP的压缩,也就是说可以支持INSERT,DELETE,UPDATE操作的压缩。 (正式发布的11g最早版本是2008年OOW上的11.1.0.6.x,2009年我就有客户用这个版本的了,而且一次上了4中平台的RAC,O(∩_∩)O哈哈~) . 当然,从11g开始,Oracle很多其他操作也支持压缩,比如,非结构化数据压缩(SecureFile数据压缩),Data Pump数据压缩,以及RMAN备份压缩等等,这里不做赘述。 支持OLTP的压缩,不代表每个DML语句执行时都会启用同步压缩,也就是说,只有当数据块中未压缩的数据达到一个阀值的时候,才会启动压缩,而不是每个DML语句之后都会压缩。如图: 关于压缩表的限制: 更多内容请参考 Notes 882712.1。 这里主要讨论下EHCC(Exadata Hybrid Columnar Compression ),官方文档说明如下: 关于测试创建各类压缩表的创建消耗的时间和IO的统计如下,我就不说了,有兴趣的自己看吧,O(∩_∩)O哈哈~
Exadata上一次POC的记录——PDML
下面的一次POC中的某2个语句的执行,可以看到除了CTAS创建的表名称不同,其余都是一样: 同样的都是Exadata x3-2,同样的环境(表结构,数据等等),但是执行效率却大相径庭: 从执行计划上看,SQL1执行时间了44秒: 1,在select阶段,所有Slave进程以直接路径读的方式并行的从cell上读取数据 2,所有Slave进程并行的将读取的数据发送给Query Coordinator,然后仍然以直接路径读取的方式并行的写入到数据文件 3,Query Coordinator进程从并行数据流中接收数据,并在所有并行写入结束后,将执行结果(Table created)反馈给SQL1 从执行计划上看,SQL1执行时间了9.3分钟: 1,在select阶段,所有Slave进程以直接路径读的方式并行的从cell上读取数据 2,所有Slave进程并行的将读取的数据发送给Query Coordinator 3,Query Coordinator进程等待所有Slave进程都执行结束后,将接收到的数据以直接路径度的方式写入到数据文件,将执行结果(Table created)反馈给SQL2 这个2个SQL的区别就在于PDML需要单独enable,缺省的只有SELECT会采用parallel。 也就是说,在执行SQL1之前,我执行了: alter session force parallel query; alter session force parallel dml; alter session force parallel ddl; . 而在执行SQL2的会话中,我没有enable PDML。 .
Exadata上的IOPS和MBPS
关于IOPS和MPBS的概念网上可以有很多详细的解释和介绍。 . IOPS (Input/OutputPer Second),,即每秒读写(I/O)操作的次数总和,多用于OLTP/数据库或者小IO/小文件等场合,衡量系统的随机访问的性能。 . 我们知道,磁盘完成一个I/O请求所花费时间就磁盘本身的因素来说,跟寻道时间、转数和数据传输都有关系。 也就是说, IOPS(每秒IO次数) = 1s/(寻道时间+旋转延迟+数据传输时间) . 而实际应用中IOPS还受到很多其他因素的影响,比如存储配置和不同操作系统上的相关配置等等(读写比例,顺序和随机,工作线程数,队列深度……),因此对比测量磁盘IOPS时应该在相同的测试基准下进行。 . 与之对应的是 MBPS ,另一个重要指标是数据吞吐量(Throughput),指单位时间内可以成功传输的数据数量。对于大量顺序读写的应用,如VOD(Video On Demand),则更关注吞吐量指标。 传统磁盘也就是我们常说的机械盘,如SAS, SATA磁盘等等,在Exadata的存储节点上每个cell配置了12块SAS盘或者SATA盘: Exadata V1 存储节点上磁盘的选择: 300 GB串行连接SCSI (SAS) 磁盘 或者 1TB串行连接(SATA) 磁盘(3.5寸) Exadata V2 存储节点上磁盘的选择: 600 GB串行连接SCSI (SAS) 磁盘 或者 2TB串行连接(SATA) … 继续阅读