分类目录归档：Exadata

Exadata上HCC表的数据块结构—1-非压缩数据块结构

发表于 2014 年 3 月 23 日 由 Lunar

普通表的数据块结构网上已经铺天盖地了，我就不赘述了，看图：

发表在 Internal, 内部机制 | 标签为 , , | 留下评论

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和性能调整 | 标签为 , , | 留下评论

kcfis的相关隐含参数

发表于 2014 年 3 月 20 日 由 Lunar

记录一下kcfis的相关隐含参数：

发表在 Exadata, 内部机制 | 留下评论

Exadata上cell如何判断何时进行智能扫描？————2.在非Exadata环境的测试

发表于 2014 年 3 月 20 日 由 Lunar

创建测试表： 使用gdb跟踪： ———— 回到 session 2 —————- (gdb) c Continuing. 继续跟踪 ———— 回到 session 1 —————- 执行： LUNAR@lunar>select count(1) from lunar; ……. ———— 回到 session 2 继续跟踪 —————- ———— 回到 session 1 —————- 回到session 1，此时已经返回了结果： LUNAR@lunar>select count(1) from lunar; COUNT(1) … 继续阅读 →

发表在 内部机制 | 留下评论

Exadata上cell如何判断何时进行智能扫描？————1.在Exadata环境的测试

发表于 2014 年 3 月 20 日 由 Lunar

我们知道，SmartScan的先决条件是下面3个： 1，必须是对象上的全表扫描或者全索引快速扫描（TABLE ACCESS FULL或INDEX FAST FULL SCAN） 2，必须使用直接路径读取（Direct Path Read）。SmartScan的数据流是无法缓存在SGA缓冲池中的。直接路径读取可以串行，也可以并行，缓冲在进程的PGA(heap)中。 3，对象必须存储在Exadata的Cell节点上 . 在Exadata环境的数据库节点上： 1，ASM实例使用libcell11.a这个动态库跟cell节点通信, 2，数据库实例使用kcfis（ Kernel File Intelligent Storage ）执行SmartScan。 3，Diskmon进行心跳监控，I/O fencing和IORM 。 . 而cell节点上，主要是cellsrv（多线程的服务）完成相关的IO请求的操作（MS主要是监控，RS是重启其他进程） . 并且，对于Linux环境，Exadata和非Exadata上面安装的Oracle介质并无却别，那么有两个问题： 1，这两个环境是上执行计划为什么会不同（一个是全表扫描，一个是智能扫描）？ 2，cell在收到数据库节点的请求后，怎么判断是否执行只能扫描呢？ . 首先，在Exadata上大体有下面3种读取数据块的方式： 1，普通的block读：从磁盘读取数据块，读入到SGA 2，直接路径读：从磁盘读取数据块，读入PGA 3，智能扫描：由cell直接从底盘读取，读入PGA . 而在非Exadata环境，通常只有前两种。 我们分别用gdb跟踪一下。 首先在我的Exadata VM上测试： 创建测试表： … 继续阅读 →

发表在 内部机制 | 留下评论

使用 DECLI 配置Exadata上cell节点的celladmin的信任关系

发表于 2014 年 3 月 19 日 由 Lunar

在Exadata上缺省没有配置cell节点的celladmin用户的信任关系，但是有时候我们需要用，那么手工配置一下吧。 借助dcli工具，使得配置很简单：

发表在 FAQ, 日常运维 | 留下评论

HOW TO GENERATE SYSTEMSTATE ON THE CELLSRV TO IDENTIFY MEMORY LEAKS

发表于 2014 年 3 月 19 日 由 Lunar

1. Executing command kill -12 on the cellsrv pid. Identify the pid of cellsrv process -> ps -ef |grep ‘cellsrv 100’ kill -12 Example: 2. On the storage cell, obtain the statedump by running command from cellcli: 3. Provide to … 继续阅读 →

发表在 FAQ, 故障诊断 | 留下评论

在Exadata上修改操作系统用户口令的方法

发表于 2014 年 3 月 19 日 由 Lunar

注意修改完了要用这个用户登录一次才可以：

发表在 FAQ, 日常运维 | 留下评论