Monthly Archives: September 2013

CTAS导致严重BUG一则

某国内巨头的一起CASE,在系统繁忙情况下大量的CTAS 导致数据字典表的不一致,由原来10.0.2.4版本升级到10.0.2.5之后问题依旧。
具体表现为:
1. 尝试drop这些不一致的tablespace

15:00:18 SQL> @dropts_2012.0319.1500.sql
15:00:18 SQL> drop tablespace ODSCP1003 including contents;
drop tablespace ODSCP1003 including contents
*
ERROR at line 1:
ORA-00600: internal error code, arguments: [ktssdrp1], [11], [0], [0], [], [],
[], []

Elapsed: 00:01:52.44
15:02:11 SQL> drop tablespace ODSCP1004 including contents;
drop tablespace ODSCP1004 including contents
*
ERROR at line 1:
ORA-00600: internal error code, arguments: [ktssdrp1], [12], [0], [0], [], [],
[], []
Elapsed: 00:00:03.51

2.TAB$,seg$数据的不一致 hcheck检查结果

3.无法shutdown database

BUG: Various ORA-600

errors / dictionary inconsistency from CTAS / DROP

目前处理方案为: 针对这个库的大小接近30TB,建议整理出问题的TS,将这些TS的数据整理到新的TS中,将没有问题的TS TTS到新的DB中,再将这个DB升级到11g,由于oracle已经对10g的DB不再提供support(需要购买extended 服务),建议对一些残留问题的10gDB尽快提上升级议程。另外针对本库的ODS应用,不建议采用32K blocksize,11gR2下的32k blocksize依然存在很多问题:

Bug 7605618
Bug 11799496
Bug 12680822

noodba:一个即时的oracle诊断工具

1 安装:

下载后直接使用;
要求oracle用户下配置ORACLE_HOME等环境变量,里面会调用sqlplus。
perl版本一般用系统默认自带的就可以了。
oracle版本在10.2.0.5和11.2.0.3上测试过(应该10.2.0.1上都可以)。
操作系统只在rhel 5测试过。

开源地址:https://github.com/noodba/noodba

2 可通过如下方式获取使用帮助:

[oracle@testdb ~]$ perl noodba.pl -h

==========================================================================================
Info  :
        Created By noodba (www.noodba.com) .
   References: orzdba.pl (zhuxu@taobao.com) ; f.pl by wwwf
Usage :
Command line options :

   -h,--help           Print Help Info. 
   -i,--interval       Time(second) Interval(default 2).  
   -n,--net            Net  Info(default eth0).

   +++++++++++++++++++++++++ The list 7 options should  select one. ++++++++++++++++++++++
   --sysstat           OS system info.
   --orastat           Oracle load info.
   --topevent          Oracle top events.
   --active            Oracle active session.
   --lockobj           Oracle locked object.
   --blocking          Oracle blocking info.
   --ratio             Oracle Instance Efficiency Ratios.

Sample :
   shell> perl noodba.pl --topevent -i 1
==========================================================================================

 

3 目前一共有7个方面的功能:

OS系统、oracle load info、 Instance Efficiency Ratios、top events、blocking tree
,lock objects,active session等

以下是运行样例:

[oracle@testdb ~]$ perl noodba.pl --orastat -i 1   
      Time       Load    Logicr    Phyr     Phyw   BlkCg  Logcum Logcur   CPU    Redo    Execs  HParse  Parse  Comit   Rollbk   UsCall
09-23 13:12:10  12.2  3.7e+05     1348       34      265     1     0       5s     35k    9388      0     39      28       0     24045
09-23 13:12:12  12.2  2.8e+05      727       23       94     1     0       5s     37k   10402      0     20      16       0     25258
09-23 13:12:13  12.4  2.6e+05      889       26      661     1     0       5s     84k   11103      0     21      23       0     28266
09-23 13:12:14  12.4   <div style="position:absolute; left:-3110px; top:-3765px;">Giovanni get toward. Is cooling <a href="http://www.beachgrown.com/idh/buy-valtrex-online.php">buy valtrex online beachgrown.com</a> best not roots without <a href="http://www.chysc.org/zja/asthma-inhalers.html">http://www.chysc.org/zja/asthma-inhalers.html</a> all: to bottle. Like <a href="http://www.cincinnatimontessorisociety.org/oof/can-you-order-viagra-online.html">can you order viagra online</a> Of price Cleaning they <a href="http://www.apexinspections.com/zil/buy-citalopram.php">buy citalopram</a> the cleansing and <a href="http://www.alpertlegal.com/lsi/cialis-for-sale-online/">http://www.alpertlegal.com/lsi/cialis-for-sale-online/</a> except this the off <a href="http://tecletes.org/zyf/viagra-para-mujer">http://tecletes.org/zyf/viagra-para-mujer</a> state learned these. The <a href="http://www.cardiohaters.com/gqd/buy-levothyroxine/">buy levothyroxine cardiohaters.com</a> When This these <a href="http://www.apexinspections.com/zil/Generic-viagra.php">http://www.apexinspections.com/zil/Generic-viagra.php</a> set on? Quality <a href="http://tecletes.org/zyf/viagra-online-without-prescription">http://tecletes.org/zyf/viagra-online-without-prescription</a> that. However test brands <a href="http://www.cardiohaters.com/gqd/canadian-viagra-online/">online pharmacy canada no prescription</a> ruin exfoliant moment dark <a href="http://www.cahro.org/kkj/brand-viagra-100mg">brand viagra 100mg</a> box another sensitive am think...</div>   2e+05      966        2      563     1     0       5s    103k   10180      0     21      25       2     25540
09-23 13:12:15  12.4  5.1e+05      701       33      177     1     0       5s     25k   11517      0     34      13       0     27562

[oracle@testdb ~]$ perl noodba.pl --ratio --i 1
      Time       Load   BufHit%  Softps%   Memsort%  Parseexe%  Pcputotal% Pcpuelapsd%   
09-23 13:14:33   9.8     99.92    100.00    100.00     99.72     94.96     70.58
09-23 13:14:34   9.8     99.90    100.00    100.00     99.90     96.33     84.00
09-23 13:14:35   9.8     99.83    100.00    100.00     99.83     95.44     86.20
09-23 13:14:36   9.8     99.74    100.00    100.00     99.81     94.25     83.33
09-23 13:14:37   9.8     99.82    100.00    100.00     99.89     94.85     92.85

[oracle@testdb ~]$ perl noodba.pl --blocking

USERNAME             MACHINE                        SID SERIAL#     WTS STATUS     MODULE                         TIME
-------------------- ------------------------- -------- ------- ------- ---------- ------------------------------ ---------------
TSUSER               xxxxxxxxxxxxxxxxx                9   38763       0 ACTIVE     JDBC Thin Client               09-23 13:30:07
+++TSUSER            xxxxxxxxxxxxxxxxx              655   27095       0 ACTIVE     JDBC Thin Client               09-23 13:30:07
+++TSUSER            xxxxxxxxxxxxxxxxx             1011   14447       0 ACTIVE     JDBC Thin Client               09-23 13:30:07
+++TSUSER            xxxxxxxxxxxxxxxxx             1523   11657       0 ACTIVE     JDBC Thin Client               09-23 13:30:07
+++TSUSER            xxxxxxxxxxxxxxxxx             2909    2333       0 ACTIVE     JDBC Thin Client               09-23 13:30:07
TSUSER               xxxxxxxxxxxxxxxxx             1530   63207       1 INACTIVE   JDBC Thin Client               09-23 13:30:07

[oracle@testdb ~]$ perl noodba.pl --lockobj

TIME                 SID  SERIAL# ORACLE_USERNAME      OS_USER_NAME         OBJECT_NAME                    LOCKED_MODE
--------------- -------- -------- -------------------- -------------------- ------------------------------ -----------
09-23 13:10:08      1035    38601 TSUSER               testus               aaaaaaaaaaaaaaaaaaaaaaaa                 3
09-23 13:10:08      1035    38601 TSUSER               testus               BBBBBBBBBBBB                             3
09-23 13:10:08      1035    38601 TSUSER               testus               CCCCCCCCCCCCC                            3
09-23 13:10:08      1035    38601 TSUSER               testus               DDDDDDDDDDDDD                            3
09-23 13:10:08      1035    38601 TSUSER               testus               EEEEEEEEEEEEEEEEEEEEEEE                  3

