Ludatou's data life – 第79页 – Database support : +86 0571 86507110

4月21号小记

7月份就要考OCM了
最近一直有点忙，但是还是比较容易分心
老婆马上来杭州了，看着口袋那么拮据，往后的日子怎么办·这OCM真要人命，一下去了几万块。

虽然报名时候就考虑到了今年会过得很拮据，但是真的拮据来了还是有点不适应~~~
TAT

加把努力！！！

Oracle | Guang Cai Li | 2011-04-21

Rac 常用管理命令一

关于oracle rac的操作命令 — 开发人员熟悉版本

rac的备份不只是数据的备份，也要对ocr以及voting进行备份，所以rac的备份概念和传统的数据库概念并不一样

这篇文档主要讲解oracle RAC的操作文档和实际的备份以及恢复概念，

1.环境
公司的oracle RAC
铁甲人linux 5.5版本
oracle 10201 database
oracle cluster 10201

节点：

node1 ip 231
node2 ip 232

主机：
windows xp sp3 241

2.确定oracle rac服务状态的命令

主要分为4种
crsctl gsdctl onsctl srvctl

（1）crsctl —- 谨慎操作，一般情况不允许做这个操作，除非crs出问题需要重启
这个命令主要用来启动和关闭集群服务

示例：

[root@node1 ~]# crsctl stop crs
Stopping resources.
Successfully stopped CRS resources
Stopping CSSD.
Shutting down CSS daemon.
Shutdown request successfully issued.
[root@node1 ~]# crsctl start crs
Attempting to start CRS stack

测试crs，确定集群服务运行健康状态：
ORACLE@node1:/oracle/product/10.2.0/db_1/dbs>crsctl check crs
CSS appears healthy
CRS appears healthy
EVM appears healthy

（2）crs_ 系列
这系列的命令可以在CRS_HOME中找到，在公司的环境中我没有设置CRS_HOME变量，具体路径为：
/oracle/product/10.2.0/crs/bin

实例：
一：crs_stat -t的命令主要确定oracle rac的全部服务状态

ORACLE@node1:/home/oracle>crs_stat -t
Name Type Target State Host
————————————————————
ora.ldrac.db application ONLINE ONLINE node1
ora….c1.inst application ONLINE ONLINE node1
ora….c2.inst application ONLINE ONLINE node2
ora….SM1.asm application ONLINE ONLINE node1
ora….E1.lsnr application ONLINE ONLINE node1
ora.node1.gsd application ONLINE ONLINE node1
ora.node1.ons application ONLINE ONLINE node1
ora.node1.vip application ONLINE ONLINE node1
ora….SM2.asm application ONLINE ONLINE node2
ora….E2.lsnr application ONLINE ONLINE node2
ora.node2.gsd application ONLINE ONLINE node2
ora.node2.ons application ONLINE ONLINE node2
ora.node2.vip application ONLINE ONLINE node2

ORACLE@node1:/home/oracle>crs_stat -help
Usage: crs_stat [resource_name […]] [-v] [-l] [-q] [-c cluster_member]
crs_stat [resource_name […]] -t [-v] [-q] [-c cluster_member]
crs_stat -p [resource_name […]] [-q]
crs_stat [-a] application -g
crs_stat [-a] application -r [-c cluster_member]
crs_stat -f [resource_name […]] [-q] [-c cluster_member]
crs_stat -ls [resource_name […]] [-q]

示例
ORACLE@node1:/home/oracle>crs_stat -ls
Name Owner Primary PrivGrp Permission
—————————————————————–
ora.ldrac.db oracle oinstall rwxrwxr–
ora….c1.inst oracle oinstall rwxrwxr–
ora….c2.inst oracle oinstall rwxrwxr–
ora….SM1.asm oracle oinstall rwxrwxr–
ora….E1.lsnr oracle oinstall rwxrwxr–
ora.node1.gsd oracle oinstall rwxr-xr–
ora.node1.ons oracle oinstall rwxr-xr–
ora.node1.vip root oinstall rwxr-xr–
ora….SM2.asm oracle oinstall rwxrwxr–
ora….E2.lsnr oracle oinstall rwxrwxr–
ora.node2.gsd oracle oinstall rwxr-xr–
ora.node2.ons oracle oinstall rwxr-xr–
ora.node2.vip root oinstall rwxr-xr–

二： crs_start 这个命令和crsctl start crs 是一样的功能
crs_start 是用来启动集群所有服务的
，命令格式：

crs_start -all 启动全部服务
crsctl start/stop resources 启动和关闭资源服务

三 gsdctl gsd控制器 The Global Services Daemon = GSD

关闭 gsdctl stop

