月归档：2014 年十一月

奇怪的AWR–部分sql执行次数跟实际情况相差10倍之多

发表于 2014 年 11 月 29 日 由 Lunar

应用通知有个应用很慢，于是查原因 下面是AWR的采样时间： 从AWR可以看到该语句30分钟内，这两条应用反应慢的语句的执行次数分别在930万次和950万次，这个跟应用的反映差了一个数量级： 但是应用反映，实际上在应用中实际设置的加载量是10分钟25万次。 这就很奇怪了，首先用logminer随机抽查了10分钟的归档，并挖掘了数据: 根据Logminer的挖掘的结果，发现实际执行次数跟应用反馈的执行次数差不多，跟AWR的数据相差大概10倍： 再查一下其他语句： 检查awr发现，该语句的执行次数基本跟吻合。 这里也就是说，部分语句执行次数相差10倍，但是部分语句的执行次数又是正常的，奇葩！ 检查share pool，发现大量sql异常LUNARDB 这里的sql信息感觉严重失真，貌似重复了很多，也就是应该purge的sql在V$SQL中没有被更新，而是越积越多…… 重启服务器后，恢复正常，目前还没有找到具体的bug信息。

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

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

发表于 2014 年 11 月 28 日 由 Lunar

前几天有个朋友提出一个“老问题”，数据库上的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 —–只有主键约束无子表的情况

发表于 2014 年 11 月 18 日 由 Lunar

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 —–对有主外键关系的表的操作

发表于 2014 年 11 月 18 日 由 Lunar

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）

发表于 2014 年 11 月 9 日 由 Lunar

朋友数据库报错： 使用隐含参数拉库： 这里看到由于他之前在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维护操作和需求的差异

发表于 2014 年 11 月 6 日 由 Lunar

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

发表于 2014 年 11 月 6 日 由 Lunar

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）

发表于 2014 年 11 月 5 日 由 Lunar

====================================== 主数据库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的主要内容

发表于 2014 年 11 月 3 日 由 Lunar

升级到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的数据字典)

发表于 2014 年 11 月 2 日 由 Lunar

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