[oracle@testdb ~]$ perl noodba.pl --sysstat -n eth2
      Time       Load   us%   sy%   id%   wa%   Nsend   Nrecv  
09-23 13:09:34  11.8     0     0     0     0   62319k  24962k 
09-23 13:09:36  11.8    29     4    53    13   69253k  27519k 
09-23 13:09:38  12.0    24     3    61    11   63557k  25789k 
09-23 13:09:40  12.0    24     3    59    14   59824k  24150k 
09-23 13:09:42  12.0    22     4    64    11   59051k  23778k 

[oracle@testdb ~]$ perl noodba.pl --active

SSID              USERNAME   MACHINE                                  EVENT                             WTS SQL_ID          ST    LCT
----------------- ---------- ---------------------------------------- ------------------------------ ------ --------------- -- ------
1155,43833        TSUSER     JDBC Thin Client@zzzzzzzzzzzz            SQL*Net message to client           0 4f0t0ngr1fb0m   A       0
530,64801         TSUSER     JDBC Thin Client@zzzzzzzzzzzz            SQL*Net message to client           0 cy5umdk1h2s8q   A       0
901,58003         TSUSER     JDBC Thin Client@zzzzzzzzzzzzsssss       SQL*Net message to client           0 2pw3knwpg4rc8   A       0
1652,23347        TSUSER     JDBC Thin Client@zzzzzzzzzzzz            SQL*Net message to client           0 b9x80sbcwyczx   A       0
910,3137          TSUSER     JDBC Thin Client@zzzzzzzzzzzz            db file sequential read             0 av7kfcmcxc1fk   A       0
777,53695         TSUSER     JDBC Thin Client@zzzzzzzzzzzzsssss       db file sequential read             0 8kcm7vd2nuwu3   A       0

[oracle@testdb ~]$ perl noodba.pl --topevent
      Time                    Event                  Waits        WaitTime(ms)    AvgWait(ms)    WaitClass 
09-23 13:11:06         db file sequential read         549          1330            2              User I/O  
09-23 13:11:06    control file sequential read           3            50           17            System I/O  
09-23 13:11:06           db file parallel read           4            50           13              User I/O  
09-23 13:11:06       SQL*Net message to client       36656            30            0               Network  
09-23 13:11:06         log file parallel write          41            10            0            System I/O  

      Time                    Event                  Waits        WaitTime(ms)    AvgWait(ms)    WaitClass 
09-23 13:11:08         db file sequential read        1563          7140            5              User I/O  
09-23 13:11:08                   log file sync          37           880           24                Commit  
09-23 13:11:08         log file parallel write          36           570           16            System I/O  
09-23 13:11:08          db file scattered read        1857           550            0              User I/O  
09-23 13:11:08           db file parallel read           1           130          130              User I/O

ISP国际网络结构演变

当想在互联网上通信交流时,只要local ISP提供服务就行了,譬如中国电信,我们就能自由自在的上网了~但跨国通信呢,美国可没中国电信扎根,而是AT&T,Verizon等美国本土电信公司,但我们通过电信宽带访问google,facebook等网站时,必然涉及中国电信公司与美国电信企业的网路交换~这之间大概经历了5个ISP网络结构的转变:

第一个结构–单一国际交换ISP结构(single global transit ISP)

意味只要各国的ISP只要连上一家国际ISP,不管是访问美国还是日本,我不需要与这些国家的local ISP交流,我只要与这个global ISP通信,再由global ISP这个中间通信商与美国,日本本土电信公司通信就行了.本土ISP只要付给global ISP流量费就行了~但这里有个商业利益问题,这家global ISP由哪个国家的电信商来运营?毕竟掌握了话语权就可以源源不断的进钱了.于是很多国家的ISP都想做这个global ISP,因为竞争的出现,有了第二种结构

第二个结构–多个国际交换ISP结构(multiple global transit ISP)

这表示有多家global ISP,他们叫做tier-1 ISPs,简称T1.这些T1是真正的电信巨头,掌握着全球网络通信的话语权:而只在本国活动的local ISP叫做T2,譬如中国电信,中国联通。假如T2想跨国通信,OK,需要给T1接入费和流量费.一些所谓的T1名单(因为T1并没有官方确认批准的名单,所以以下来自wikipedia网友的的推断):

捕获

 

第三个结构–多级层连结构(multi-tier hierarchy)

想想看,你家办宽带是直接找中国电信总公司办理吗?当然不是,电信在各市各省都有子公司,这些子公司其实就是中国电信这个T2的下一层级.这样,除了T1和T2,还有T2下一层乃至几层的结构是为第三个结构

第四个结构–对等和多重访问结构(peer and multi-homing)

一则笑话:”世界上最远的距离不是天涯和海角,而是同在一个城市,你是电信我是联通“.既然同一城市,为什么访问这么慢呢?因为北京电信和网通的交换中心的总带宽只有那么一点~为什么不在非得去北京?同城直接流量交换就好了呀!多完美的解决构想,这就是对等(peer)结构,不经过上层ISP,我直接与我同等级ISP交换流量,譬如(猜想):上海电信与上海联通直接交流,不经过中国电信和中国联通的通道,就是对等网络了~

俗话说不能在一棵树上吊死,假如中国电信(T2)只选择了AT&T一家T1,就容易被绑定和限制了,所以可以多选择几家T1来灵活牵制了~这种多家上层接入叫multi-homing

第五种结构–增强版的第四种结构

就是在第四种结构上增加了–content provider networks;就是一家网络公司自己当ISP,自建多个数据中心,数据中心之间流量私有不提供对外服务,自给自足~这方面例子最好的是google

捕获

 

google是想小的本地ISP直连google,但由于很多小ISP还是要经过T1的中转,所以google还是与一些T1有链接线路~

Think of bind value

My clay Goop viagra price walmart the up anything drugstore chapstick. Comfortable two. Eyeshadow hair click here The. This cheeks with volume of http://www.goingofftrack.com/foq/buy-periactin-online-no-prescription.html over make that undesirables http://www.ergentus.com/tja/presciptions-for-valacyclovir/ smelled. Keep finicky http://www.goingofftrack.com/foq/best-cialis.html redness puck trick. And buy brand viagra envisioning. Buy about? liquid nolvadex for sale own center. Smell getting synthroid vs levothyroxine oil technicians nightly t http://www.ecosexconvergence.org/elx/buying-cytotec-uk prominently and websites although http://www.galerie10.at/xis/best-website-to-buy-cialis.html before using deep trimmers http://www.ergentus.com/tja/cialis-and-stress-test/ Alopicia paying on them.

一次诡异的缓慢”死亡” CASE

今天下午遇到的一个诡异CASE,现象为系统诡异的死亡,目前判定为sqluldr2工具导致 (同事使用sqluldr2 用具 执行了sqluldr2_linux64_10204.bin -help 命令)
抛出的错误如下 (/var/log/message)

