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

o_哈哈o

　　OCP ORACLE 10G 管理二，电子工业出版社。
关于快闪version查询以及快闪transaction 查询
基本概念
Flashback Time Navigation
The Flashback technology offers the capability to query past versions of schema objects,
query historical data, and perform change analysis. Every transaction logically generates a
new version of the database. With the Flashback technology, you can navigate through
these versions to find an error and its cause:
· Flashback Query: Query all data as it existed at a specific point in time.
· Flashback Versions Query: See all versions of rows between two times and the
transactions that changed the row.
· Flashback Transaction Query: See all changes made by a transaction.
　　快闪版本查询的总括:
Flashback Versions Query: Overview
With the Flashback Query feature, you can perform queries on the database as of a certain
time span or range of user-specified system change numbers (SCNs). The Flashback
Versions Query feature enables you to use the VERSIONS clause to retrieve all the
versions of the rows that exist between two points in time or two SCNs.
The rows returned by Flashback Versions Query represent a history of changes for the
rows across transactions. Flashback Versions Query retrieves only committed occurrences
of the rows. Uncommitted row versions within a transaction are not shown. The rows
returned also include deleted and subsequently reinserted versions of the rows.
You can use Flashback Versions Query to retrieve row history. It provides you with a way
to audit the rows of a table and retrieve information about the transactions that affected the
rows. You can then use the returned transaction identifier either to perform transaction
mining by using LogMiner or to perform a Flashback Transaction Query, which is covered
later in this lesson.
Note: In the example, VERSIONS_XID is a pseudocolumn that returns the transaction
identifier of the corresponding version of a row.
　　快闪查询，（使用em)
Flashback Versions Query Through Enterprise Manager
Flashback Versions Query can also be performed through Enterprise Manager. On the
Maintenance page, select Perform Recovery.
On the Perform Recovery page, select Tables for the Object Type and select Flashback
Existing Tables for the Operation Type. Click Perform Object Level Recovery. On the
“Perform Object Level Recovery: Point-in-Time” page, select “Evaluate row changes and
transactions to decide on a point in time,” and specify the name of the target table.
Select the columns that you want to view in the Available Columns box, and then enter a
search clause in the Bind The Row Value box. Select “Show all row history,” and then
click Next.
　　
　　DB_BLOCK_CHECKING controls whether or not Oracle performs block checking for database blocks. The checking that is performed depends on the value you supply, as follows:
　　OFF - no block checking is performed for blocks in the user tablespaces. However, semantic block checking for SYSTEM tablespace blocks is always turned on.
　　LOW - basic block header checks are performed after block contents change in memory (for example, after UPDATE or INSERT statements, on-disk reads, or inter-instance block transfers in RAC)
　　MEDIUM - all LOW checks are performed, as well as semantic block checking for all non-index-organized table blocks
　　FULL - all LOW and MEDIUM checks are performed, as well as semantic checks for index blocks (that is, blocks of subordinate objects that can actually be dropped and reconstructed when faced with corruption)
　　
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
　　如何探索数据库中的坏块
坏块的原因
1>硬件引起，磁盘坏道
2>软件引起错误
　　ANALYZE，DBVERIFY，DB_BLOCK_CHECKING,DBMS_REPAIR
　　1.块版本，地址、校验和
2.show parameter check
db_block_checking:带来 1%-10%的开销，对数据进行逻辑上的校验
db_block_checksum:带来1%-3%的开销，开启之后，用来验证数据物理上是否一致。
　　db_block_checking 几个参数，如果是none，则只检查完整性。
db_block_checking　可以在session级别被设置为真。
db_block_checkingsum :将把内存中的内容放入数据块中，把数据总合的块数
记录到header,下次如果再把同样的数据再加载进来，如果读近来的block数量和header记录的不一致，则表示数据块有问题了。
　　详细参数可以参照 reference
index->books->reference(文档)
　　块错误，会导致 ora-01578的错误，并报道(file#%s,block# %s)
,并报道给 alert.log。
exp 如果遇到块损坏，将报告错误，错误号是 01578
　　解决块损坏的方法:
1.检查日志
2.用dbv
3.再检查
4.用rman restore来解决
　　dbverify:只能校验数据文件不能校验控制文件和redo文件，归档日志文件
analyze:察看定义上的错误，进行逻辑上校验
exp：物理层的校验
　　flash back：查询，可以修复数据库的逻辑错误
dbms_repair:修复逻辑上的错误，贴上补丁 ，把损坏数据跳过去
（原理：把对应的index dump出来，重建，彻底跳过错误)
[具体的过程
逻辑上错误，admin建立一个repair table,用来存放检查出来的错误　，
admin 创建一个表，查找ORPHAN_KEY_TABLE,FIX CORRUPTION BLOCK
扫描阶段，忽略损坏的块。越过标记，把损坏日志条KEY DUMP出来，再调用
skip　访问时越过。rebuild
]
　　block media recovery:块级别的还原
dbverify 可以在数据库open状态检查数据文件 。
　　dbv数据检查的 参数
start_ end_参数 ：从哪个块开始，到那个块结束
为什么要有上面这两个参数：比如校验bigfile的时候，只能分段来做。
　　blocksize:必须校验时指定块大小，
10g情况下摸认识 8K，老版本是2k
　　page: 一个page就是一个block
flux:不匹配就会加一，记录一共有多少块不匹配。
　　analyze:校验逻辑错误
analyze table table_name validate
structure cascade;
　　cd $ORACLE_HOME/rdbms/admin/
运行 utilvalid.sql
这个脚本运行之后将建立一个表，invalid rows，
analyze将把结果存储到这个表。
　　
BLOCK MEDIA RECOVERY
块级别恢复　　　１.可以设置数据文件为online状态
　　　　　　　　２.恢复的时候是块无法被访问
　　
rman>block recover(必须是完全还原）
RMAN>blockrecover datafile 6 block 33,47 datafile 7 block 5,98,99;
注意对块的还原，必须始终都是完全还原。
　　
　　RMAN>blockrecover corruption list
            restore until time 'sysdate-10';
　　
The following example recovers two blocks and forces the blocks to be restored by using
backups that were made before SCN 100:
BLOCKRECOVER DATAFILE 9 BLOCK 13 DATAFILE 2 BLOCK 19 RESTORE
UNTIL SCN 100;
还原这个scn之前的备份集合。
· The following example recovers two blocks and forces the blocks to be restored by using
backups that were made before log sequence 7024:
BLOCKRECOVER DATAFILE 9 BLOCK 13 DATAFILE 2 BLOCK 19 RESTORE
UNTIL SEQUENCE 7024;
还原 数据块利用 sequece 7024之前的备份。
　　v$backup_corruption
Dynamic views show the current state of corruption.
· The V$DATABASE_BLOCK_CORRUPTION view shows
the list of currently corrupted database blocks.
RMAN> BLOCKRECOVER CORRUPTION LIST
2> RESTORE UNTIL TIME 'sysdate – 10';
　　· The V$BACKUP_CORRUPTION view shows the list of
corrupted blocks in data file backups.
· The V$COPY_CORRUPTION view shows the list of
corrupted blocks in image file copies.
　　下面的语法用来检查哪个block含有坏块
　　The V$BACKUP_CORRUPTION view shows the list of
corrupted blocks in data file backups.
The V$COPY_CORRUPTION view shows the list of
corrupted blocks in image file copies.
　　Alternative Actions to Take
If you do not plan to restore data files and recover, use the following statement to determine
which object has corrupted blocks.
The absolute file number (for example, 5) and block number (for example, 2) can be found in the
error message; for example:
ORA-01578: ORACLE data block corrupted (file #5, block # 2)
Run the following command:
SQL> SELECT segment_name, segment_type, relative_fno
2 FROM dba_extents
3 WHERE file_id = 5
4 AND 2 BETWEEN block_id AND block_id + blocks - 1;
SEGMENT_NAME SEGMENT_TYPE RELATIVE_FNO
-------------- --------------- ------------
EXAMPLE TABLE PARTITION 5
After you determine which object is corrupted, there are other options available to you for
recovering from it. For a table, you can use an export dump file. You can also use SQL to
generate a good table from the corrupted one. This may require knowledge of the business data.
If you have a corrupted index, it may be most efficient to simply drop and re-create the index.
　　
ASSM：自动内存管理（oracle 10g 新特性)
share pool:如果不足，解析sql，会造成4031错误，
keep buffer:内存区，不是内存管理的内存区，避免
经常被访问的小表被淘汰，在内存中开辟块，叫做 keep buffer.
recycle buffer:避免被淘汰，缓冲不经常使用的大表
nk_block_size:创建非标准块的前提(必须建立非标准块缓冲区）
船舰非标准块缓冲区，才能建立非标准块表。
　　手工调整：
create index cust_idx storage(BUFFER_POOL KEEP..);
设置系统的内存大小
alter system set db_keep_ cache_size=10m;
结果变成了 12m
因为规定，keep_cache_size大小必须是 granule size的整数倍。
　　怎么察看granule size：
select * from v$sgainfo;
　　fixed  SGA+REdo buffer=2 granual
　　察看表存储的位置:
select table_name ,buffer_pool from user_tables;
　　|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
SQL> select table_name,buffer_pool,tablespace_name from user_tables;
　　TABLE_NAME                     BUFFER_ TABLESPACE_NAME
------------------------------ ------- ------------------------------
PLSQL_PROFILER_RUNS            DEFAULT USERS
PLSQL_PROFILER_UNITS           DEFAULT USERS
PLSQL_PROFILER_DATA            DEFAULT USERS
CC                             DEFAULT USERS
BOOK_COPIES                    DEFAULT USERS
BOOKS                          DEFAULT USERS
CCLOCK                         DEFAULT USERS
　　7 rows selected.
　　SQL>
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
shared pool:
作用是缓冲sql,执行计划（缓冲到 library cache)
　　关于rba,检查点， checkpoint queue怎么回事，可以查看oracle 的培训
perfomace tuning的文档。
　　数据启动的时候会初始化 10%的内存。
　　io 读写效率和内存读写效率的io 比:
10000:1 （提高内存 的换取io，作为调优的代价）

　　
　　如上图，为sga里的一段内容，内存颗粒大小由db_block_size决定，
内存中存在两条表，一条表记录了被访问数据的前映像，以及被访问的次数(touch counts)，如果
touch counts增加，就会向左移动。（按被访问的频率来排序)
checkpoint queue里记录了内存中被修改过的数据,checkpoint queue里面的数据都是 dirty block.
commit之后，checkpoint queue里面的数据才能被清空。
　　
PGA里的 有一块cursor：专门用来针对软软解析。（pga中cursor 直接和 share pool中 sga的cursor进行关联)
　　
一个事务消耗时间最多的是在它的parse阶段，
在一个事务中，如果有4个表需要解析，则会解析4的阶层次。
n 张表，解析n!次。
4*3*2(解析次数)
　　
dedicated 模式下，UGA 将放置在pga中，
shared 模式下，uga 放在 share pool下，如果设置了 large pool ,uga 将放置large pool里面，不配置就放 share pool.
　　
eagle 的书分析share-pool不错。
分析内存有三篇文章:large pool必须在外部指定 。
手工管理内存的方式:
　　log buffer是静态参数，可以设置比较大，减小 lgwr写太频繁的问题，曾经有用户设置到 500m；
　　谁去 构建redo log buffer 条? server process.
　　
ASSM : oracle 自动内存管理（内存搬移)
　　ASSM管理的几大组建:
DB_CACHE_SIZE
SHARED_POOL_SIZE
LARGE_POOL_SIZE
JAVA_POOL_SIZE
STREAM_POOL_SIZE
　　
SGA_MAX_SIZE:sga 中所有组件加起来不能超过 sga_max_size
sga_target:规定了内存能够调整的范围
　　比如 手工管理的几个池
share-pool 100m
data-buffer 200m
keep buffer 100m
log buffer 7m
fix buffer  1m
largepool 100m
java 100
那么oracle 内存可以自动管理的范围是
800-100-7-1=692
　　
　　database buffer 100m 往下调，不能比它小
　　
设置 SGA_TARGET=0 则变成手工管理，仅禁用了 oracle的 ASSM
　　MMON 收集统计->memory advisor 根据它收集的进行建议->
建议执行计划，内存调整。( 建议 内存调整的方案， MMAN 从内存中得到建议）
　　数据库启动的时候会利用down机时候的参数。
EM->administrator->memeory->sga
（手工管理才有 advice)
　　statistics_level=typical
basic:收集时候使用最少的统计信息，不能为自调整组建使用
typical:这样才能被自调整信息所用
all:除了typical之外，还包含了一些诊断信息
　　
调整 sga的方法
v$sgastat
v$sga_dynamic_components
察看使用
　　db_cache_size=0
最小调整到 0，而不是说设置为0，而是说它的最小值是0
把值减小滞后，不意味着会被立即减小，而会等待一段时间才能减小。
　　SGA TARGET:只能影响 5个自动调整的内存大小。
　　for example:
　　shared_pool_size=100m 表示往下调整，share_pool_size不能小于的值，
可以查看视图 _ _ shared_pool_size=1G ，表示内存的直接大小，
在ASSM 管理条件下，这个数值会不断地调整变化的。
　　手工resize:所有值更改后不能改成，share pool size值。
　　
PGA：

　　
PGA：
session memory:主要存储 会话的内存
　　
work area:排序工作区
　　
　　PGA设置为非零值，
当把PGA_AGRGREGATE_TARGET 初始化参数设置为0，
那么PGA 的自动管理被禁用了。
　　PGA_WORKARE_SIZE:
For backward compatibility, automatic PGA memory management can be disabled by setting the
value of the PGA_AGGREGATE_TARGET initialization parameter to 0. When automatic PGA
memory management is disabled, the maximum size of a work area can be sized with the
associated *_AREA_SIZE parameter, for example:
SORT_AREA_SIZE
HASH_AREA_SIZE
BITMAP_MERGE_AREA_SIZE
CREATE_BITMAP_AREA_SIZE
才能把 workarea_size_policy 设置为auto.
　　
共享模式下：
　　后台定制可以共享方式给更多人服务，session如果没活动，还可被别人共享。
但是如果是dedicated方式，则无法共享。
　　PGA自动管理
show parameter area_size
show parameter  pga
　　PGA可以设置 16个G，初始化不会放那么多，
　　v$sql_workarea_histogram
把4个T，放入33个组，统计

　　
从上面可以看出，如果PGA AGGREGATE  设置为 200M之后，cache hit可以提高到 100%。
命中率不是调优的关键，调优的关键是等待时间，累计等待时间。
　　
bind 变量 有时候也有估计的错误:
如果前一个搜索是 select * from tabs where **=**;
执行计划推荐做索引扫描，
但是如果 强制bind 变量之后，
如果再搜索 某个范围内的 数据，(>10%)
其实这个时候做全表扫描更好，
但是因为强制bind 变量了，还是会用 前面的索引扫描的执行计划。
　　
　　尽量使用pl/sql,function(package)
cache sequence number 提高取数的速度
sequence gab:
缓冲10个数，用了三个，还剩7个，如果down掉了，
sequence 再起来又要从 1-10排列。
pin 对象减小
pin objects in the library cache.
销定。
pin 连接。
自动共享内存管理的特点:
　　sql access advisor ,tunning advisor 在10g 版本里区别不大
在11G里，tunning advisor 放入基表，和基表进行比较， 而 access advisor
针对partion advisor ，用处更多。
　　tunning activities
　　Instance Tuning
At the start of any tuning activity, it is necessary to have specific goals. A goal such as “Process
500 sales transactions per minute” is easier to work toward than one that says “Make it go as fast
as you can, and we’ll know when it’s good enough.”
You must allocate Oracle database memory suitably for your application to attain optimum
performance. You have a finite amount of memory to work with. Too little memory allotted to
certain parts of the Oracle database can cause inefficient background activity, which you may
not even be aware of without doing some analysis.
Disk I/O is often the bottleneck of a database and, therefore, requires a lot of attention at the
outset of any database implementation.
The operating system configuration can also affect the performance of an Oracle database. For
more information, see the Oracle Database Installation Guide for your particular platform.
　　
　　Performance Tuning Methodology
Oracle has developed a tuning methodology based on years of experience. The basic steps are:
· Check the OS statistics and general machine health before tuning the instance to be sure
that the problem is in the database.
· Tune from the top down. Start with the design, then the application, and then the instance.
For example, try to eliminate the full tables scans causing the I/O contention before tuning
the tablespace layout on disk.
· Tune the area with the greatest potential benefit. The tuning methodology presented in this
course is simple. Identify the biggest bottleneck and tune it. Repeat this step. All the
various tuning tools have some way to identify the SQL statements, resource contention, or
services that are taking the most time. The Oracle database provides a time model and
metrics to automate the process of identifying bottlenecks.
· Stop tuning when you meet your goal. This step implies that you set tuning goals.
This is a general approach to tuning the database instance and may require multiple passes.
　　使用调优参数，
1>定合理的目标
2>合理分配内存
3>io需要
4>影响数据库性能参数(system 层面)
　　优化目的
1>之前调优应用代码
2>索引的，语法
最长等待时间，最大的服务次数，
report
AWR已经包含了stackpack 所有功能，
　　当目标达到，停止调优。
　　统计信息，索引信息
统计信息，会直接优化执行计划，统计信息不会随着表删除而变化，
gather_stats_job:收集统计信息，手工删除后，可以手工收集
DBMS_STATS PACKAGE
　　
SQL>conn scott/tiger
SQL>create table test6 tablespace users as select * from emp;
SQL>select table_name ,num_rows from user_tables;
SQL>exec dbms_stats.gather_table_stats('scott','test6');
等待事件 ，捕获操作等待事件。
　　
SQL> SELECT name, class, value FROM v$sysstat;
NAME CLASS VALUE
------------------------------- ------ ----------
...
table scans (short tables) 64 135116
table scans (long tables) 64 250
table scans (rowid ranges) 64 0
table scans (cache partitions) 64 3
table scans (direct read) 64 0
table scan rows gotten 64 14789836
table scan blocks gotten 64 558542
...
Systemwide statistics are classified by the tuning topic and the debugging purpose. The classes
include general instance activity, redo log buffer activity, locking, database buffer cache activity,
and so on.
　　short table:一次访问块<4
long table:一次访问块>4
　　
察看内存使用情况:
SGA Global Statistics
The server displays all calculated memory statistics in the V$SGASTAT view. You can query
this view to find cumulative totals of detailed SGA usage since the instance started. For example:
SQL> SELECT * FROM v$sgastat;
POOL NAME BYTES
------ ------------------------- ----------
fixed_sga 7780360
buffer_cache 25165824
log_buffer 262144
shared pool sessions 1284644
shared pool sql area 22376876
　　
　　sqlplus  scott/tiger
察看 sid，
　　select * from v_$mystat;
select sid,serial#,username from v$session;
sid+serial 唯一标识会话。
　　||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
　　V$SESSIONThis view lists session information for each current session.
　　Column Datatype Description
SADDR RAW(4 | 8) Session address
SID NUMBER Session identifier
SERIAL# NUMBER Session serial number. Used to uniquely identify a session's objects. Guarantees that session-level commands are applied to the correct session objects if the session ends and another session begins with the same session ID.
AUDSID NUMBER Auditing session ID
PADDR RAW(4 | 8) Address of the process that owns the session
USER# NUMBER Oracle user identifier
USERNAME VARCHAR2(30) Oracle username
COMMAND NUMBER Command in progress (last statement parsed); for a list of values, see Table 7-5. These values also appear in the AUDIT_ACTIONS table.
OWNERID NUMBER The column contents are invalid if the value is 2147483644. Otherwise, this column contains the identifier of the user who owns the migratable session.
For operations using Parallel Slaves, interpret this value as a 4-byte value. The low-order 2 bytes of which represent the session number, and the high-order bytes the instance ID of the query coordinator.

