作者归档:Lunar

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, 内部机制 | 标签为 , , | 留下评论

insert 的enq: TM – contention的情况-2 —–只有主键约束无子表的情况

insert 的enq: TM – contention的情况-1 —–对有主外键关系的表的操作 insert 的enq: TM – contention的情况-2 —–只有主键约束无子表的情况 #################################################################################### 总结2 : 1,当存在pk时,无论有没有子表,对存在pk的表来说,无论有没有子表,update pk的操作会同时阻塞对该表做insert操作中那些pk跟update语句更改前、后两个值相关的会话。 2,当子表无事务时,我下面的简单的测试情况下(其他复杂情况没有测试)跟上述第一点结果相同 #################################################################################### 测试6: 在测试5的基础上,测试一下子表无事务的情况下,对父表的update是如何影响父表的delete和insert的 首先,我们在Session 4(SID 116)对做commit,此时session 2(SID 220)会自动解锁,并报出来应有的违反约束的错误ORA-02292: Session 4: 现在,我们把所有的会话都做commit或者rollback,然后观察对父表的updae会不会对父表的其他DML操作有影响: Session 2(SID 220): 这里看见session 4对父表的delete不受session 2在父表的update的影响,而session 5对父表的insert 会被session 2在父表的update阻塞 被阻塞的对父表的insert操作等待事件为:enq: TX … 继续阅读

发表在 FAQ | 标签为 | 留下评论

insert 的enq: TM – contention的情况-1 —–对有主外键关系的表的操作

insert 的enq: TM – contention的情况-1 —–对有主外键关系的表的操作 insert 的enq: TM – contention的情况-2 —–只有主键约束无子表的情况 #################################################################################### 总结1 :当外键无索引时 1,对子表的insert操作所在的事务没有完成前,对于父表的DML操作(INSERT/UPDATE/DELETE)都会因为不能获得对子表的TM锁而出现enq: TM – contention。 2,在总结1的基础上,如果又有了对子表的insert(我没有测试,但是我怀疑这里如果改成对子表的update和delete,也是相同道理……). 那么这个对子表的insert同样被阻塞,等待事件也是 enq: TM – contention。 3,对父表的insert会阻塞对父表的delete。同样的道理,此时对父表的insert也阻塞对父表的update pk操作。 #################################################################################### ######################################################### 当没有索引的时候: ######################################################### 测试1, 在子表发生:Insert,然后在父表上有update操作 Session 1: 对子表进行insert,不commit时: 这是,我们看到,该回话在主表(1062788 DEPT)和子表(1062790 EMP)上都分别持有了 exclusive … 继续阅读

发表在 Performence Tuning | 标签为 | 留下评论

一次体验N种报错的Oracle数据库恢复(ORA-704 ORA-604 ORA-600[25016] ORA-376)

朋友数据库报错: 使用隐含参数拉库: 这里看到由于他之前在OS上删除了文件,又重建了控制文件,因此数据字典中的文件信息和重建的控制文件不匹配 因此,报了上面的错误。 这时候使用使用隐含参数屏蔽system表空间检查,并屏蔽只读打开状态的字典检查,并使用gdb跳过数据字典检查,再次resetlog数据库试试看: 这里是AIX系统: 这是看到,已经跳过了数据字典检查,并且报错是ORA-00604 ORA-00376 ORA-01110 这个跟我以前处理自己的一次测试很相似了,参见《艰难的修复数据库过程,却发现Oracle 11.2果然强大》 alert信息如下: 再次尝试重建控制文件,使用gdb跳过字典检查,然后使用open upgrade尝试打开库(因为此时数据文件的scn都一致了): 尝试open数据库,发现数据库又出现了ORA-00600 [25016] 这至少说明一个问题,没有使用resetlogs的时候,控制文件并没有损坏,因此,不重建控制文件,直接恢复数据库,然后open upgrade: (CDKF177:oracle)/home/oracle>sqlplus / as sysdba 数据库已经open了。

发表在 backup&recovery | 标签为 , , , | 留下评论

RAC上ocr和voting disk从10.1到11.2维护操作和需求的差异

Oracle从10.1开始推出了自己真正意义的集群软件(9i和9i之前的版本,Oracle只有集群数据库,集群的存储和网络是由第三方厂商维护的,比如IBM的HACMP,HPUX的MC SERVICE GUARD /OA,SUN的suncluster,True64的Trucluster,linux就用ocfs和check-timer等等)。 因此,从10.1开始,oracle的集群有了自己的管理网络和存储的机制,ocr存放集群配置信息,voting disk用于磁盘心跳。 本文就简单的汇总一下各版本对于ocr和voting disk在一些维护操作和安装需求大致做个总结。 更改ocr(ocrconfig)和voting disk(crsctl replace votedisk)到其他的磁盘组—11.2 RAC 1,各个版本ocr和vot的空间需求: 2,各个版本ocr和vot的磁盘组权限: 3,voting disk个数的要求: For Voting disks (never use even number of voting disks): External redundancy requires minimum of 1 voting disk (or 1 failure group) Normal … 继续阅读

