Chinaunix首页 | 论坛 | 博客
  • 博客访问: 244880
  • 博文数量: 64
  • 博客积分: 1416
  • 博客等级: 上尉
  • 技术积分: 565
  • 用 户 组: 普通用户
  • 注册时间: 2010-03-18 10:54
文章分类

全部博文(64)

文章存档

2011年(4)

2010年(60)

我的朋友

分类: Oracle

2010-03-24 19:21:34

ocp原厂培训笔记(第四天) 

dual 哑表 ,
select sysdate from dual
dual 帮助构造sql语句。

performance :性能调整
proactive:前瞻性
reactive

10G和9i一个大的区别:10有ADDM,9i没有
10g库内置组建,ADDM
警告的两种类型:
设置警告:alert set alert thresholds
非设置警告:错误本身报警

前瞻性的维护:

select v$
1.parse
2.execute
3.fetch
察看视图来维护数据库。
数据库可以调用程序,
绕过应用层 API,直接访问底层。

metric:量度,自动化任务里,定时发现系统瓶颈。


Automatic Workload Repository (AWR):
Infrastructure for data gathering, analysis, andsolutions recommendations
Baseline: Data gathered of a “normal runningdatabase” for performance comparison
Metric: Rate of change in a cumulative statistic
Statistics: Data collections used for optimizing
internal operations, such as execution of a SQLstatement
Threshold: A boundary value against which metric values are compared

METRIC:量度, 如果超过这个值,将会报警。
AWR:一组表,存放统计信息,分析结果,和解决方案。
BASELINE:为metric 服务.
(for example,每秒访问次数=1000对于IBM小机很正常,但对于普通pc就很高了。
我们可以收集系统正常运行时的数据,作为基表)基表可以是 基线也可以是曲线。

Optimizer statistics are:
  Not real time
  Persistent across instance restarts
  Collected automatically


优化器统计
1.不是实时的,
2.在instance重启之后仍然有用
3.是被自动收集的

优化器主要是为CBU来分析的,其中'c'的意思就是成本,IO,CPU等等。
优化器的统计是静态的,放在数据库里。oracle调度一个语句的执行计划,
它是不会对表实际进行查询的,而是根据存在字典表里的statitcs来制定计划。

Optimizer Statistics对数据进行统计之后,会修改执行计划,选择一个更有效的执行计划。
删除优化器统计,回到默认 统计,(一个块,有100个表)

统计过时:每次对大表监控,如果变化超过10%,(相对与平常),原统计值才能被标识为stale.
restore optimizer:把老统计从另外一个统计还原回去。

Optimizer Statistics (continued)
A large table that experiences 10 percent growth (or reduction) within a 24-hour period is usually
considered too volatile for statistics collection once per day to be sufficient. For tables that
experience this level of change, Oracle recommends collecting statistics more frequently,
preferably often enough that the table never changes by more than about 10 percent between
collection periods. This requires manual statistics collection.
Statistics can be manually collected by using Enterprise Manager or through the use of the
DBMS_STATS package as shown here:
SQL> EXEC dbms_stats.gather_table_stats(‘HR’,’EMPLOYEES’);
SQL> SELECT num_rows FROM dba_tables
2 WHERE owner='HR' AND table_name = 'EMPLOYEES';
NUM_ROWS
----------
214
Note that the number of rows now correctly reflects what was in the table as of the time statistics
were gathered. DBMS_STATS also enables manual collection of statistics for an entire schema or
even the whole database.
从上面可以看到,一旦对表进行了信息收集,这个表在 dba_tables里的信息就会产生。
执行计划将依靠这个内容。

SQL> conn hr/hr
Connected.
SQL> create table emp1 as select * from employees;
     Table created.
    SQL> select num_rows from user_tables where table_name='EMP1';
     NUM_ROWS
----------
    SQL> exec dbms_stats.gather_table_stats('HR','EMP1');
    PL/SQL procedure successfully completed.
     SQL> select num_rows from user_tables where table_name='EMP1';
        NUM_ROWS
----------
       107
      SQL>
手动收集了信息之后,这些信息才可以在user_tables中可见

 

           
如上图,是监控的一个原理图:
MMON会定时从SGA中读取数据数据,把这些数据传送到AWR资料库里。
存在内存的统计信息可以通过动态性能视图来访问(v$)
AWR快照信息防在数据字典里,通过dba_性能视图访问。
dba_表,和v$都可以被外在的客户端 EM,SQL*PLUS访问。

AWR 是一个自动工作资料库:
被保存在表空间sysaux里,默认保留时间是7天(可以根据存储容量做调整)
awr收集间隔是60分钟。
关于AWR report的等级,查看下面的表:


建议在生产环境,这个参数设置为typical.(默认的)
建议在开发环境,这个参数设置为ALL。这样会产生额外开销,但是开发者可以利用这个来查看自己编写的plsql脚本的性能。
从DBconsole访问 ADDM比较合适,因为这些数据通过图形表格方式变的很直观。


会话分两种:
active session:连上来了,而且正在进行分析,提取或者调用的会话。
inactive session:连上来但是没有操作的会话。