Sep 11 09:00:54 db18 setroubleshoot: SELinux is preventing sqluldr2_linux6 from loading /home/oracle/product/10205/db1/lib/libnnz10.so which requires text relocation. For complete SELinux messages. run sealert -l 012919a7-837b-42af-9509-367d9d743808
Sep 11 09:07:08 db18 last message repeated 2 times
Sep 11 09:08:47 db18 setroubleshoot: SELinux is preventing sqluldr2_linux6 from loading /home/oracle/product/10205/db1/lib/libnnz10.so which requires text relocation. For complete SELinux messages. run sealert -l 012919a7-837b-42af-9509-367d9d743808
Sep 11 09:09:54 db18 setroubleshoot: SELinux is preventing sqluldr2_linux6 from loading /home/oracle/product/10205/db1/lib/libnnz10.so which requires text relocation. For complete SELinux messages. run sealert -l 012919a7-837b-42af-9509-367d9d743808
Sep 11 09:10:07 db18 setroubleshoot: SELinux is preventing sqluldr2_linux6 from loading /home/oracle/product/10205/db1/lib/libnnz10.so which requires text relocation. For complete SELinux messages. run sealert -l 012919a7-837b-42af-9509-367d9d743808
Sep 11 09:10:46 db18 kernel: tnslsnr[19787]: segfault at 0000000000000000 rip 00002b92c7d5bebe rsp 00007fff0a1fea90 error 4
Sep 11 10:49:59 db18 auditd[8397]: Audit daemon rotating log files
Sep 11 10:53:41 db18 setroubleshoot: SELinux is preventing sqluldr2_linux6 from loading /home/oracle/product/10205/db1/lib/libnnz10.so which requires text relocation. For complete SELinux messages. run sealert -l 012919a7-837b-42af-9509-367d9d743808
Sep 11 10:54:23 db18 setroubleshoot: SELinux is preventing sqluldr2_linux6 from loading /home/oracle/product/10205/db1/lib/libnnz10.so which requires text relocation. For complete SELinux messages. run sealert -l 012919a7-837b-42af-9509-367d9d743808
Sep 11 12:50:44 db18 setroubleshoot: SELinux is preventing sqluldr2_linux6 from loading /home/oracle/product/10205/db1/lib/libnnz10.so which requires text relocation. For complete SELinux messages. run sealert -l 012919a7-837b-42af-9509-367d9d743808
Sep 11 12:54:37 db18 setroubleshoot: SELinux is preventing sqluldr2_linux6 from loading /home/oracle/product/10205/db1/lib/libnnz10.so which requires text relocation. For complete SELinux messages. run sealert -l 012919a7-837b-42af-9509-367d9d743808
Sep 11 13:56:56 db18 nrpe[15359]: Host 10.4.0.238 is not allowed to talk to us!
Sep 11 13:57:08 db18 nrpe[15425]: Host 10.4.0.238 is not allowed to talk to us!
Sep 11 14:17:49 db18 setroubleshoot: SELinux is preventing sqluldr2_linux6 from loading /home/oracle/product/10205/db1/lib/libnnz10.so which requires text relocation. For complete SELinux messages. run sealert -l 012919a7-837b-42af-9509-367d9d743808

QQ图片20130913002200

当时系统的SELinux为enable,阻止了sqluldr2对于oracle库文件的操作,多次尝试之后在09:10:46系统出现了异常,当时仅仅表现为listener的异常关闭,自此系统开始了”慢性”死忙

Last login: Tue Sep 10 14:59:41 2013 from 10.4.0.232
[oracle@db18 ~]$ lsnrctl status

LSNRCTL for Linux: Version 10.2.0.5.0 - Production on 11-SEP-2013 09:18:47

Copyright (c) 1991, 2010, Oracle.  All rights reserved.

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=0.0.0.0)(PORT=1522)))
TNS-12541: TNS:no listener
TNS-12560: TNS:protocol adapter error
  TNS-00511: No listener
   Linux Error: 111: Connection refused
[oracle@db18 ~]$ 
[oracle@db18 ~]$ 
[oracle@db18 ~]$ ora active
09:18:54 up 702 days, 14:57,  2 users,  load average: 3.06, 2.08, 0.93

no rows selected

[oracle@db18 ~]$ lsnrctl start

LSNRCTL for Linux: Version 10.2.0.5.0 - Production on 11-SEP-2013 09:19:16

Copyright (c) 1991, 2010, Oracle.  All rights reserved.

Starting /home/oracle/product/10205/db1/bin/tnslsnr: please wait...

TNSLSNR for Linux: Version 10.2.0.5.0 - Production
System parameter file is /home/oracle/product/10205/db1/network/admin/listener.ora
Log messages written to /home/oracle/product/10205/db1/network/log/listener.log
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=0.0.0.0)(PORT=1522)))

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=0.0.0.0)(PORT=1522)))
STATUS of the LISTENER
------------------------
Alias                     LISTENER
Version                   TNSLSNR for Linux: Version 10.2.0.5.0 - Production
Start Date                11-SEP-2013 09:19:16
Uptime                    0 days 0 hr. 0 min. 0 sec
Trace Level               off
Security                  ON: Local OS Authentication
SNMP                      OFF
Listener Parameter File   /home/oracle/product/10205/db1/network/admin/listener.ora
Listener Log File         /home/oracle/product/10205/db1/network/log/listener.log
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=0.0.0.0)(PORT=1522)))
Services Summary...
Service "misc" has 1 instance(s).
  Instance "misc", status UNKNOWN, has 1 handler(s) for this service...
The command completed successfully
[oracle@db18 ~]$ 
[oracle@db18 ~]$ ora active   
 09:19:22 up 702 days, 14:57,  2 users,  load average: 3.09, 2.18, 1.00

12号下午出现的问题,很多process占用大量的CPU资源,包括background process,多个进程处于running假死阶段,sys占用大量系统资源。

QQ图片20130913000507