PS : 关闭服务可以参考一下命令
[oracle@node1 ~]$ crs_stop ora.ORCL.ORATEST.cs
Attempting to stop `ora.ORCL.ORATEST.cs` on member `node2`
Stop of `ora.ORCL.ORATEST.cs` on member `node2` succeeded.
[oracle@node1 ~]$ crs_stop ora.node1.ASM1.asm
Attempting to stop `ora.node1.ASM1.asm` on member `node1`
Stop of `ora.node1.ASM1.asm` on member `node1` succeeded.
[oracle@node1 ~]$ crs_stop ora.node1.LISTENER_node1.lsnr
Attempting to stop `ora.node1.LISTENER_node1.lsnr` on member `node1`
Stop of `ora.node1.LISTENER_node1.lsnr` on member `node1` succeeded.
[oracle@node1 ~]$ crs_stop ora.node1.ons
Attempting to stop `ora.node1.ons` on member `node1`
Stop of `ora.node1.ons` on member `node1` succeeded.
[oracle@node1 ~]$ crs_stop ora.node1.vip
Attempting to stop `ora.node1.vip` on member `node1`
Stop of `ora.node1.vip` on member `node1` succeeded.
[oracle@node1 ~]$ crs_stop ora.node2.gsd
Attempting to stop `ora.node2.gsd` on member `node2`
Stop of `ora.node2.gsd` on member `node2` succeeded.
[oracle@node1 ~]$ crs_stop ora.node2.ons
Attempting to stop `ora.node2.ons` on member `node2`
Stop of `ora.node2.ons` on member `node2` succeeded.
[oracle@node1 ~]$ crs_stop ora.node1.gsd
Attempting to stop `ora.node1.gsd` on member `node1`
Stop of `ora.node1.gsd` on member `node1` succeeded.

相反启动服务可以用 crs_start 如上只需要把stop改成start就可以了。

四： ASM的使用

在orcale用户下输入

asmcmd
就可以进入asm的介质管理平台

输入help就可以列出一系列操作解释

下一篇： srvctl 的使用 —- 这个是rac常用的管理工具

Oracle | Guang Cai Li | 2011-04-19

优化法则 CBO

RBO和CBO的基本概念

Oracle数据库中的优化器又叫查询优化器（Query Optimizer）。它是SQL分析和执行的优化工具，它负责生成、制定SQL的执行计划。Oracle的优化器有两种，基于规则的优化器（RBO）与基于代价的优化器（CBO)

RBO: Rule-Based Optimization 基于规则的优化器

CBO: Cost-Based Optimization 基于代价的优化器

RBO自ORACLE 6以来被采用，一直沿用至ORACLE 9i. ORACLE 10g开始，ORACLE已经彻底丢弃了RBO，它有着一套严格的使用规则，只要你按照它去写SQL语句，无论数据表中的内容怎样，也不会影响到你的“执行计划”，也就是说RBO对数据不“敏感”；它根据ORACLE指定的优先顺序规则，对指定的表进行执行计划的选择。比如在规则中，索引的优先级大于全表扫描;RBO是根据可用的访问路径以及访问路径等级来选择执行计划，在RBO中，SQL的写法往往会影响执行计划，它要求开发人员非常了解RBO的各项细则，菜鸟写出来的SQL脚本性能可能非常差。随着RBO的被遗弃，渐渐不为人所知。也许只有老一辈的DBA对其了解得比较深入。关于RBO的访问路径，官方文档做了详细介绍：

RBO Path 1: Single Row by Rowid

RBO Path 2: Single Row by Cluster Join

RBO Path 3: Single Row by Hash Cluster Key with Unique or Primary Key

RBO Path 4: Single Row by Unique or Primary Key

RBO Path 5: Clustered Join

RBO Path 6: Hash Cluster Key

RBO Path 7: Indexed Cluster Key

RBO Path 8: Composite Index

RBO Path 9: Single-Column Indexes

RBO Path 10: Bounded Range Search on Indexed Columns

RBO Path 11: Unbounded Range Search on Indexed Columns

RBO Path 12: Sort Merge Join

RBO Path 13: MAX or MIN of Indexed Column

RBO Path 14: ORDER BY on Indexed Column

RBO Path 15: Full Table Scan

CBO是一种比RBO更加合理、可靠的优化器，它是从ORACLE 8中开始引入，但到ORACLE 9i 中才逐渐成熟，在ORACLE 10g中完全取代RBO， CBO是计算各种可能“执行计划”的“代价”，即COST，从中选用COST最低的执行方案，作为实际运行方案。它依赖数据库对象的统计信息，统计信息的准确与否会影响CBO做出最优的选择。如果对一次执行SQL时发现涉及对象（表、索引等）没有被分析、统计过，那么ORACLE会采用一种叫做动态采样的技术，动态的收集表和索引上的一些数据信息。

