分类目录归档:内部机制

根据块号查看块内数据和修改时间的例子(普通表和压缩表)

今天微信群里有个朋友问起一个问题,顺手做了个测试。 问题是这样的: 1,怎么根据file# block#来判断这个block中有多少数据? 2,启用了高级压缩后,如何查看? 3,怎么判断这些数据插入的时间? 4,不适用dump block的形式,可以怎么观察? 最后一个问题不用测试了,不用dump的话,可以使用类似bbed等一堆工具,还可以使用event 10046跟踪来观察。 本次始终压缩相关的脚本可以参考blog: Exadata上的HCC测试(EHCC)——1 Exadata上的HCC测试(EHCC)—2—:DBMS_COMPRESSION.GET_COMPRESSION_RATIO Exadata上的HCC测试(EHCC)—3—分区表的压缩 关于HCC压缩的块结构参见: Exadata上HCC表的数据块结构—1-非压缩数据块结构 Exadata上HCC表的数据块结构—2-BASIC Compress和OLTP Compress Exadata上HCC表的数据块结构—3-HCC块(compress for query low) 前三个问题,一次测试如下: 因为朋友问到ASM的情况,这个需求实际上跟是否使用ASM无关,是ORACLE DB的原理,测试环境如下: 随便找一个block,或者指定一个block都可以: 查看这个block中有多少条数据: 这里看到,目前这个block中存储了88行记录。 查看这88行数据是什么时间插入的,以及他们的ROWID: 这里看到有88行,跟前面的结果是一致的。 看看这个表中有多少个block,以及他们的块号: 因为要测试压缩,那么先看看现在该表的压缩状态,这里我的LUNAR表是没有压缩的: 这里的查询方法,参考: 现在启用压缩(HCC只能在exadata上,否则会报错): 再次查询,可以看到,已经是高级压缩了: 这里可以看到,rowid已经改变了,这是因为块的存储格式已经变化了: 看下现在这个LUNAR表使用了哪些block: 这里看到比刚才已经减少了17-12=5个block。 查询每个block中的记录数: … 继续阅读

发表在 Internal, 内部机制 | 标签为 , | 一条评论

oracle数据块如何定位到ASM中?在exadata定位block的思路是什么?