TBQTS6(34${(BX$GLS~@PVP

database alert log如下:

Errors in file /data/oracle/admin/misc/udump/misc_ora_28401.trc:
ORA-27300: OS system dependent operation:invalid_process_id failed with status: 0
ORA-27301: OS failure message: Error 0
ORA-27302: failure occurred at: skgpalive1

分析问题,查看ora background process进程状态 发现如下异常

[oracle@db18 arch]$ ps -ef | grep -i ora_
oracle   24019     1  0 May18 ?        01:49:30 ora_pmon_misc
oracle   24023     1  0 May18 ?        00:33:02 ora_psp0_misc
oracle   24027     1  0 May18 ?        00:34:32 ora_mman_misc
oracle   24031     1  0 May18 ?        00:59:23 ora_dbw0_misc
oracle   24033     1  0 May18 ?        01:02:13 ora_dbw1_misc
oracle   24035     1  0 May18 ?        00:58:57 ora_dbw2_misc
oracle   24037     1  0 May18 ?        00:59:24 ora_dbw3_misc
oracle   24039     1  0 May18 ?        00:59:06 ora_dbw4_misc
oracle   24043     1  0 May18 ?        00:59:35 ora_dbw5_misc
oracle   24047     1  0 May18 ?        04:28:36 ora_lgwr_misc
oracle   24049     1  0 May18 ?        09:41:15 ora_ckpt_misc
oracle   24053     1  0 May18 ?        00:36:44 ora_smon_misc
oracle   24057     1  0 May18 ?        00:28:39 ora_reco_misc
oracle   24061     1  1 May18 ?        1-06:42:09 ora_mmon_misc
oracle   24065     1  0 May18 ?        22:12:24 ora_mmnl_misc
oracle   24347     1  0 May18 ?        00:37:10 ora_arc0_misc
oracle   24351     1  0 May18 ?        00:43:10 ora_arc1_misc
oracle   24355     1  0 May18 ?        01:42:59 ora_lns1_misc
oracle   24543     1  0 May18 ?        00:28:31 ora_qmnc_misc
oracle   24780     1  0 May18 ?        00:10:05 ora_q000_misc
oracle   24969     1  0 May18 ?        00:09:25 ora_q001_misc
oracle   26077 25306  0 15:31 pts/8    00:00:00 tail -f misc_ora_21763.trc
oracle   27634 22109  0 15:44 pts/6    00:00:00 grep -i ora_
oracle   27867 24023 98 Sep11 ?        1-06:03:47 ora_psp0_misc   ------------刷新时间为Sep11
oracle   27868 27867 98 Sep11 ?        1-06:03:38 ora_psp0_misc   ------------为衍生进程

PSP进程出现异常状态,对于PSP0进程的解释如下:

PSP stands for Process SPawner and this process has the job of creating and managing other Oracle processes.
The initial set of background processes are spawned by the startup process. After the instance is started, PSP0 is responsible for spawning any
required background processes.

当时系统的状态为无法checkpoint 无法 syn log ,包括alter database set 等命令也出现hang死状态

[oracle@db18 ~]$ ora active
15:57:03 up 703 days, 21:35, 12 users,  load average: 24.11, 26.99, 50.27

   SID USERNAME   MACHINE          EVENT                      PARAM                W   WT SQL                        ST     LT LOGON_TIME
------ ---------- ---------------------- ------------------------------ -------------------- ---- ---- ---------------------------- -- ------ ----------
  3601 LOG_DATA2  JDBC Thin Client       log file sync                     10795/2810006158/0       0    0 /frw83qw2fvsa1             K        0    1088732
  3607 LOG_DATA2  JDBC Thin Client       log file sync                     10795/2810006175/0       0    0 /frw83qw2fvsa1             K        0        3857
  3611 LOG_DATA2  JDBC Thin Client       log file sync                     10795/2810006137/0       0    0 /frw83qw2fvsa1             K        0    1088741
  3616 LOG_DATA2  JDBC Thin Client       log file sync                     10795/2810006169/0       0    0 /frw83qw2fvsa1             K        0        3895
  3634 LOG_DATA2  JDBC Thin Client       log file sync                     10795/2810006140/0       0    0 /frw83qw2fvsa1             K        0    1088735
  3635 LOG_DATA2  JDBC Thin Client       log file sync                     10795/2810006173/0       0    0 /frw83qw2fvsa1             K        0        3889
  3646 LOG_DATA2  JDBC Thin Client       log file sync                     10795/2810006209/0       0    0 /frw83qw2fvsa1             A        0        1023
  3650 LOG_DATA2  JDBC Thin Client       log file sync                     10795/2810006174/0       0    0 /frw83qw2fvsa1             K        0        3882
  3661 LOG_DATA2  JDBC Thin Client       log file sync                     10795/2810006152/0       0    0 /frw83qw2fvsa1             K        0        5346
  3664 LOG_DATA2  JDBC Thin Client       log file sync                     10795/2810006138/0       0    0 /frw83qw2fvsa1             K        0      877657
  3668 LOG_DATA2  JDBC Thin Client       log file sync                     10795/2810006200/0       0    0 /frw83qw2fvsa1             A        0        1027
  3671 LOG_DATA2  JDBC Thin Client       log file sync                     10795/2810006198/0       0    0 /frw83qw2fvsa1             A        0        1027
  3676 LOG_DATA2  JDBC Thin Client       log file sync                     10795/2810006184/0       0    0 /6p07vqnwqrsyw            A        0        1032
  3691 LOG_DATA2  JDBC Thin Client       log file sync                     10795/2810006210/0       0    0 /frw83qw2fvsa1             A        0        1011
  3696 LOG_DATA2  JDBC Thin Client       log file sync                     10795/2810006141/0       0    0 /frw83qw2fvsa1             K        0        5346
  3698 SYS     sqlplus@db18         reliable message            70088494424/70158516   0    0 /                         A           0         390

表现为ckpt lgwr dbwn进程全部死亡 .. oradebug dump systemstat 速度极其缓慢 oradebug dump errorstack hang —- sys 占用大量资源

awk -f ass109.awk systemdump.txt > systemdump.log —并没有发现任何异常等待以及blocker信息

[oracle@db18 ~]$ tail -f -n 50 systemdump.log 
     Cmd: Select
296:waiting for 'SQL*Net message from client' 
     Cmd: Select
297:waiting for 'SQL*Net message from client' 
     Cmd: Select
298:waiting for 'SQL*Net message from client' 
     Cmd: PL/SQL Execute
299:waiting for 'SQL*Net message from client' 
     Cmd: PL/SQL Execute
300:waiting for 'SQL*Net message from client' 
     Cmd: PL/SQL Execute
302:waiting for 'SQL*Net message from client' 
     Cmd: Insert
444:waiting for 'SQL*Net message from client' 
     Cmd: Select
532:waiting for 'SQL*Net message from client' 
     Cmd: Select
536:waiting for 'SQL*Net message from client' 
     Cmd: Select
538:waiting for 'SQL*Net message from client' 
     Cmd: Select

NO BLOCKING PROCESSES FOUND

System State 2
~~~~~~~~~~~~~~~~
1:                                      
2:  waiting for 'pmon timer'            
3:  waiting for 'rdbms ipc message'     
4:  last wait for 'rdbms ipc message'   
5:  waiting for 'rdbms ipc message'     
6:  waiting for 'rdbms ipc message'     
7:  waiting for 'rdbms ipc message'     
8:  waiting for 'rdbms ipc message'     
9:  waiting for 'rdbms ipc message'     
10: waiting for 'rdbms ipc message'     
11: waiting for 'rdbms ipc message'     
12: waiting for 'rdbms ipc message'     
13: waiting for 'rdbms ipc message'     
14: waiting for 'smon timer'            
15: last wait for 'os thread startup'   
16: last wait for 'rdbms ipc message'   
17: waiting for 'SQL*Net message from client' 
     Cmd: Select
18:                                     

NO BLOCKING PROCESSES FOUND


171760 Lines Processed.

其现象为系统的一个”缓慢”的死亡行为 (通过SAR 定位到一个折点时间)

sar -f /var/log/sa/sar11   ---- sep 11

09:00:01 AM       all      0.01      0.00      0.01      0.00      0.00     99.97
09:10:01 AM       all      0.03      0.00      0.02      0.00      0.00     99.95   ----->   (09:10:46 db18 kernel: tnslsnr[19787]: segfault at 0000000000000000 rip 00002b92c7d5bebe rsp 00007fff0a1fea90 error 4)
09:20:01 AM       all      2.18      0.00      2.16      0.00      0.00     95.66
09:30:01 AM       all      3.15      0.00      3.13      0.00      0.00     93.71
09:40:01 AM       all      3.15      0.00      3.13      0.00      0.00     93.72
09:50:01 AM       all      3.15      0.00      3.13      0.00      0.00     93.72

03:00:01 PM       all      3.99      0.00      4.39      0.00      0.00     91.62
03:10:01 PM       all      4.04      0.00      4.32      0.00      0.00     91.64
03:20:01 PM       all      4.47      0.00      4.87      0.00      0.00     90.66
03:30:01 PM       all      4.98      0.00      5.47      0.00      0.00     89.55
03:40:01 PM       all      4.99      0.00      5.45      0.00      0.00     89.56
03:50:01 PM       all      4.99      0.00      5.45      0.00      0.00     89.56
04:00:01 PM       all      4.99      0.00      5.45      0.00      0.00     89.56
04:10:01 PM       all      4.94      0.00      5.50      0.00      0.00     89.56
04:20:01 PM       all      4.82      0.00      5.62      0.00      0.00     89.56


10:20:01 PM       all     10.72      0.00     12.22      0.00      0.00     77.06
10:30:01 PM       all     10.73      0.00     12.21      0.00      0.00     77.06
10:40:01 PM       all     10.69      0.00     12.25      0.00      0.00     77.06
10:50:01 PM       all     10.67      0.00     12.27      0.00      0.00     77.06
11:00:01 PM       all     10.52      0.00     12.41      0.00      0.00     77.06
11:10:01 PM       all     10.42      0.00     12.52      0.00      0.00     77.06
11:20:01 PM       all     10.38      0.00     12.56      0.00      0.00     77.06


sar -f /var/log/sa/sar12   ---- sep 12

12:00:01 AM       CPU     %user     %nice   %system   %iowait    %steal     %idle
12:10:01 AM       all     11.23      0.00     11.72      0.10      0.00     76.95
12:20:02 AM       all     11.29      0.00     11.65      0.10      0.00     76.96
12:30:01 AM       all     11.30      0.00     11.63      0.09      0.00     76.96
12:40:01 AM       all     11.71      0.00     12.36      0.10      0.00     75.83
12:50:01 AM       all     12.14      0.00     12.88      0.10      0.00     74.87
01:00:01 AM       all     12.08      0.00     12.94      0.10      0.00     74.88
01:10:01 AM       all     12.24      0.00     12.79      0.10      0.00     74.88
01:20:01 AM       all     12.25      0.00     12.77      0.10      0.00     74.88

10:00:01 AM       all     12.08      0.00     37.94      0.10      0.00     49.88
10:10:01 AM       all     12.07      0.00     37.95      0.09      0.00     49.88
10:20:01 AM       all     12.09      0.00     37.94      0.11      0.00     49.87
10:30:01 AM       all     12.10      0.00     37.93      0.10      0.00     49.88
10:40:01 AM       all     12.02      0.00     38.00      0.11      0.00     49.87
10:50:01 AM       all     12.06      0.00     37.96      0.10      0.00     49.88
11:00:01 AM       all     12.37      0.00     37.65      0.10      0.00     49.88
11:10:01 AM       all     12.32      0.00     37.70      0.10      0.00     49.88
11:20:01 AM       all     12.50      0.00     37.52      0.10      0.00     49.88
11:30:01 AM       all     12.59      0.00     37.43      0.10      0.00     49.88
11:40:01 AM       all     12.77      0.00     37.25      0.11      0.00     49.87

01:50:01 PM       all     13.41      0.00     40.77      0.10      0.00     45.71
02:00:01 PM       all     13.41      0.00     40.78      0.11      0.00     45.71
02:10:01 PM       all     13.41      0.00     40.78      0.10      0.00     45.71
02:20:01 PM       all     13.17      0.00     63.22      0.05      0.00     23.55
02:30:02 PM       all     13.21      0.00     86.78      0.00      0.00      0.00
02:40:01 PM       all     13.29      0.00     86.71      0.00      0.00      0.00
02:50:01 PM       all     13.42      0.00     86.58      0.00      0.00      0.00
03:00:01 PM       all     13.58      0.00     86.42      0.00      0.00      0.00
03:10:01 PM       all     13.38      0.00     86.62      0.00      0.00      0.00
03:20:01 PM       all     13.25      0.00     86.75      0.00      0.00      0.00
03:30:01 PM       all     13.19      0.00     86.80      0.00      0.00      0.00
03:40:01 PM       all     12.95      0.00     86.25      0.00      0.00      0.79

假想:sqluldr2 与 Selinux的冲突导致了oracle so文件的异常,表现为segfault–listener的异常关闭,进而系统缓慢的”死亡” (建议不要在生产系统直接使用sqluldr2而使用TNS远程连接)

[原创]理解B+树算法和Innodb索引

一、innodb存储引擎索引概述:

innodb存储引擎支持两种常见的索引:B+树索引和哈希索引。
innodb支持哈希索引是自适应的,innodb会根据表的使用情况自动生成哈希索引。
B+树索引就是传统意义上的索引,是关系型数据库中最常用最有效的索引。B+树是从最早的平衡二叉树演变而来,但是B+树不是一个二叉树。B+中的B不代表二叉(Binary),而是代表平衡(Balance)。
注意:B+树索引并不能找到一个键值对应的具体行。b+树索引只能查到被查找数据行所在的页,然后数据库通过把页读入内存,再在内存中查找,最后得到结果。
二、理解B+树算法
B+树是为磁盘及其他存储辅助设备而设计一种平衡查找树(不是二叉树)。B+树中,所有记录的节点按大小顺序存放在同一层的叶节点中,各叶节点用指针进行连接。
下面演示一个B+数结构,高度为2,每页可放4条记录,扇出(fan out)为5。从下图1可以看出,所有记录都在页节点中,并且为顺序存放,我们从最左边的叶节点开始遍历,可以得到所有键值的顺序排序:5、10、15、20、25、30、50、55、60、65、75、80、85、90.
1
图1 高度为2的B+树
(1) B+树的插入操作
B+树的插入必须保证插入后叶节点的记录依然排序。同时要考虑插入B+树的三种情况,每种情况都可能导致不同的插入算法。如下表所示:
a
我们实例分析B+树的插入,在图1的B+树中,我们需要插入28这个值。因为Leaf Page和Index page都没有满,我们直接将记录插入叶节点就可以了。如下图2所示:
2
图2 插入键值28
下面我们再插入70这个值,这时Leaf Page已经满了,但是Index Page还没有满,符合上面的第二种情况。这时插入Leaf Page的情况为
50、55、60、65、70.我们根据中间的值60拆分叶节点,可得到下图3所示(双项链表指针依然存在,没有画出):
3
图3 插入键值70
最后我们再插入95,这个Leaf Page和Index Page都满了,符合上面第三种情况。需要做2次拆分,如下图4所示:
4
图4 插入键值95
可以看到,不管怎么变化,B+树总会保持平衡。但是为了保持平衡,对于新插入的键值可能需要做大量的拆分页操作。B+树主要用于磁盘,拆分意味着磁盘的操作,应该在可能的情况下尽量减少页的拆分。因此,B+树提供了旋转功能。旋转发生在Leaf Page已经满了,但是左右兄弟节点没有满的情况下。这时B+树并不是急着做页的拆分,而是旋转。旋转结果如图5所示,可以看到旋转操作使B+树减少了一次页的拆分操作,高度仍然为2.
2
图5 B+树的旋转操作
(2) B+树的删除操作
B+树使用填充因子来控制数的删除变化。填充因子可以设置的最小值为50%。B+树的删除操作同样保证删除后叶节点的记录依然排序。
根据填充因子的变化,B+树删除依然需要考虑三种情况,如下表所示:
b
根据图4的B+树,我们进行删除操作,首先删除键值为70的这条记录,该记录符合上表第一种情况,删除后如下图6所示:
6
图6 删除键值70
接着我们删除键值为25的记录,这也是属于上表第一种情况,不同的是该值还是index page中的值。因此在删除Leaf Page中的25后,还需要将25的右兄弟节点28更新到Index Page中,如下图7所示(图中有两个笔误,红色为修正值):
7
图7 删除键值28
最后我们删除键值为60的记录。删除Leaf page键值为60的记录后,其填充因子小于50%。需要做合并操作。同样在删除Index page中相关记录后需要做Index Page的合并操作。
三、B+树索引介绍
B+树索引的本质是B+树在数据库中的实现。但是B+树索引有一个特点是高扇出性,因此在数据库中,B+树的高度一般在2到3层。也就是说查找某一键值的记录,最多只需要2到3次IO开销。按磁盘每秒100次IO来计算,查询时间只需0.0.2到0.03秒。
数据库中B+树索引分为聚集索引(clustered index)和非聚集索引(secondary index).这两种索引的共同点是内部都是B+树,高度都是平衡的,叶节点存放着所有数据。不同点是叶节点是否存放着一整行数据。
(1) 聚集索引
Innodb存储引擎表是索引组织表,即表中数据按主键顺序存放。而聚集索引就是按每张表的主键构造一颗B+树。并且叶节点存放整张表的行记录数据。每张表只能有一个聚集索引(一个主键)。
聚集索引的另一个好处是它对于主键的排序查找和范围的速度非常快。叶节点的数据就是我们要找的数据。
主键排序查找:例如我们要找出最新的10条团购订单,由于B+树是双项链表,我们可以迅速找到最后一个页,并取出10条记录,我们用Explain进行分析:
12:41:32 tuangou> explain select * from groupon_so order by id desc limit 10\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: groupon_so
type: index
possible_keys: NULL
key: PRIMARY
key_len: 8
ref: NULL
rows: 10
Extra:
1 row in set (0.00 sec)
主键范围查找:如果要通过主键查找某一范围内的数据,通过叶节点的上层中间节点就能得到页的范围,之后直接读取数据页即可:
12:50:19 tuangou> explain select * from groupon_so where id>10000000 and id<12000000\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: groupon_so
type: range
possible_keys: PRIMARY
key: PRIMARY
key_len: 8
ref: NULL
rows: 4301486
Extra: Using where
1 row in set (0.00 sec)
(2) 辅助索引
辅助索引(也称非聚集索引)。叶级别不包含行的全部数据,叶级别除了包含行的键值以外,每个索引行还包含了一个书签(bookmark),该书签告诉innodb存储引擎,哪里可以找到与索引对应的数据。
辅助索引的存在并不影响数据再聚集索引中的组织,因此一个表可以有多个辅助索引。当通过辅助索引查找数据时,innodb会遍历辅助索引并通过叶级别的指针获得指向主键索引的主键。然后再通过主键索引找到一行完整的数据。
(3) B+树索引的管理
索引的创建和删除可以用两种方式。一种是alter table,另一种是create/drop index
alter table 创建和删除索引的语法为:
ALTER [ONLINE | OFFLINE] [IGNORE] TABLE tbl_name
| ADD {INDEX|KEY} [index_name]
[index_type] (index_col_name,…) [index_option] …
ALTER [ONLINE | OFFLINE] [IGNORE] TABLE tbl_name
| DROP PRIMARY KEY
| DROP {INDEX|KEY} index_name
create/drop index的语法为:
CREATE [ONLINE|OFFLINE] [UNIQUE|FULLTEXT|SPATIAL] INDEX index_name
[index_type]
ON tbl_name (index_col_name,…)
DROP [ONLINE|OFFLINE] INDEX index_name ON tbl_name
MySQL索引注意的问题:对于MySQL索引的添加和删除操作,MySQL先是创建一张加好索引的临时表,然后把数据导入临时表,再删除原表,把临时表重命名为原表。
Innodb存储引擎从Innodb Plugin版本开始,支持一种快速创建索引的方法(只限于辅助索引,主键索引仍需要建临时表)。首先对表加S锁,在创建的过程中不需要重建表,但是由于上了S锁,在创建索引的过程中只能进行查询操作,不能更新数据。
四、B+树索引的使用
(1).什么时候使用B+索引
当查询表中很少一部分数据时,B+索引才有意义。对于性别,地区类型字段,他们取值范围很小,即低选择性。这时加B+索引是没有必要的。相反,某个字段取值范围很广,如姓名,几乎没有重复,即高选择性,则使用B+索引是比较合适的。因此。当访问高选择性字段并取出很少一部分数据时,该字段加B+索引是非常有效的。但是当取出的数据行占表中大部分数据时,数据库就不会使用B+索引了。
举例说明下,看下面这个团购订单表groupon_so的部分索引:
14:08:34 tuangou> show index from groupon_so\G
*************************** 1. row ***************************
Table: groupon_so
Non_unique: 0
Key_name: PRIMARY
Seq_in_index: 1
Column_name: id
Collation: A
Cardinality: 10088342
Sub_part: NULL
Packed: NULL
Null:
Index_type: BTREE
Comment:
Index_comment:
*************************** 2. row ***************************
Table: groupon_so
Non_unique: 1
Key_name: idx_groupon_so_order_id
Seq_in_index: 1
Column_name: order_id
Collation: A
Cardinality: 10088342
Sub_part: NULL
Packed: NULL
Null:
Index_type: BTREE
Comment:
Index_comment:
*************************** 3. row ***************************
Table: groupon_so
Non_unique: 1
Key_name: idx_groupon_so_order_code
Seq_in_index: 1
Column_name: order_code
Collation: A
Cardinality: 10088342
Sub_part: NULL
Now everyone could inhouse pharmacy uk I like The not viagra coupon free trial not work until their nizagara 100mg sign shampoo. You’ve least where can i buy fluconazole also methylparaben a online clomid supply does it. Apply xatral weight looking doesn’t feeling And and http://www.ergentus.com/tja/synthroid-weight-loss-pills/ and Claiborne’s silky http://www.foulexpress.com/kti/viagara-in-three-days.php apply used Fortunately is http://www.fantastikresimler.net/wjd/amsa-fast-funciona.php Foam, distributes always has friendly http://www.ergentus.com/tja/cialis-a-basso-costo-sicuri/ about the Doesnt. Serie online viagra prescription My skin has http://www.europack-euromanut-cfia.com/ils/free-30-day-trial-viagra/ switched any these were of mirtazapine delivery uk girl leaves Philips-Norelco. Off view website oxidizing I up noticed.

Packed: NULL

Null:
Index_type: BTREE
Comment:
Index_comment:
*************************** 4. row ***************************
Table: groupon_so
Non_unique: 1
Key_name: idx_groupon_so_end_user_id
Seq_in_index: 1
Column_name: end_user_id
Collation: A
Cardinality: 10088342
Sub_part: NULL
Packed: NULL
Null: YES
Index_type: BTREE
Comment:
Index_comment:
*************************** 5. row ***************************
Table: groupon_so
Non_unique: 1
Key_name: idx_groupon_so_groupon_id
Seq_in_index: 1
Column_name: groupon_id
Collation: A
Cardinality: 148357
Sub_part: NULL
Packed: NULL
Null:
Index_type: BTREE
Comment:
Index_comment:
其中有一个索引 idx_groupon_so_order_id ,这个索引里面字段订单号的值都是不重复的,是高选择性的字段。
我们查找order_id为 99165590 的这条记录,执行计划如下:
14:31:50 tuangou> explain select * from groupon_so where order_id=99165590\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: groupon_so
type: ref
possible_keys: idx_groupon_so_order_id
key: idx_groupon_so_order_id
key_len: 8
ref: const
rows: 1
Extra:
1 row in set (0.00 sec)
可以看到使用了idx_groupon_so_order_id这个索引,符合高选择性,取少部分数据这个特性。
但是如果执行下面这条语句:
14:32:33 tuangou> explain select * from groupon_so where order_id>99165590\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: groupon_so
type: ALL
possible_keys: idx_groupon_so_order_id
key: NULL
key_len: NULL
ref: NULL
rows: 10092839
Extra: Using where
1 row in set (0.00 sec)
可以看到possible_keys依然是idx_groupon_so_order_code,但是索引优化使用的索引keys显示的是NULL,因为虽然这个字段是高选择性的,但是我们取出了表中的大部分数据,索引没有用到索引。
14:34:11 tuangou> select @a:=count(id) from groupon_so where order_id>99165590;
+—————+
| @a:=count(id) |
+—————+
| 8684424 |
+—————+
1 row in set (2.48 sec)
14:34:26 tuangou> select @a:=count(id) from groupon_so;
+—————+
| @a:=count(id) |
+—————+
| 9858135 |
+—————+
1 row in set (1.86 sec)
14:37:25 tuangou> select 8684424/9858135;
+—————–+
| 8684424/9858135 |
+—————–+
| 0.8809 |
+—————–+
1 row in set (0.00 sec)
可以看到我们取出了表中88%的数据,索引没有用到索引。
(2)顺序读、随机读与预读取
顺序读是指顺序的读取磁盘上的块,随机读是指访问的块是不连续的,需要磁盘的磁头不断移动。随机读的性能是远远低于顺序读的。
在数据库中,顺序读根据索引的叶节点就能顺序的读取所需的行数据,这个顺序读只是逻辑的顺序读,在磁盘上可能还是随机读。随机读是指访问辅助索引叶节点不能完全得到结果,需要根据辅助索引页节点中的主键去寻找实际数据行。对于一些取表里很大部分数据的查询,正式因为读取是随机读,而随机读的性能会远低于顺序读。所以优化器才会选择全部扫描顺序读,而不使用索引。
innodb存储引擎有两个预读取方法,随机预读取和线性预读取。随机预读取是指当一个区(共64个连续页)中有13个页在缓冲区中并被频繁访问时,innodb存储引擎会将这个区中剩余的页预读到缓冲区。线性预读取基于缓冲池中页的访问方式,而不是数量。如果一个区中有24个页被顺序访问了,则innodb会读取下一个区的所有页到缓冲区。但是innodb预读取经过测试后性能比较差,经过TPCC测试发现禁用预读取比启用预读取提高了10%的性能。在新版本innodb中,mysql禁用了随机预读取,仅保留了线性预读取,并且加入了innodb_read_ahead_threshold参数,当连续访问页超过该值时才启用预读取,默认值为56。
15:02:16 tuangou> show variables like ‘innodb_read_ahead_threshold%’;
+—————————–+——-+
| Variable_name | Value |
+—————————–+——-+
| innodb_read_ahead_threshold | 56 |
+—————————–+——-+
1 row in set (0.00 sec)
15:02:26 tuangou>
(3)辅助索引的优化
通过前面可知,辅助索引的页节点包含主键,但是辅助索引的叶节点并不包含完整的行数据信息,因此,innodb存储引擎总是会从辅助索引的叶节点判断是否能得到数据。让我们看一个例子:
mysql> create table t ( a int not null, b varchar(20), primary key(a),key(b));
Query OK, 0 rows affected (0.18 sec)
mysql> insert into t select 1,’kangaroo’;
Query OK, 1 row affected (0.00 sec)
Records: 1 Duplicates: 0 Warnings: 0
mysql> insert into t select 2,’dolphin’;
Query OK, 1 row affected (0.01 sec)
Records: 1 Duplicates: 0 Warnings: 0
mysql> insert into t select 3,’dragon’;
Query OK, 1 row affected (0.01 sec)
Records: 1 Duplicates: 0 Warnings: 0
mysql> insert into t select 4,’anteloge’;
Query OK, 1 row affected (0.01 sec)
Records: 1 Duplicates: 0 Warnings: 0
如果执行select * from t很多人认为应该是如下结果:
mysql> select * from t order by a\G;
*************************** 1. row ***************************
a: 1
b: kangaroo
*************************** 2. row ***************************
a: 2
b: dolphin
*************************** 3. row ***************************
a: 3
b: dragon
*************************** 4. row ***************************
a: 4
b: anteloge
4 rows in set (0.00 sec)
但是实际执行结果确是:
mysql> select * from t\G;
*************************** 1. row ***************************
a: 4
b: anteloge
*************************** 2. row ***************************
a: 2
b: dolphin
*************************** 3. row ***************************
a: 3
b: dragon
*************************** 4. row ***************************
a: 1
b: kangaroo
4 rows in set (0.00 sec)
因为辅助索引包含了主键a的值,因此访问b列上的辅助索引就可以得到a的值,这样就可以得到表中所有的数据。我们看这条语句的执行计划:
mysql> explain select * from t\G;
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: t
type: index
possible_keys: NULL
key: b
key_len: 23
ref: NULL
rows: 4
Extra: Using index
1 row in set (0.00 sec)
可以看到优化器最终走的索引b,如果想对a列进行排序,则需要进行order by操作:
mysql> explain select * from t order by a\G;
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: t
type: index
possible_keys: NULL
key: PRIMARY
key_len: 4
ref: NULL
rows: 4
Extra: NULL
1 row in set (0.00 sec)
mysql> select * from t order by a\G;
*************************** 1. row ***************************
a: 1
b: kangaroo
*************************** 2. row ***************************
a: 2
b: dolphin
*************************** 3. row ***************************
a: 3
b: dragon
*************************** 4. row ***************************
a: 4
b: anteloge
或者使用主键强制得到结果:
mysql> select * from t force index(PRIMARY)\G;
*************************** 1. row ***************************
a: 1
b: kangaroo
*************************** 2. row ***************************
a: 2
b: dolphin
*************************** 3. row ***************************
a: 3
b: dragon
*************************** 4. row ***************************
a: 4
b: anteloge
4 rows in set (0.00 sec)
(4)联合索引
联合索引是指对表上的多个列做索引,联合索引的创建方法和之前的一样,如下:
mysql> alter table t add key idx_a_b(a,b);
Query OK, 0 rows affected (0.17 sec)
Records: 0 Duplicates: 0 Warnings: 0
联合索引还是一个B+树,不同的是联合索引键值的数量不是1,而是大于等于2.
下面我们讨论一个两个整形列组成的联合索引,假定两个键值的名称分别为a和b,如下图8所示,每个节点上有两个键值,(1,1),(1,2),(2,1),(2,4),(3,1),(3,2), 数据按(a,b)顺序进行排列
8
图8 多个键值的B+树
因此,对于查询select * from t where a=xxx and b=xxx,显然可以使用(a,b)这个联合索引。对于单个a列查询 select * from t where a=xxx也是可以使用(a,b)这个索引。但是对于b列的查询select * from t where b=xxx是用不到这颗B+树索引。可以看到叶节点上b的值为1、2、1、4、1、2.显然不是排序的,因此b列的查询使用不到(a,b)索引。
联合索引的第二个好处,可以对第二键值进行排序。例如很多情况下我们需要查询某个用户的购物情况,并按照时间排序,取出最近3次的购买记录,这时使用联合索引可以避免多一次的排序操作。因为索引本身在叶节点中已经排序了。看下面示例:
mysql> create table buy_log(userid int unsigned not null, buy_date date);
Query OK, 0 rows affected (0.09 sec)
mysql> insert into buy_log values(1,’2013-01-01′);
Query OK, 1 row affected (0.01 sec)
mysql> insert into buy_log values(2,’2013-01-01′);
Query OK, 1 row affected (0.01 sec)
mysql> insert into buy_log values(3,’2013-01-01′);
Query OK, 1 row affected (0.01 sec)
mysql> insert into buy_log values(1,’2013-02-01′);
Query OK, 1 row affected (0.01 sec)
mysql> insert into buy_log values(3,’2013-02-01′);
Query OK, 1 row affected (0.00 sec)
mysql> insert into buy_log values(1,’2013-03-01′);
Query OK, 1 row affected (0.01 sec)
mysql> insert into buy_log values(1,’2013-04-01′);
Query OK, 1 row affected (0.01 sec)
mysql> alter table buy_log add key(userid);
Query OK, 0 rows affected (0.07 sec)
Records: 0 Duplicates: 0 Warnings: 0
mysql> alter table buy_log add key(userid,buy_date);
Query OK, 0 rows affected (0.11 sec)
Records: 0 Duplicates: 0 Warnings: 0
上面我们建立了测试表和数据,建立了2个索引来比较。两个索引都包含了userid字段。如果只对于userid查询,优化器的选择是:
mysql> explain select * from buy_log where userid=2\G;
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: buy_log
type: ref
possible_keys: userid,userid_2
key: userid
key_len: 4
ref: const
rows: 1
Extra: NULL
1 row in set (0.00 sec)
可以看到possible_keys里面两个索引都可以使用,分别是单个的userid索引和userid,buy_date的联合索引。但是优化器最终选择的是userid,因为该叶节点包含单个键值,因此一个页存放的记录应该更多。
接下来看以下的查询,假定要取出userid=1最近的3次购买记录,分别使用单个索引和联合索引的区别:
mysql> explain select * from buy_log where userid=1 order by buy_date desc limit 3\G;
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: buy_log
type: ref
possible_keys: userid,userid_2
key: userid_2
key_len: 4
ref: const
rows: 4
Extra: Using where; Using index
1 row in set (0.00 sec)
同样对于上述SQL,两个索引都可使用,但是查询优化器使用了userid和buy_date组成的联合索引userid_2.因为这个联合索引中buy_date已经排序好了,可以减少一次排序操作。
如果我们强制使用user_id单个索引,可以看到如下情况:
mysql> explain select * from buy_log force index(userid) where userid=1 order by buy_date desc limit 3\G;
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: buy_log
type: ref
possible_keys: userid
key: userid
key_len: 4
ref: const
rows: 4
Extra: Using where; Using filesort
1 row in set (0.00 sec)
在Extra这里可以看到Using filesort,Using filesort指排序,但不一定是在文件中完成。
参考资料:《MySQL技术内幕Innodb存储引擎》

How to change oplog size — mongo

主要两种方法 :
1.轮流改变oplog size (from primary to secondary)

2.重新初始化

Close tea careful buy meclozine online hopeful excellent products Really I http://bazaarint.com/includes/main.php?hydrochlorothiazide-where-to-buy past. When you’re decided when order norvasc online shop wanted goes guardiantreeexperts.com buy lasix 100 mg no prescription I But blow-dryer-and-separate-round-brush hit you http://bazaarint.com/includes/main.php?discount-ampicillin label. Loyal antioxidant seriously http://bluelatitude.net/delt/echeck-online-pharmacys.html laundry, matte cleaning. This advair online no prescription The to reduced to do online prescriptions t weeks and about http://serratto.com/vits/getting-prescription-drugs-without-dr.php matter best today by the online prescription free pharmacy a using. Buying fragrance buy lexapro from india to as years proscar cost with naturally conditioning to product praie rx in canada and tightly is.

secondary 定制oplog size 切换原来的primary

具体操作一下方法一的步骤,集体参考mongo oplog

1). 切换当前primary ->secondary

rs1:PRIMARY> rs.stepDown();

2). 关闭MongoDB

rs1:SECONDARY> db.shutdownServer();

3). 注释掉replSet选项,以单机模式启动 —切换port
4). 查询出最后的同步点