发表在 RAC | 标签为 , , | 留下评论

更改ocr(ocrconfig)和voting disk(crsctl replace votedisk)到其他的磁盘组—11.2 RAC

RAC上ocr和voting disk从10.1到11.2维护操作和需求的差异 检查当前的ocr所在磁盘: 添加+DBFS_DG作为新的存放ocr的磁盘组: 删除+DATA_DG上的ocr: 查看voting disk当前存放在哪个磁盘组(N中方法,这里直接在ASM里面看的): [oracle@dm01db01 ~]$ . ./env/grid.env [oracle@dm01db01 ~]$ asmcmd ASMCMD> 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 NORMAL N 512 4096 4194304 16625664 16624360 1511424 7556468 … 继续阅读

发表在 RAC | 标签为 , | 留下评论

MYSQL小白的FAQ系列—-7—-如何配置mysql主从同步(Master-Slave)

====================================== 主数据库master修改 ====================================== # 是master的日志文件,存放地址和名称 log-bin=/u01/mysql/data/binlog/mysql-bin.index log-bin=/u01/mysql/data/binlog/mysql-bin # 日志格式,建议mixed binlog_format = mixed # 主数据库端ID号 server-id = 1 #不同步哪些数据库 binlog-ignore-db = mysql binlog-ignore-db = test binlog-ignore-db = information_schema #只同步哪些数据库,除此之外,其他不同步 binlog-do-db = lunar #日志保留时间 expire_logs_days = 10 #控制binlog文件的更新频率。每执行n次事务保存一次 #这个参数性能消耗很大,但可减小MySQL崩溃造成的损失 sync_binlog = 1 … 继续阅读

发表在 FAQ, 复制 | 一条评论

升级到11.2.0.4的一些发现-3-catalog.sql的主要内容

升级到11.2.0.4的一些发现-1-catupgrd.sql大致解读 升级到11.2.0.4的一些发现-2-其他发现 升级脚本catupgrd.sql中,首先调用的catupstr.sql主要用于更新数据字典(里面还调用很多重要的创建基表的语句),例如: 之后,就是调用catalog.sql来创建各种数据字典,大概看了一下,记录如下:

发表在 Installation and Deinstall | 标签为 , | 留下评论

MYSQL小白的FAQ系列—-6—-如何查看mysql中的“元数据”(类似于oracle的数据字典)

mysql中,INFORMATION_SCHEMA提供了访问数据库元数据的方式. 元数据是关于数据的数据,如数据库名或表名,列的数据类型,或访问权限等。有些时候用于表述该信息的其他术语包括“数据词典”和“系统目录”。 在mysql5.5的官方文档中有以下内容: 第23章:INFORMATION_SCHEMA信息数据库 目录 23.1. INFORMATION_SCHEMA表 23.1.1. INFORMATION_SCHEMA SCHEMATA表 23.1.2. INFORMATION_SCHEMA TABLES表 23.1.3. INFORMATION_SCHEMA COLUMNS表 23.1.4. INFORMATION_SCHEMA STATISTICS表 23.1.5. INFORMATION_SCHEMA USER_PRIVILEGES表 23.1.6. INFORMATION_SCHEMA SCHEMA_PRIVILEGES表 23.1.7. INFORMATION_SCHEMA TABLE_PRIVILEGES表 23.1.8. INFORMATION_SCHEMA COLUMN_PRIVILEGES表 23.1.9. INFORMATION_SCHEMA CHARACTER_SETS表 23.1.10. INFORMATION_SCHEMA COLLATIONS表 23.1.11. INFORMATION_SCHEMA COLLATION_CHARACTER_SET_APPLICABILITY表 … 继续阅读

发表在 FAQ | 标签为 , , | 留下评论

MYSQL小白的FAQ系列—-5—-如何查看mysql中的历史命令

如何查看mysql中的历史命令: [root@lunar ~]# cat ~/.mysql_history _HiStOrY_V2_ show\040databases; FLUSH\040PRIVILEGES; show\040databases; create\040database\040lunardb; show\040databases; show\040user; show\040users; show\040tables; use\040lunardb show\040tables; use\040mysql show\040databases; show\040databases ; desc\040user; use\040lunardb desc\040user; use\040mysql help status connect? ; connect go go\040mysql ; select\040*\040from\040user; select\040*\040from\040users; show\040user; desc\040user; show\040databases; show\040columns\040from\040user; use\040test show\040user; … 继续阅读

发表在 FAQ | 标签为 , | 留下评论