前几天有个朋友提出一个“老问题”,数据库上的block能否对应到EXADATA的block上,我答应做个demo,一直没时间,今天闲了,玩了一下: 对于EXADATA来说,这个需求设计两个问题: 1,数据库的block如何对应到asm中 2,exadata上的block如何对应到cell上的物理盘(griddisk,celldisk都是逻辑概念) 首先创建测试表: create table lunartest as select * from dba_users; –查找里面用户名为LUNAR的ROWID: 记录一下这个表的username=’LUNAR’的数据的rowid,便于验证数据。 然后找到该表的第一个block,也就是segment header,方法至少有3种 1,通过dbms_rowid 2,通过dba_extents 3,通过dba_segments 这里我们随便选一种,找到了该block的位置: 查看当前ASM的AU尺寸和BLOCK尺寸(通常是缺省的,不排除特殊客户自己设定的或者exadata的情况,因此还是找一下): exadata上使用KEFED的例子可以参考《Exadata上验证ASM磁盘头备份的位置》 我的数据库为8k的数据块(db_block_size),那么计算一下对应到ASM是哪一个extent: lunartest表在DATA DG的asm file 1755上: 如果是exadata,那么输出类似下面的,这里并没有本质区别(区别在通信方式上,后面会讲……): 根据上面的计算,查找这个表的第一个数据块在哪一个ASM的diskgroup,disk和AU的信息: 如果是exadata环境,那么查询到的信息,对应到这里的/dev/lunarlun02可能就是类似下面的:o/192.168.10.3/DATA_DM01_CD_00_dm01cel01: 这里也就对应到cell01(IP为:192.168.10.3) 具体例子可以参考:Exadata更换硬盘的操作过程和解释 使用dd 我们用dd验证一下数据,: 验证数据:这个LUNARTEST是根据DBA_USERS做的CTAS,因此上面我们有一行测试数据,这里可以找到: 因为是别人的生产库,不能使用bbed等工具瞎折腾,因此,我这里使用UltraEdit查看这个块来验证数据: 可以看到数据是吻合的。至此,上面将oracle的block对应到ASM是没问题的。 另外,如果要想观察asm的具体操作,还可以使用strace,比如 read64(15, … 继续阅读

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

Exadata上,ASM的Req_mir_free_MB 是如何得到的?

Exadata上,ASM的Req_mir_free_MB 是如何得到的? 首先,我们都知道,可通过v$asm_diskgroup来查看required_mirror_free_mb: 这里看到,实际上lsdg的输出跟v$asm_diskgroup是一致的(注意,早起的数据库版本由于rebalance时的bug,可能造成显示不一致,例如 Bug 7699985) 由于Exadata上,没有外部冗余,数据完全通过ASM镜像,那么就要考虑当磁盘故障或者cell故障时的数据保护,需要相应的根据Normal Redundancy或者High Redundancy来考虑分别两种情况: 1,在Normal Redundancy时,要考虑1块磁盘损坏或者1个cell不能启动时,如果修复时间超过缺省的3.6小时,需要使用现有系统中可用磁盘空间做Rebalance 2,在HighRedundancy时,要考虑2块磁盘损坏或者2个cell不能启动时,如果修复时间超过缺省的3.6小时,需要使用现有系统中可用磁盘空间做Rebalance Oracle根据内部算法,使用一个调解因子做系数,比如,不同版本的Oracle,评估方法不同: 如果数据库是11.2.0.3或者11.2.0.4,那么这个调解因子为1.10,如果是低于这个版本的数据库,调解因子是1.5(具体该因子的算法尚未知道) 对于每一个磁盘组,他们需要调解的空间大小(即,预留空间)=v$asm_diskgroup.required_mirror_free_mb * 调解因子 然后根据不同的镜像(Normal或者High),以及不同的Exadata配置(1/8,1/4、1/2,满配)再分别乘以一个系数,下面的代码根据每个磁盘组的最大的failgroup的大小来确定需要保留的空间: 然后,计算出来总共的需要“预留的空间”按照不同配置的Exadata乘以一个比例,就是我们这看到的 REQUIRED_MIRROR_FREE_MB: 对于Normal Redundancy: 对于High Redundancy: 完整的代码可在这里下载

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

Exadata和非Exadata平台上,ASM的可用空间如何计算?

曾经很多次,有客户问到ASM上可用的空闲空间问题,实际上,由于ASM带有3中冗余设置方式,分别应对不同场景的数据冗余情况,因此,通常在Exadata上的选择和非Exadata上的选择是不同的。 . 在非Exadata的环境中,通常我们会使用RAID,比如RAID10,因此ASM中使用External Redundancy,例如: ASMCMD> lsdg State Type Rebal Sector Block AU Total_MB Free_MB Req_mir_free_MB Usable_file_MB Offline_disks Voting_files Name MOUNTED EXTERN N 512 4096 1048576 51200 45862 0 45862 0 N CFARCH1/ MOUNTED EXTERN N 512 4096 1048576 51200 47653 … 继续阅读

发表在 ASM, FAQ, 内部机制 | 标签为 , , | 2 条评论

Exadata的磁盘自动管理-3-磁盘自动管理的操作规则

Exadata的磁盘自动管理-1-教你读懂cell alert中的磁盘相关信息 Exadata的磁盘自动管理-2-Cell上各种磁盘相关的概念 Exadata的磁盘自动管理-3-磁盘自动管理的操作规则 磁盘自动管理的一些条件和限制: 1. Griddisk 的状态改变时(OFFLINE/ONLINE): 如果一个griddisk的状态变为临时不可用(temporarily unavailable),那么它会在ASM中被自动的变更为OFFLINED。 如果一个griddisk的状态变成可用的(available),那么它会在ASM中被自动的变更为ONLINED 2. Griddisk的DROP磁盘的操作 如果一个物理盘(physicaldisk)失效了,所有在这个物理盘之上的griddisk都会在ASM中自动的以FORCE选项DROP。 如果一个物理盘(physicaldisk)的状态变为’predictive failure’,所有在这个物理盘之上的griddisk都会在ASM中被自动DROP。 ‘predictive failure’的概念参见前面的《Exadata的磁盘自动管理-1-读懂cell alert的磁盘信息》 如果一个flashdisk出现性能降级,相应的griddisk都会在ASM中自动的以FORCE选项DROP。 3. Griddisk的ADD磁盘的操作 如果更换了一个物理盘,该物理盘上对应的celldisk和griddisk都会被重新自动的创建,并且在创建后自动的加入到ASM中。当然,这个是要求换盘之前这个盘是完全自动管理的,也就是之前他是被自动的在ASM中drop的。 如果手工的drop了griddisk(不带force选项),那么就需要手工的将盘加回到ASM中。 如果griddisk是NORMAL状态,并且在ONLINE模式,那么使用FORCE选线drop了磁盘(这个模式通常必须使用FORCE选项),他也会被自动加回到ASM中。 4. 对CELL进行rolling upgrade时,Griddisk 的状态发生改变:OFFLINE/ONLINE Before the upgrade all griddisks will be inactivated on the storage … 继续阅读

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

Exadata的磁盘自动管理-2-Cell上各种磁盘相关的概念

Exadata的磁盘自动管理-1-教你读懂cell alert中的磁盘相关信息 Exadata的磁盘自动管理-2-Cell上各种磁盘相关的概念 Exadata的磁盘自动管理-3-磁盘自动管理的操作规则 首先明确一些Cell上各种磁盘相关的概念: 每个cell上有12块Physicaldisk,每个盘的容量相同,目前,X2的可以有600GB, 2TB和3TB(2T盘已经停产了),X3的只能有600GB和3TB,X4可以有1.2T和4T盘。 每块物理盘对应一个LUN(前面的2块盘,分别会划去一部分空间用来管理OS。后面的10块盘分别直接对应一个LUN),每个LUN对应一个CELLDISK。 每个cell上前两块盘的前面42G左右的空间做成软RAID1,后面的557G空间和其他10块盘使用方法一样,都是作为一个独立的celldisk的。 注意,celldisk是一个逻辑盘的概念。 这个信息在cell的配置文件中有明确说明 : 还可以使用下面的命令查看celldisk的容量: [root@dm01cel11 ~]# cellcli -e list griddisk where celldisk=CD_02_dm01cel11 attributes name,size,offset 每个cell上有16个Flashdisk(每个cell上4个PCI闪存卡,每个卡上集成4块flashdisk),X2是每个24G,X3是每个100G,X4是每个200G。 每一个Flashdisk对应一个Flash LUN,每个Flash LUN对应一个Cell Disk。 普通硬盘,即disktype=HardDisk的盘上创建的Celldisk缺省命名为CD_00_cellname,CD_01_cellname, …CD_11_cellname 基于FlashDisk的盘,即disktype=flashdisk的盘上创建的Celldisk缺省命名为FD_00_cellname, FD_01_cellname … FD_15_cellname. GridDisk是一些创建在一个或者多个celldisk上的逻辑盘。在Exadata的标准安装流程中,Griddisk只是使用基于硬盘创建的celldisk,而不使用基于Flashdisk创建的celldisk。 一般我们使用基于flashdisk创建的celldisk来做flashcache和flashlog。 在Exadata环境中,ASM DISK其实就是一个的griddisk。 在Exadata的标准安装中,一般会创建3个磁盘组,其中DATA DG和RECO … 继续阅读

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

Exadata的磁盘自动管理-1-教你读懂cell alert中的磁盘相关信息

Exadata的磁盘自动管理-1-教你读懂cell alert中的磁盘相关信息 Exadata的磁盘自动管理-2-Cell上各种磁盘相关的概念 Exadata的磁盘自动管理-3-磁盘自动管理的操作规则 从11.2.3.2.x开始,系统可以自动识别磁盘性能下降,并自动从当前配置中移除。 出现性能下降的磁盘会影响系统整体的性能表现,因为所有的工作负载是平均的分布到所有的磁盘的。 举个例子,如果一个磁盘有相对于其他的磁盘有30%的性能下降,那么整体的系统IO能力就会下降30%。 当检测到磁盘性能下降时,系统自动从当前配置将该盘移除。Exadata会执行一些列性能测试,如果这个磁盘的问题是临时问题,那么系统会自动将其放回原来的配置中。如果这个磁盘不能通过测试,那么就会被标记为性能不佳(pool performance),并自动开启一个ASR(Automatic Service Request)来请求更换磁盘。 这一特性对于硬盘和flash盘同样有效。 说到Exadata的IO能力和管理,必要要提到众所周知的CELLSRV。 CELLSRV是Exadata上存储服务器的主要组成部件,它是一个多线程服务器,主要针对简单的块请求和智能扫描请求(如投影和筛选的表扫描等)提供服务,另外,CELLSRV也与DBRM协同工作来计量各种数据库和客户组在发送IO时所用IO带宽。 CELLSRV收集与操作相关的大力统计信息。Oracle数据库和ASM进程使用LIBCELL和CELLSRV通信,LIBCELL使用iDB协议将IO请求转换为要发送给CELLSRV的消息。 CELL上跟IO相关的主要进程还有MS和RS。 MS(管理服务器),MS提供Exadata cell管理和配置的功能。它与命令行界面CELLCLI协同工作,每个CELL有CELLCLI进行单独管理。 CELLCLI是一个本地化的管理工具,也就是说他需要在某个特定CELL中管理该CELL。 不过,在Exadata上,可以用dcli实现远程地对多个CELL运行同一个CELLCLI命令来达到集成管理或者统一管理。dcli是一套集成的工具包,本质是通过SSH进行集成管理,可以单独配置(比如你自己有很多非Exadata的linux环境,可以根据需要配置dcli)。 另外,在CELL上,除了CELLSRV负责收集主要的统计信息外,MS也负责发送警报和收集其它统计信息。 RS(重启服务器),RS用于启动和关闭CELLSRV和MS服务,并监控这些服务进程的状态,在必要时负责重新启动cellsrv和ms。 前面说到CELLSRV会自动检测磁盘的性能,并自动更改配置。当CELLSRV检测到磁盘性能下降时,cell disk的状态就会更改为’normal – confinedOnline’,物理盘的状态更改为’warning – confinedOnline’。 这意味着磁盘已经进入了性能表现不佳的第一个阶段,这个阶段是个过渡阶段,磁盘状态不会停留在这个阶段很长时间。 通常磁盘的常见状态会有4种: HEALTH_BAD_ONLINE HEALTH_BAD_OFFLINE HEALTH_GOOD HEALTH_FAIL 这些检测和状态的变化,会有CELLSRV记录到alert中,例如: 同样的信息,在alerthistroy总也有可以观察到: 我猜测,上述信息是通过类似:下面这样的命令完成的: list griddisk attributes … 继续阅读

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

Exadata上HCC表的数据块结构—3-HCC块(compress for query low)

关于EHCC表的测试参见: Exadata上的HCC测试(EHCC)——1 Exadata上的HCC测试(EHCC)—2—:DBMS_COMPRESSION.GET_COMPRESSION_RATIO Exadata上的HCC测试(EHCC)—3—分区表的压缩 HCC(Hybrid Columnar Compression )是数据以CU(compression units )的方式存储,一个CU是由一组连续的block组成的,比如常见的是32k(即,4个连续的8k的block)。每个CU内部都是按列存储的数据,每一列都分别进行压缩,但是每一行数据都可以在一个CU内完全找到。 下面以”compress for query low”为例的数据块为例: 这次测试只dump了一个数据块,因此,不是一个很理想的说明,下次测试我会每个表多dump一些block,再加上表数据的内容,进行对比分析,这样才清晰。O(∩_∩)O哈哈~

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

Exadata上HCC表的数据块结构—2-BASIC Compress和OLTP Compress

OLTP 和 BASIC的压缩是符号表(a symbol table)的方式,老熊的blog已经讲的很清晰了,我怎么也不可能比老熊讲的清晰,不赘述了,看图:

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

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

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

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