关于RBO与CBO，我有个形象的比喻：大数据时代到来以前，做生意或许凭借多年累计下来的经验（RBO）就能够很好的做出决策，跟随市场变化。但是大数据时代，如果做生意还是靠以前凭经验做决策，而不是靠大数据、数据分析、数据挖掘做决策，那么就有可能做出错误的决策。这也就是越来越多的公司对BI、数据挖掘越来越重视的缘故，像电商、游戏、电信等行业都已经大规模的应用，以前在一家游戏公司数据库部门做BI分析，挖掘潜在消费用户简直无所不及。至今映像颇深。

CBO与RBO的优劣

CBO优于RBO是因为RBO是一种呆板、过时的优化器，它只认规则，对数据不敏感。毕竟规则是死的，数据是变化的，这样生成的执行计划往往是不可靠的，不是最优的，CBO由于RBO可以从很多方面体现。下面请看一个例子，此案例来自于《让Oracle跑得更快》。

SQL> create table test as select 1 id ,object_name from dba_objects;

Table created.

SQL> create index idx_test on test(id);

Index created.

SQL> update test set id=100 where rownum =1;

1 row updated.

SQL> select id, count(1) from test group by id;

        ID   COUNT(1)

---------- ----------

       100          1

         1      50314

从上面可以看出，该测试表的数据分布极其不均衡,ID=100的记录只有一条，而ID=1的记录有50314条。我们先看看RBO下两条SQL的执行计划.

SQL> select /*+ rule */ * from test where id =100;

Execution Plan

----------------------------------------------------------

Plan hash value: 2473784974

------------------------------------------------

| Id  | Operation                   | Name     |

------------------------------------------------

|   0 | SELECT STATEMENT            |          |

|   1 |  TABLE ACCESS BY INDEX ROWID| TEST     |

|*  2 |   INDEX RANGE SCAN          | IDX_TEST |

------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

   2 - access("ID"=100)

Note

-----

   - rule based optimizer used (consider using cbo)

Statistics

----------------------------------------------------------

          1  recursive calls

          0  db block gets

          3  consistent gets

          0  physical reads

          0  redo size

        588  bytes sent via SQL*Net to client

        469  bytes received via SQL*Net from client

          2  SQL*Net roundtrips to/from client

          0  sorts (memory)

          0  sorts (disk)

          1  rows processed

SQL>

SQL> select /*+ rule */ * from test where id=1;

50314 rows selected.

Execution Plan

----------------------------------------------------------

Plan hash value: 2473784974

------------------------------------------------

| Id  | Operation                   | Name     |

------------------------------------------------

|   0 | SELECT STATEMENT            |          |

|   1 |  TABLE ACCESS BY INDEX ROWID| TEST     |

|*  2 |   INDEX RANGE SCAN          | IDX_TEST |

------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

   2 - access("ID"=1)

Note

-----

   - rule based optimizer used (consider using cbo)

Statistics

----------------------------------------------------------

          1  recursive calls

          0  db block gets

       7012  consistent gets

         97  physical reads

          0  redo size

    2243353  bytes sent via SQL*Net to client

      37363  bytes received via SQL*Net from client

       3356  SQL*Net roundtrips to/from client

          0  sorts (memory)

          0  sorts (disk)

      50314  rows processed

从执行计划可以看出，RBO的执行计划让人有点失望，对于ID=1，几乎所有的数据全部符合谓词条件，走索引只能增加额外的开销（因为ORACLE首先要访问索引数据块，在索引上找到了对应的键值，然后按照键值上的ROWID再去访问表中相应数据），既然我们几乎要访问所有表中的数据，那么全表扫描自然是最优的选择。而RBO选择了错误的执行计划。可以对比一下CBO下SQL的执行计划，显然它对数据敏感，执行计划及时的根据数据量做了调整,当查询条件为1时，它走全表扫描；当查询条件为100时，它走区间索引扫描。如下所示：

SQL> select * from test where id=1;

50314 rows selected.

Execution Plan

----------------------------------------------------------

Plan hash value: 1357081020

--------------------------------------------------------------------------

| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |

--------------------------------------------------------------------------

|   0 | SELECT STATEMENT  |      | 49075 |  3786K|    52   (2)| 00:00:01 |

|*  1 |  TABLE ACCESS FULL| TEST | 49075 |  3786K|    52   (2)| 00:00:01 |

--------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

   1 - filter("ID"=1)

Note

-----

   - dynamic sampling used for this statement

Statistics

----------------------------------------------------------

         32  recursive calls

          0  db block gets

       3644  consistent gets

          0  physical reads

          0  redo size

    1689175  bytes sent via SQL*Net to client

      37363  bytes received via SQL*Net from client

       3356  SQL*Net roundtrips to/from client

          0  sorts (memory)

          0  sorts (disk)

      50314  rows processed

SQL> select * from test where id =100;

Execution Plan

----------------------------------------------------------

Plan hash value: 2473784974

----------------------------------------------------------------------------------------

