分类目录归档：POC和性能调整

Exadata X5 上测试单进程impdp导入数据的效率

发表于 2015 年 4 月 23 日 由 Lunar

=========================================== 单进程，每分钟： 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

发表在 POC和性能调整 | 标签为 , | 留下评论

在Exadata X5-2（HC）测试创建31g各类文件和10Tbigfile的效率

发表于 2015 年 4 月 7 日 由 Lunar

本周要使用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分钟？） … 继续阅读 →

发表在 POC和性能调整 | 标签为 , | 留下评论

使用Oracle 11.2的DBMS_RESOURCE_MANAGER.CALIBRATE_IO对Exadata X5（HC）进行测试

发表于 2015 年 4 月 7 日 由 Lunar

之前测试的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的数值差不多 这是执行过程中的一个截图。

发表在 POC和性能调整 | 标签为 , , | 一条评论

使用Exadata的calibrate命令测试X5-2的IOPS和MBPS

发表于 2015 年 4 月 7 日 由 Lunar

之前测试的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 … 继续阅读 →

发表在 POC和性能调整 | 标签为 , , , , | 留下评论

Exadata上的HCC测试（EHCC）—3—分区表的压缩

发表于 2014 年 3 月 21 日 由 Lunar

Exadata上的HCC测试（EHCC）—2—：DBMS_COMPRESSION.GET_COMPRESSION_RATIO Exadata上的HCC测试（EHCC）——1 在分区表内部，不同分区可以不同的压缩类型：建立测试表 （注意，还可以按照列选择不同分区，具体参见文档的语法） 对比插入普通的表（Basic Compress）的时间和插入分区表（不同分区类型）的时间： 检查分区表各个分区的分区类型： 检查每种分区中的记录数据： 还可以按照rowid来查看压缩情况，输出为一个数字，代表压缩类型，具体的含义上面都有了：

发表在 POC和性能调整 | 标签为 , , | 留下评论

Exadata上的HCC测试（EHCC）—2—：DBMS_COMPRESSION.GET_COMPRESSION_RATIO

发表于 2014 年 3 月 21 日 由 Lunar

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:

发表在 POC和性能调整 | 标签为 , , | 留下评论

Exadata上的HCC测试（EHCC）——1

发表于 2014 年 3 月 21 日 由 Lunar

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哈哈~

发表在 POC和性能调整 | 标签为 , , | 留下评论

Exadata上一次POC的记录——PDML

发表于 2014 年 3 月 18 日 由 Lunar

下面的一次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。 .

发表在 POC和性能调整 | 标签为 , , | 一条评论

Exadata上的IOPS和MBPS

发表于 2014 年 3 月 18 日 由 Lunar

关于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) … 继续阅读 →

发表在 FAQ, POC和性能调整 | 标签为 , , | 留下评论

快速创建1000用户，每用户1000表，1000索引，1000个trigger

发表于 2014 年 3 月 4 日 由 Lunar

有时候为了方便测试，我们需要制造一些复杂的数据，比如这里，我们快速的创建1000用户，每用户1000表，1000索引，1000个trigger

发表在 POC和性能调整, Scripts | 标签为 , | 一条评论