TADDR VARCHAR2(8) Address of transaction state object
LOCKWAIT VARCHAR2(8) Address of lock waiting for; null if none
STATUS VARCHAR2(8) Status of the session:
ACTIVE - Session currently executing SQL
　　INACTIVE
　　KILLED - Session marked to be killed
　　CACHED - Session temporarily cached for use by Oracle*XA
　　SNIPED - Session inactive, waiting on the client

SERVER VARCHAR2(9) Server type (DEDICATED| SHARED| PSEUDO| NONE)
SCHEMA# NUMBER Schema user identifier
SCHEMANAME VARCHAR2(30) Schema user name
OSUSER VARCHAR2(30) Operating system client user name
PROCESS VARCHAR2(12) Operating system client process ID
　　
SQL> select sid,serial#,username,process from v$session;
　　SID    SERIAL# USERNAME                       PROCESS
---------- ---------- ------------------------------ ------------
      1598      15307                                22805
      1600       6096 CX                             22989
      1613       6367                                22344
      1615        115 SYS                            27824
      1617          2                                28056
      1620         29 DBSNMP                         4954
      1621      31765                                16293
      1622          2                                27990
      1626          1                                27975
      1627          3                                27973
      1628          1 SYS                            27824
　　SID    SERIAL# USERNAME                       PROCESS
---------- ---------- ------------------------------ ------------
      1629          1 SYS                            27824
      1632          1                                27826
      1633          1                                27820
      1634      10221 SYS                            9697
      1636          1                                27808
      1637          1                                27802
      1638          1                                27800
      1639          1                                27798
      1640          1                                27791
      1641          1                                27789
      1642          1                                27787