| Id  | Operation                   | Name     | Rows  | Bytes | Cost (%CPU)| Time     |

----------------------------------------------------------------------------------------

|   0 | SELECT STATEMENT            |          |     1 |    79 |     2   (0)| 00:00:01 |

|   1 |  TABLE ACCESS BY INDEX ROWID| TEST     |     1 |    79 |     2   (0)| 00:00:01 |

|*  2 |   INDEX RANGE SCAN          | IDX_TEST |     1 |       |     1   (0)| 00:00:01 |

----------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

   2 - access("ID"=100)

Note

-----

   - dynamic sampling used for this statement

Statistics

----------------------------------------------------------

          9  recursive calls

          0  db block gets

         73  consistent gets

          0  physical reads

          0  redo size

        588  bytes sent via SQL*Net to client

        469  bytes received via SQL*Net from client

          2  SQL*Net roundtrips to/from client

          0  sorts (memory)

          0  sorts (disk)

          1  rows processed

SQL>

仅此一项就可以看出为什么ORACLE极力推荐使用CBO，从ORACLE 10g开始不支持RBO的缘故。所谓长江后浪推前浪，前浪死在沙滩上。

CBO知识点的总结

CBO优化器根据SQL语句生成一组可能被使用的执行计划，估算出每个执行计划的代价，并调用计划生成器（Plan Generator）生成执行计划，比较执行计划的代价，最终选择选择一个代价最小的执行计划。查询优化器由查询转换器（Query Transform）、代价估算器（Estimator）和计划生成器（Plan Generator）组成。

CBO优化器组件

CBO由以下组件构成：

· 查询转化器（Query Transformer）

查询转换器的作用就是等价改变查询语句的形式，以便产生更好的执行计划。它决定是否重写用户的查询（包括视图合并、谓词推进、非嵌套子查询/子查询反嵌套、物化视图重写），以生成更好的查询计划。

The input to the query transformer is a parsed query, which is represented by a set of

query blocks. The query blocks are nested or interrelated to each other. The form of the

query determines how the query blocks are interrelated to each other. The main

objective of the query transformer is to determine if it is advantageous to change the

form of the query so that it enables generation of a better query plan. Several different

query transformation techniques are employed by the query transformer, including:

■ View Merging

■ Predicate Pushing

■ Subquery Unnesting

■ Query Rewrite with Materialized Views

Any combination of these transformations can be applied to a given query.

· 代价评估器（Estimator）

评估器通过复杂的算法结合来统计信息的三个值来评估各个执行计划的总体成本：选择性（Selectivity）、基数（Cardinality）、成本（Cost）

计划生成器会考虑可能的访问路径（Access Path）、关联方法和关联顺序，生成不同的执行计划，让查询优化器从这些计划中选择出执行代价最小的一个计划。

Oracle | Guang Cai Li | 2011-04-18

4月16日小记

其实不止一次的考虑过，2年或者3年，5年，甚至10年后，我还是DBA么？

DBA的发展方向是什么？
在未来的几年中，这个职业的趋势是什么？
那我又该何去何从？

继续我的DBA生涯，那我该在oracle的基础上，添加mysql？nosql？
还是在作为一个运维DBA的同时，也兼任着开发DBA的角色？把监控做好，C？还是php？或者要从新学过java？

eh？分布式数据存储？……

迷茫

Oracle | Guang Cai Li | 2011-04-16

Linux：误删除/etc/inittab的解决办法

由于删除oracle cluster sofeware时候误删除了inittab文件

在系统重启时候报错，提示找不到启动模式，找不到inittab

———————————————————–

这时候可以进去rescue模式补救

我这里的经过是这样的：

插入安装光盘，修改cdrom为第一启动模式，

进入到安装界面，输入 linux recsue

在配置网卡那段可以跳过，直接进去到补救模式的系统

这时候挂在原有系统

chroot /mnt/sysimage

挂载完之后

启动网络服务和telnet服务

service network start

service xinetd start

然后 telnet进来

vi /etc/inittab
把别的机子上的inittab复制过来，保存

重启，机子

Linux Oracle恢复 Unix and Linux | Guang Cai Li | 2011-04-15 | linux

4月21号小记

Rac 常用管理命令一

优化法则 CBO

4月16日小记

Linux：误删除/etc/inittab的解决办法

Oracle 恢复工具 Mdata 5.0.1 版本发布

近期文章

分类目录

扫码关注微信公众号:Oracle运维那些事获取定期发布的数据库运维的有趣事情!

近期活动

Oracle 恢复工具 Mdata 5.0.1 版本发布

近期文章

分类目录

扫码关注微信公众号:Oracle运维那些事 获取定期发布的数据库运维的有趣事情!

近期活动

扫码关注微信公众号:Oracle运维那些事获取定期发布的数据库运维的有趣事情!