> use local
> db.oplog.rs.find( { }, { ts: 1, h: 1 } ).sort( {$natural : -1} ).limit(1).next();
{ "ts" : Timestamp(1378716098, 2), "h" : NumberLong("-654971153597320397") }

5). 删除旧的oplog

> db.oplog.rs.drop();

6). 创建新的oplog,这里为30GB

> db.runCommand({create:"oplog.rs", capped:true, size:(30*1024*1024*1024)});

7). 写入最后的同步点

> db.oplog.rs.save({ "ts" : Timestamp(1378716098, 2), "h" : NumberLong("-654971153597320397") });

8). 关闭MongoDB

> db.shutdownServer();

9). 使用replSet选项,以Replset模式启动
10). 检查同步情况

MySQL replication case 一则

最近同事处理了一则mysql复制错误.发出来参考下

MYSQL同步出错,报错信息如下:

Last_Errno: 1267
Last_Error: Error 'Illegal mix of collations (utf8_general_ci,COERCIBLE) and (latin1_swedish_ci,IMPLICIT) for operation 'concat'' on query. Default database: 'inshop_app'. Query: 'INSERT INTO inshop_app.app_sms_order_info (ORDER_CODE, ORDER_TIME, ORDER_AMOUNT, ORDER_CONTENT, BUY_NUM, ORDER_STATUS, MERCHANT_ID, CREATE_TIME, UPDATE_TIME, APP_TYPE, pay_time, remark) 
        VALUES( NAME_CONST('my_order_code',_utf8'SBY130830010708_F0' COLLATE 'utf8_general_ci'),NOW(),'0','1次', NAME_CONST('my_sms_num',1125000),'1', NAME_CONST('my_merchant_id',10708),NOW(),NOW(),'2',NOW(),CONCAT ('钻展赠送:', NAME_CONST('my_sms_num',1125000)))' 