IO 分两种:
用户IO 1>分析时间
       2>释放空间时间
       3>读取进入内存时间
       4>fetch时间

系统IO:
服务器进程做update,delet操作使用的IO,
主要由lgwr,dbwr造成。


ADDM的建议框架如下:

 

ADDM的唤醒方式,每次snap shot,都会调用 ADDM 和上一次snapshot比较。
通过DBCONSOLE调用ADDM:
HOME->diagnostic summary下可以查看 Diagnostics ADDM finding,如果没有建议,这个数值就是0;


Advisor Central:顾问中心,需要手动唤醒。
当运行,这个时候会调用一个DBMS_ADVISOR命令行包。建立相关的任务和引用参数。


服务器产生的警报:
Server-Generated Alerts
Oracle instance
正常
EM->ALL METRICES

警报的类型分为:
无阀值警报:报警了
阀值警报:超过空间的thredhold了

当发生了阀值报警的时候,产生了一个警告信息,(这个告警信息存在
AWR里视图名字是DBA_OUTSTANDING_ALERTS),如果这个报警后来消除了,
那么这个报警信息也会被删除,并放入DBA_ALERT_HISTORY这个视图上去。
如果是无阀值报警,(系统错误),则直接放入DBA_ALERT_HISTORY.


练习:207面
建立addm帐号
1. lab_12_01.sh
2. lab_12_02.sh 建立帐号
3.设置活动时间为30分钟lab_12_03.sh
4.查询哪些语句使用了大量的时间。

内存分页技术:
内存分页条件下,内存不够将使用swap空间。
磁盘IO,并发事务 8-10ms,一个scsi磁盘每秒8到10个io.

资源监控:
察看系统的问题出在哪。
1.通过sql语句
2.对象CPU。
sql语句:sqltunning顾问。

如果要部署一个应用,我们可以用下面两种方式:
1>新建一个oracle instance来提供服务,
2>新建一个oracle 用户来提供服务。
    区别是:
不能以用户方式实现监控,因为oracle是根据服务提供监控的。有服务才能有高可用性和监控。

实现自动内存管理:
SGA_MAX_SIZE:总共有多少
SGA_TARGET_SIZE :
如果把SGA_TARGET_SIZE设置为 0,则和9i一样,将变成手动管理;
如果把SGA_TARGET_SIZE设置为非空,则变成自动的内存管理。
察看实际share_pool大小。
10G第 2版默认是打开自动共享内存管理的,一版默认是手动管理的。

设置share_pool_size ,有一个下限。

对内存的管理,
LRU:最近最少使用算法
Buffer cache大小(Buffer cache 使用LRU 算法)

共享池的两种视图:
动态性能视图 v$
数据字典视图 DBA_
             ALL_
             USER_


察看instance 名字
show parameter instance;
select instance_name from v$instance;
临时表空间丢了是没关系的,临时表空间undo 处理机制不一样。

手工编译(compile)的意义:
如果对象无效,下次执行时 oracle会自动编译,为了防止 共享池的阻塞,可提前编译。

为了减小碎片,我们会对表做move操作,可以减少段碎片的出现,这种情况下我们必须重建索引。

试验:
1.lab3_13_01.sql
alter table hr.employee move;
2.lab_13_02.sql
sqlplus dba1/oracle
3.修改添加索引


在做这个操作的时候,
unix环境下不需要即可批量处理数据
windows环境下,需要给账户设置批处理登陆

模拟很高的负载现象:
lab_13_09.sql
看语句上的统计执行计划
不改变源代码情况下,建立sql概要文件(profile),改变执行路径(sql profile),花更长的时间来生成一个执行计划。
access顾问 ,索引和试图
重建sql:sql 分析优化顾问  unnion ,union all(这样优化)


limited 模式和 comprehesive 模式,会调用优化器的自动调整功能。

修改参数
show parameter cusor_sharing;
如果设置: cusror_sharing=force会强制绑定变量。


sql顾问:(sql tunning advisor) awr,
top sql:concurrency
top sessions:


395面
hard parse:
查找共享池的 库缓冲,如果不在的时候,则会发生硬分析,(在共享池给他开辟一个共享空间)
soft parse
如果语句利用了绑定变量,这个语句在内存中存在cursor,直接可以利用这个内存的cursor的老的执行计划。
这样可以节约很多内存和CPU分析时间。


OLTP应用,一定要使用bind variable。
千万个类似的查询都用老的执行计划,执行计划会大大减小。
和内存无关,如果内存越多,执行计划 中间的查找步骤会更长。
频繁分配内存都会产生大量的latch,会造成CPU长期大负荷。
可以修改参数强制使用bind variable:cusror_sharing=force
这个操作会大大减少latch 增加。
(对sga所有的操作都需要用到latch.硬分析操作都要用到latch.)

在dss决策支持系统中,不建议使用绑定变量。
分析时间建议多一点,这样可以得到最优的执行计划,优化执行计划。

建立物化视图:
利用视图可以求出查询的结果,提高报告的性能。

共享内存:
pga:
自动共享内存管理,总的内存大小
实现自内存

