Oracle性能管理的几个理解：
1、通过升级CPU，但不升级磁盘可能导致系统需要更多的处理I/O竞争，可能无法提升性能
2、优化的各个环节：解析SQL/缓冲SQL/写磁盘/CPU/扫描物理磁盘/从物理磁盘读结果集/网络传输
3、高速缓存命中率(buffer cache hit ratio) = 1 - physical reads/(consistent gets + db block gets)
4、很多时候数据库性能和高速缓存命中率无关，因为系统瓶颈可能出现在某一个步骤
Oracle性能管理的几个Trace文件：
1、alert文件，位于BACKGROUND_DUMP_DEST
2、bdump文件、位于BACKGROUND_DUMP_DEST
3、udump文件，位于USER_DUMP_DEST，文件最大大小MAX_DUMP_FILE_SIZE。通过SQL_TRACE来控制，或：
SQL> EXECUTE dbms_system.set_sql_trace_in_session(8,12,TRUE);
SQL> alter session set sql_trace=true;
Oracle性能管理的相关视图：
1、系统所有的统计信息：V$SYSSTAT
2、使用ANALYZE命令可以更新DBA_TABLES...这些表中的统计信息
3、V$视图的底下实际上是X$表
4、查看和会话相关的性能：v$statname, v$session , v$sesstat, V$SESSION_WAIT
通过UTLBSTAT和UTLESTAT来监控一段时期内的性能统计:
1、安装需要运行两个脚本，运行时会建立表储存信息；
2、统计信息包括(相关参数：告警阈值、发生事件所在的段)：
Library Cache：SQL和PL/SQL语句
System Statistics：检查点、buffer、consistent gets、db blocks gets、consistent gets，据此可以计算高速缓存命中率
Wait Event statistics：V$SYSTEM_EVENT、V$SESSION_EVENT、V$SESSION_WAIT
Latch statistics：Redo log allocation、redo log copy、LRU Latch
Rollback Segment Contention：回滚段slot争用
Buffer Busy Wait Statistics
Dictionary Cache Statistics
I/O Statistics per Data File/Tablespace
Fault management event tests:
Database Alert (database)：alert文件中是否有新的告警
Database UpDown (database)：数据库启动、关闭
Archiver Hung (database)：归档日志进程挂起
Database Probe (database)
Data Block Corruption (database)：数据库块被破坏
Node UpDown (node)
Session Terminated (database)
Space management events:
Alert File Large (database)：告警文件过大
Chunk Small (database)：空间过小
Disk Full (node)：磁盘满
Dump Full (database)：UDUMP和BDUMP空间满
Fast Segment Growth (database)：段增长过快
Maximum Extents (database)：段达到最大extents无法继续分配
Tablespace Full (database)：表空间满
Resource management events:
Datafile Limit (database)：数据文件数量增长，趋近上限
Lock Limit (database)：DDL/DML是否使用了过多的锁，趋近上限
Process Limit (database)：进程数量是否过多趋近上限
User Limit (database)：用户连接数量是否过多趋近上限
Session Limit (database)：会话数量是否过多趋近上限
Performance management events:
Buffer Cache (database)：高速缓存命中率
Chain Row (database)：发生row chain
CPU Utilization (node)
Disk I/O (node)
In Memory Sorts (database)：内存排序和外部排序
Library Cache (database)
Rollback Contention (database)
如何调优LibraryCache：
1、尽量使用通用的SQL语句、拼接字符串的方法来组织SQL语句。
2、经常使用的大的存储过程（包括触发器、函数等）应该被固定在共享池中：
SQL> EXECUTE dbms_shared_pool.keep(‘package_name’);
3、尽量避免使用大的匿名存储过程块，可以显式的将其固定在共享池中，或分成多个小块。
4、查询V$SGASTAT可以查看共享池的各个cache的大小：
SQL> select * from v$sgastat;
POOL NAME BYTES
----------- -------------------------- ---------
shared pool free memory 6447072
shared pool dictionary cache 160932
shared pool library cache 463100
shared pool sql area 1220580
shared pool sessions 242880
5、相关视图：V$LIBRARYCACHE、V$SQLAREA、V$SQLTEXT、V$DB_OBJECT_CACHE
6、V$ROWCACHE视图用于查看共享池中的字典缓存
7、和Data Buffer Cache类似，Library Cache和Dictionary Cache的有效性都是通过命中率来衡量的。
8、MTS模式下，Share Pool中还有UGA，用于保存多线程会话连接信息。
Large Pool：
用于备份和恢复等操作（LARGE_POOL_SIZE）
Data Buffer Cache：
1、Data Buffer Cache的大小 = DB_BLOCK_BUFFERS * DB_BLOCK_SIZE
2、通过配置多个数据缓存区，每个区拥有不同的策略（keep、recycle、default），然后将数据库对象（表、索引……）绑定到对应的缓冲区，可以提升性能。
重做日志缓冲区：
1、大小：LOG_BUFFER。如果一个机器的I/O比较慢，数据库写入活动频繁，可能需要比较大的日志缓冲区。
2、判断重做日志缓冲区是否足够的办法是：缓冲写入磁盘的重试率不应该大于1%。
NOLOGGING选项：
1、进行批量数据更新时，可以考虑使用NOLOGGING这个选项。
2、使用SQL Loader的Direct Path模式，在以下两种情况不产生重做日志：
a. 归档模式处于NOARCHIVELOG；
b. 归档模式处于ARCHIVELOG，但相关的对象已经设置了NOLOGGING属性。
3、设置了NOLOGGING属性后，Direct Insert基本不产生重做日志。NOLOGGING属性可以被设置在表、表空间、索引上面。只有以下的SQL语句才能使用NOLOGGING模式：CREATE TABLE AS SELECT; CREATE INDEX; ALTER INDEX ... REBUILD; INSERT INTO ... SELECT FROM ...
表空间管理：
一个数据库中应该为不同的对象和用途建立不同的表空间：SYSTEM、表、索引、回滚段、临时表空间、……
TableScan：
监控数据库的表扫描活动，关注table scans (long tables)：
SQL> SELECT name, value FROM v$sysstat
2 WHERE name LIKE ’%table scans%’;
NAME VALUE
--------------------------------------------------------- -----
table scans (short tables) 125
table scans (long tables) 30
table scans (rowid ranges) 0
table scans (cache partitions) 0
table scans (direct read) 0
table scan rows gotten 21224
table scan blocks gotten 804
7 rows selected.
NOSORT选项提高创建索引效率
如果数据已经排好序了，可以使用NOSORT选项来提高创建或重建索引的效率：
SQL> create index S_EMP_DEPT_ID_FK on s_emp(dept_id) NOSORT;
控制磁盘排序的比例在5%以下。
查看SQL语句执行计划：
1、查看SQL执行计划：
explain plan [into my_plan_table]
for
select ...
2、执行优化器有基于规则的优化器和基于代价的优化器
优化模式：OPTIMIZER_MODE = CHOOSE|RULE|FIRST_ROW|ALL_ROWS
CHOOSE：如果至少一个表有统计数据，使用基于代价的ALL_ROWS，否则使用RULE
RULE: 基于规则
FIRST_ROW：基于代价，选择最快响应时间的计划
ALL_ROWS：基于代价，选择完全执行完毕时间最短的计划
查看SQL语句执行过程和统计：
1、设置SQL_TRACE=TRUE, TIMED_STATISTICS=TRUE，查看SQL语句执行的详细信息：
2、或在实例层次设置：SQL_TRACE=TRUE，在会话层次：alter session set sql_trace=true;
execute DBMS_SESSION.SET_SQL_TRACE(true|false);
SQL> execute DBMS_SYSTEM.SET_SQL_TRACE_IN_SESSION(session_id, serial_id, {true|false});
3、trace的输出在user_dump_dest中。
4、TKPROF可以格式化查看SQL_TRACE的输出。
查看对象的统计信息：
1、更新对象的统计信息：
ANALYZE {INDEX|TABLE|CLUSTER} object_name
{COMPUTE|DELETE|ESTIMATE} STATISTICS
[FOR ... [SIZE n]] [SAMPLE n {ROWS|PERCENT}]
2、表的统计信息包括：
Number of rows
Number of blocks and empty blocks
Average available free space
Number of chained or migrated rows
Average row length
Last ANALYZE date and sample size
3、索引的统计信息：
Index level (heigt)
Number of leaf blocks and distinct keys
Average number of leaf blocks per key
Average number of data blocks per key
Number of index entries
Clustering factor
4、列的统计信息：
Number of distinct values
Lowest value, highest value
Last ANALYZE date and sample size
5、历史图表Histograms：
Describe the data distribution of a particular column in more detail
Better predicate selectivity estimates for unevenly distributed data
Create histograms with ANALYZE TABLE ... FOR COLUMNS ...
Data dictionary view: DBA_HISTOGRAMS
创建基于索引的表(IOT):
SQL> create table sales
2 (office_cd number(3)
3 ,qtr_end date
4 ,revenue number(10,2)
5 ,review varchar2(1000)
6 ,constraint sales_pk
7 PRIMARY KEY (office_cd,qtr_end)
8 )
9 ORGANIZATION INDEX tablespace indx
10 PCTTHRESHOLD 20
11 INCLUDING revenue
12 OVERFLOW TABLESPACE user_data;
创建物化视图：
SQL> create MATERIALIZED VIEW sales_summary
2 tablespace sales_ts
3 parallel (degree 4)
4 BUILD IMMEDIATE ““refresh”” FAST
5 ENABLE QUERY REWRITE
6 AS
7 select s.zip, p.product_type
8 , sum(s.amount)
9 from sales s, product p
10 where s.product_id = p.product_id
11 group by s.zip, p.product_type;
扫一扫
2125
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