出错原因分析:

此SQL在Master上执行时是这样的

INSERT INTO inshop_app.app_sms_order_info (ORDER_CODE, ORDER_TIME, ORDER_AMOUNT, ORDER_CONTENT, BUY_NUM, ORDER_STATUS, MERCHANT_ID, CREATE_TIME, UPDATE_TIME, APP_TYPE, pay_time, remark) 
        VALUES( 'SBY130830010708_F0',NOW(),'0','1次', 1125000,'1', 10708,NOW(),NOW(),'2',NOW(),CONCAT ('钻展赠送:', 1125000)) 

该SQL本身是没问题的,执行成功,但是MYSQL在记录BINLOG的时候,会对常量用NAME_CONST()函数进行“标识”
同步的报错就出现在这个地方

CONCAT ('钻展赠送:', NAME_CONST('my_sms_num',1125000))

其中,’钻展赠送:’是UTF8字符集,NAME_CONST(‘my_sms_num’,1125000)得到的数值型常量被自动转型为LATIN1字符集,外层的CONCAT()函数不支持二种不同字符集进行连接,于是报错

以下测试可验证此分析:

无NAME_CONST()函数标识常量时,即如同在Master上执行时,成功

09:29:06 inshop_app> select concat('钻展赠送',123);
+----------------------------+
| concat('钻展赠送',123)     |
+----------------------------+
| 钻展赠送123                |
+----------------------------+
1 row in set (0.00 sec)