备份恢复的概念
故障  恢复方法,检查点
我们最终的目的是:
增加平均无故障 时间: MTBF
减少平均恢复时间:MTTR

几种错误的情况:
1.语句的失败(无预干预)
1.合法的数据  没有权限  ,或没有足够空间
2.用户进程失败 (无需干预 )用户退出
3.网络故障(无需恢复)
4.用户错误
  1>删除并提交了
  2>删除表,(放入了recycle.bin)
5.instance失败
电源问题,自动恢复,后台进程

CKPT介绍 P421面


LGWR在下面的情况下被触发:
1>COMMIT
2>one third full
3>每3秒
4>dbwr之前

6.介质失败
1>磁盘损坏
2>磁盘控制器损坏
3>文件被删除了


第四种第六种出现问题情况很大。

oracle 能被open的前提条件
所有数据的文件头必须一致,才能被打开。


FAST_START_MTTR_TARGET(默认值是0)
实例恢复时间,oracle 指定,最大实例恢复时间为1小时
如果设置恢复时间越短,对系统的影响越大,(checkpoint 会越频繁)


归档日志文件
%t%s%r.dbf
%t:日志线程号
%s;日志序列号
%r:resetlogs 号码
    注意,rac的每个实例都有自己的线程号


归档路径,最多有10个,缺省指向闪回区
log_archive_dest :标准版只能使用 这个选项,只能使用2个
log_archive_destn:企业版可以有10个归档位置。

归档路径是在spfile里面被定义,是否归档,把信息记录到控制文件。
必须以正常方式关闭数据库,才能打开倒mount状态来设置归档。

9i和10g的区别:
9i 下 log_archive_start 这个属性必须被修改为 true,归档模式才能被打开。
10g 里不要修改这个属性,若修改了,会出现警告 (有obsolete的参数)。


练习,两份归档路径的冗余:
HOME-〉维护-〉恢复设置


关于备份
oracle secure backup
     可以实现把备份指派到磁带,低成本,但具有复杂性
怎么到这个secure backup里面去,
在dbconsole里面有一个到 secure backup的链接。

用户管理的备份;
1>cp
alter tablespace "" begin backup; 把数据文件的块头锁定。
alter tablespace "" end backup;
注意,对表空间做了 begin backup定义之后,我们可以对表空间里面的数据继续进行写操作。

2>备份整个数据库
1>备份 (whole)(partial)
注意,只有在归档模式下,做partial 备份才有意义。


备份类型:
1.增量备份
whole(除了数据文件,包括控制文件,归档日志文件)
rman 下一个备份集可以包含多个文件(可以跳过没有数据的数据块)
image copies.(一个img 一个文件)

legato:EMC
如果拥有4个磁带驱动器,为了加快速度,需要设置 parallesim为4个。

对闪回区的备份,目标必须指向磁带,oracle的就是这么设计的。
Full Backup 和增量level 0的区别,Full 无法和level 1 结合起来,

RMAN〉list backup
如果没有指定level 0的备份,则制定level 1的备份,会自动变level0
除非打开自动备份控制文件,rman 才会被分参数文件。

生成一个ctl file脚本
SQL>alter database backup controlfile to trace;
这个时候会在 user_dump_dest 下生成一个7KB大小左右的 文件。


rman 与闪回恢复的概念与区别:

rman 是在块级别的对数据库的恢复。
闪回是在逻辑级别对数据库的恢复。
Full backup

看语句上的统计执行计划
不改变源代码情况下,建立sql概要文件(profile),改变执行路径(sql profile),花更长的时间来生成一个执行计划。
access顾问 ,索引和试图
重建sql:sql 分析优化顾问  unnion ,union all(这样优化)


limited 模式和 comprehesive 模式,会调用优化器的自动调整功能。

修改参数
show parameter cusor_sharing;
cusror_sharing=force会强制绑定变量。


sql顾问:(sql tunning advisor) awr,
top sql:concurrency
top sessions:


395面
hard parse:
查找共享池的 库缓冲,如果不在的时候,则会发生硬分析,(在共享池给这个语句开辟一个共享空间)
soft parse
如果语句利用了绑定变量,这个语句在内存中存在cursor,直接可以利用这个内存的cursor的老的执行计划。
这样可以节约很多内存和CPU分析时间。


OLTP应用,一定要使用bind variable。
千万个类似的查询都用老的执行计划,执行计划会大大减小。
和内存无关,如果内存越多,执行计划 中间的查找步骤会更长。
频繁分配内存都会产生大量的latch,会造成CPU长期大负荷。
可以修改参数强制使用bind variable:cusror_sharing=force
这个操作会大大减少latch 增加。
(对sga所有的操作都需要用到latch.硬分析操作都要用到latch.)

在dss决策支持系统中,不建议使用绑定变量。
分析时间建议多一点,这样可以得到最优的执行计划,优化执行计划。

建立物化视图:
利用视图可以求出查询的结果,提高报告的性能。

共享内存:
pga:
自动共享内存管理,总的内存大小
实现自内存

阅读(1560) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~