　　SID    SERIAL# USERNAME                       PROCESS
---------- ---------- ------------------------------ ------------
      1643          1                                27785
      1644          1                                27783
      1646          1                                27781
      1648          1                                27779
      1649          1                                27777
      1650          1                                27775
      1651          1                                27773
      1652          1                                27771
      1653          1                                27768
      1654          1                                27766
      1655          1                                27759
　　33 rows selected.
　　
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
　　
　　
　　show parameter service;
service 的意义是，依靠服务监视 user.service相当于入口。
单节点可以注册 68个 service name，多节点 102个。
tnsnames.ora  里面可以定义 service name,客户端通过tns 连接进来。
　　RAC:
tnsnames里面如果只指定 sid,不是依照 service name来指定，不会有failover 功能。
如果server 是shared 而不是dedicated ，则只能用 sid来访问服务。
　　RAC 多个节点的 instance name 不同，所以如果要做负载均衡，sid1,sid2 不能放置在tnsnames 里面，
而应该把service name放置到 tnsnames里面。这样才能做Load balance.
　　
当设置了 服务器的 service name之后，
通过下面的命令注册:
alter system register;
重载入监听:
lsnrctl reload;
再查看listener  状态，将可以看到那些 service name.
这个时候我们可以通过 tnsnames.ora里面连接字符串（服务命设置为我们定义的)和数据库通信。
　　
　　v$database ,v$instance,v$parameter,v$process 进程,v$BGPROCESS  后台进程
　　v$buffer_pool_statistics:察看当前 buffer pool占用了多少块，监视了 database buffer  的内容，使用了多少。
　　v$sgainfo:内存中动态参数大小
v$librarycache 决定library cache 命中率。
　　察看 v$datafile ，看files 是否online,还是 (read write/read only)
察看 v$segment_statistics
察看数据块中哪些块被访问的比较多，热点块
　　v$latch:察看内存，（在database buffer 里找空间，锁定内存中的空间）
latch 有30多个命令，锁在调用 后台语句用，锁定级别更低。
oracle 9i 之后 锁争用不再说了。
可以查找 reference manual （查找相关解释)
　　
　　统计信息，用dbmsstat 收集来的统计信息，用user_table也可查看。
　　产生执行计划的时候，除了参照统计信息，也会查找硬件的信息，
如果统计信息还没有产生，oracle 将通过动态采样来产生执行计划。
　　
<<成本预算>>一书，出自 itpub 。执行计划在执行时候有什么依据，及其相关的内容
　　诊断  挂起的数据库情况：
可以采用memory access mode:(无法从字典视图看了)
可以查看下面的参数来 察看情况
　　v$session
v$session_wait;
v$system_event
v$sysstat
　　通过下面的EM方式能够察看 数据库的情况:
EM->performance->monitor in memory access mode
　　察看 hang analyse()
block session():kill session ()
　　AWR 不能用 stackpack的信息,stackpack 也不能 用awr的信息
快照在空间中默认保留 7天，为了防止清除，可以通过 base line，长期保留这些数据。
　　
AWR 比较两个快照集的差异，保存更长的时间。
　　察看快照:
desc  dba_history_snapshot;
　　select snap_id from dba_history_snapshot;
base line(保留 2个快照)
oracle 包含两个快照

　　
Advisor Central
通过调用组建，得到建议。
　　手工调用 ADDM:
创建新snap shot与上次 比较产生新的 分析结果。
SQL  TUNNING  Sets:
一组SQL，组成起来，SQL tunning 集
SQL  Access Advisor:
可以对假象的SQL调优，对索引建立推荐。
　　创建 sql tunning集合
advisor Central->SQL 来源 试验 tunning 做。
　　
Asynchronous commit
　　异步提交 ： 还没等LGWR写完，已经可以提高了。
一般我们不会使用 异步提交。
alter system set commit_write = immediate,wait
alter session set commit_write = immediate,wait
　　
latch,wait 全部一起提交才可以。
　　commit write batch wait;
commit write batch nowait;
如果多个用户同时连上来了，在同一时间可能有 3个用户同时commit,oracle可以把这些内容同时提交， 叫做 commit batch.
　　解决对大表访问慢的问题，IO 索引表（表和索引放在一起)
cluster 簇表：存放的时候把关联结构也存进去了。
　　
10g: 估计一个表未来的大小，分析增长趋势，管理optimizer,重组 用户信息
堆表:

每个partition 属于不同的段，并都可以存在独立的表空间，partition表成员
必须遵守列和属性都一致的约束。
partition 对应用程序是透明的，包含很多种类(p323)
范围分区

list 分区
知道所有区人口，地区做list列表，
不同人放不同的分区
　　hash 分区:
通过hash算法，把不同数据放不同的位置（这种hash分区用的比较少)
　　组合分区：
有2种
先范围分区，再list 分区
先范围分区，再hash分区
　　
　　
索引组织表: 支节点最多能有24 个层次。

联系，创建partition
admin->tables->create table->堆表
　　创建成功后察看范围:
select * from testp partition(testp_p3);
正常的partition策略是每个分区指定一个表空间。
　　
　　怎么让dml语句不产生日志：
insert append nologging.
　　partition :分区方法
分区表维护(partition) p326面
　　io索引组织表，没有物理的rowid，只有逻辑rowid
iot索引组织表的好处
不能是延迟约束（插入不检查，提交裁检查）
iot　不能包含long　或rowid类型。
blob　数据类型（存指向）
clob 存在数据库里
　　toad 可以把图像显示出来。
　　threshold:20
超过　20%就放到另一个表空间。
　　簇表不能经常变动，因为簇表的目的就是减少表关联的时间
　　簇表的类型
1>index cluster
2>hash_cluster (hash 簇)
3>stored hash cluster( 排序过的hash簇)
　　所有行数据比较小，适合用簇。
表大量增长，簇不断被修改，不适合做簇表。 (不适合的场景

　　簇表不适合的情况:
簇不断被修改，不适合做簇表，簇表适合的场景，数据量小，改动少的情况。
　　对于簇表，不用再跟内容了( order by)
簇表的建立时间。
　　
　　CREATE CLUSTER calls_cluster
( origin_number NUMBER
, call_timestamp NUMBER SORT
, call_duration NUMBER SORT)
HASHKEYS 10000
SINGLE TABLE HASH IS origin_number
SIZE 50;
CREATE TABLE calls
( origin_number NUMBER
, call_timestamp NUMBER
, call_duration NUMBER
, other_info VARCHAR2(30))
CLUSTER calls_cluster(
origin_number,call_timestamp,call_duration
);
　　
簇表不太适合中国的环境，因为中国数据量都比较大阿，管理对象的统计信息。
可以查看 杨昆廷的书 IOT簇表
　　1>估计表达小，估计 行数
比如建一个表， 列类型是  name,varchar2,80 估算 有200万行，需要多大。
趋势分析。
　　SQL replay 比 restore optimizer 更好。
　　如果对一个table 做了move 操作之后，它的原来的索引将会实效了，
对于9i情况下，将会报错，
如果是10g，oracle 将执行全表扫描。
　　
表重组:
重组:选择 move 与导入导出相比，move 更好;rebuild 与删除索引重建相比，rebuild 更好。
(因为相对于重建索引，rebuild 的时候不需要排序了)
　　建议对表采取move来重组表，对索引采取rebuild 重建索引。
重组的方法将导致表的分部重分散的 区变成连续的区。
　　可以在em 里面show tablespace contents。来查看 表的分布情况。
对于 index 的重建有一种方法，叫做rebuild online.
这种在线rebuild 的好处是 维护期间只针对index 条进行维护，不影响其它的 index.
而采取删除重建的方法,将会影响其它的事务，10g里其他事物将变成全表扫描了。
　　reorganize=move
alter table "scott"."EMP" MOVE
alter index "scott","PK_EMP" REBUILD (users online) 只针对move的索引
begin DBMS_STATS.GATHER_TABLE_STATS("SCOTT","EMP",estimate_percent=>null,cascade=>true);
end;
重定义可以看 lab_07_02.sh
             版权声明：本文为博主原创文章，未经博主允许不得转载。