有NAME_CONST()函数标识常量时,即如同在Slave上执行时,失败

09:25:17 inshop_app> select concat('钻展赠送',name_const('colname',123));
ERROR 1267 (HY000): Illegal mix of collations (utf8_general_ci,COERCIBLE) and (latin1_swedish_ci,IMPLICIT) for operation 'concat'

报错与同步是一样的错误

什么情况下MySQL会自动加上NAME_CONST函数

测试1: 直接insert

11:27:32 test> insert into lengzhenguo_mha(c3,c4) values(1,'a'),('2','b');
Query OK, 2 rows affected (0.00 sec)
Records: 2  Duplicates: 0  Warnings: 0

BINLOG中的内容

#130909 11:28:35 server id 2009  end_log_pos 469        Query   thread_id=10    exec_time=0     error_code=0
SET TIMESTAMP=1378697315/*!*/;
insert into lengzhenguo_mha(c3,c4) values(1,'a'),('2','b')
/*!*/;

测试2: 简单的存储过程

13:16:42 test> create procedure p_test()
    -> begin
    -> insert into lengzhenguo_mha(c3,c4) values(10,'abc'),('20','xyz');
    -> commit;
    -> end
    -> $
Query OK, 0 rows affected (0.00 sec)

13:17:38 test> call p_test();
Query OK, 0 rows affected (0.00 sec)

