花了6个多小时把公司的rac搭建好了,遇见了不少新问题 明儿整理记录下来
杭州的夏季
这几天杭州雾蒙蒙的,马上进入夏季了, 杭州的炎热不是厦门可以比拟的,相比起来,这里是个大蒸笼. 我的工作环境还好,至少还算不热
并发性能问题一例
朋友昨天问我在对一个生产环境进程压力测试时候,当并发达到1000时候等待时间很长,怎么弄?
这是他的环境:
双机rac
M8000,128G的内存,SGA设置为64G,PGA设置为13G
测试的插入表大约有3000多万的数据量
为教育部的一个库。
———————————————–
首先就是让他先查看告警日志,看看有什么异常提示
结果并没有发现什么异常,日志是30秒切换一次
把日志扩大到6组,每组1G
依然是这样情况
根据上面的tx 等待事件 从index下手
这里的一个主键索引引起的等待事件,
采取措施:
ALTER INDEX PK_MVS_B_STUDENT REBUILD ONLINE INITRANS 32;
ALTER INDEX MVS.STUDENT INITRANS 16;
性能改善明显,提高500%
一个SQL的优化
郁闷,只是价格count 就不扫描表了
SQL> create index idx_luda_zhutou_obna on zhutou(upper(object_name)) online;
Index created.
SQL> select /*+ INDEX(a IDX_LUDA_ZHUTOU_OBNA)*/ count(a.object_name)
2 from zhutou a
3 where upper(a.object_name) like ‘LUDA%’;
Execution Plan
———————————————————-
Plan hash value: 4142235787
—————————————————————————————————–
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
—————————————————————————————————–
| 0 | SELECT STATEMENT | | 1 | 66 | 158 (0)| 00:00:02 |
| 1 | SORT AGGREGATE | | 1 | 66 | | |
| 2 | TABLE ACCESS BY INDEX ROWID| ZHUTOU | 8 | 528 | 158 (0)| 00:00:02 |
|* 3 | INDEX RANGE SCAN | IDX_LUDA_ZHUTOU_OBNA | 464 | | 4 (0)| 00:00:01 |
—————————————————————————————————–
Predicate Information (identified by operation id):
—————————————————
3 – access(UPPER(“OBJECT_NAME”) LIKE ‘LUDA%’)
filter(UPPER(“OBJECT_NAME”) LIKE ‘LUDA%’)
Note
—–
– dynamic sampling used for this statement
Statistics
———————————————————-
28 recursive calls
0 db block gets
73 consistent gets
1 physical reads
0 redo size
527 bytes sent via SQL*Net to client
492 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
SQL> ^Cselect /*+ INDEX(a IDX_LUDA_ZHUTOU_OBNA)*/ count(upper(a.object_name))
SQL> from zhutou a
SP2-0734: unknown command beginning “from zhuto…” – rest of line ignored.
SQL> where upper(a.object_name) like ‘LUDA%’
SP2-0734: unknown command beginning “where uppe…” – rest of line ignored.
SQL>
SQL> select /*+ INDEX(a IDX_LUDA_ZHUTOU_OBNA)*/ count(upper(a.object_name))
2 from zhutou a
3 where upper(a.object_name) like ‘LUDA%’;
Execution Plan
———————————————————-
Plan hash value: 3214512578
——————————————————————————————
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
——————————————————————————————
| 0 | SELECT STATEMENT | | 1 | 66 | 4 (0)| 00:00:01 |
| 1 | SORT AGGREGATE | | 1 | 66 | | |
|* 2 | INDEX RANGE SCAN| IDX_LUDA_ZHUTOU_OBNA | 8 | 528 | 4 (0)| 00:00:01 |
——————————————————————————————
Predicate Information (identified by operation id):
—————————————————
2 – access(UPPER(“OBJECT_NAME”) LIKE ‘LUDA%’)
filter(UPPER(“OBJECT_NAME”) LIKE ‘LUDA%’)
Note
—–
– dynamic sampling used for this statement
Statistics
———————————————————-
4 recursive calls
0 db block gets
71 consistent gets
0 physical reads
0 redo size
534 bytes sent via SQL*Net to client
492 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
SQL>
Mysql 备份方式
MYSQLDUMP
在linux下的mysql在刚安装时候的默认用户都是root
导出的语句
mysql -uusername -ppassword -hlocalhost database_name > name.sql
导入的语句
mysql -uusername -ppassword -hlocalhost database_name < name.sql