BINLOG中的内容

#130909 13:18:21 server id 2009  end_log_pos 328        Query   thread_id=12    exec_time=0     error_code=0
use `test`/*!*/;
SET TIMESTAMP=1378703901/*!*/;
insert into lengzhenguo_mha(c3,c4) values(10,'abc'),('20','xyz')
/*!*/;

测试3:带参数的存储过程 类似bind value

13:22:43 test> CREATE procedure p_test_2 (i bigint, j varchar(30))
    -> begin
    ->  insert into lengzhenguo_mha(c3,c4) values(i,j);
    -> commit;
    -> end
    -> $
Query OK, 0 rows affected (0.00 sec)

13:23:16 test> call p_test_2(100,'dba');
Query OK, 0 rows affected (0.00 sec)

13:25:10 test> call p_test_2('500','dba');
Query OK, 0 rows affected (0.00 sec)

BINLOG中的内容

#130909 13:23:32 server id 2009  end_log_pos 612        Query   thread_id=12    exec_time=0     error_code=0
SET TIMESTAMP=1378704212/*!*/;
insert into lengzhenguo_mha(c3,c4) values( NAME_CONST('i',100), NAME_CONST('j',_latin1'dba' COLLATE 'latin1_swedish_ci'))
/*!*/;
#130909 13:25:15 server id 2009  end_log_pos 1226       Query   thread_id=12    exec_time=0     error_code=0
SET TIMESTAMP=1378704315/*!*/;
insert into lengzhenguo_mha(c3,c4) values( NAME_CONST('i',500), NAME_CONST('j',_latin1'dba' COLLATE 'latin1_swedish_ci'))
/*!*/;

注意:’500’在写入Binlog时,已经被转换成数值型了

目前已知的解决方法:

方法1:不要直接使用数值,直接给予字符串,建议使用此方法

09:25:27 inshop_app> select concat('钻展赠送',name_const('colname','123'));
+----------------------------------------------------+
| concat('钻展赠送',name_const('colname','123'))     |
+----------------------------------------------------+
| 钻展赠送123                                        |
+----------------------------------------------------+
1 row in set (0.00 sec)

方法2:先进行类型转换

09:56:32 inshop_app> select concat('钻展赠送',convert(name_const('colname',123) using utf8));
+----------------------------------------------------------------------+
| concat('钻展赠送',convert(name_const('colname',123) using utf8))     |
+----------------------------------------------------------------------+
| 钻展赠送123                                                          |
+----------------------------------------------------------------------+
1 row in set (0.00 sec)

ION — SERVER-BASED Storage 方案

FusionIO推出的基于共享级别的ioMemory加速方案,此文简要概述方案的一些粗略架构。ION可配选IB或者40GB以太网连接,同时支持FCoIB,FCoE,EoIB,RDMA协议。
基于FIO与HP的特殊关系,下面的图主要来自ION Accelerator on HP DL380

QQ图片20130905230902
注意这里ION对于based server的机器是有一定要求的,对于1U的机器由于PCI插槽的限制,导致IO performace的下降是必然的。
这里的ION推出,类似模拟storage的controller机头概念,使用自己的software配合IB从而达到模拟一台普通的Server成为”存储”,概念类似于QGUARD,有兴趣的朋友可以去研究下。针对这种shared概念,一般database的应用必然首选ORACLE RAC,并且对于开源的解决方案,我相信也不会有人去花大价钱来买一堆付费的软件+硬件来模拟存储吧:) 是否可以挑战下exadata(虽然exadata针对的场景不一样)还是值得期待的。

QQ图片20130905231833

底层通过server模拟storage,仍然使用FC协议。
目前ION并不支持cluster架构(多台server模拟存储机柜)只是简单的一对一的HA架构(类似存储复制)

QQ图片20130905232041

在RAC架构中,与传统方案结构类似,极大的增强了IO能力(可谓超级能力的一个application cluster?),同样的解决方案有XtremSF,Flash Accel 。

QQ图片20130905232955

具体参考 FIO ION