The DB File Scattered Read wait event generally indicates waits related to full table scans or fast
full index scans. As full table scans are pulled into memory, they are scattered throughout the
buffer cache, since it is usually unlikely that they fall into contiguous buffers. A large number
indicates that there may be missing or suppressed indexes. This could also be preferred, since it
may be more efficient to perform a full table scan than an index scan. Check to ensure full table
scans are necessary when you see these waits. Try to cache small tables to avoid reading them
into memory over and over again. Locate the data on disk systems that have either more disk
caching or are buffered by the OS file system cache. DB_FILE_MULTIBLOCK_READ_COUNT
can make full scans faster (but it could also influence Oracle to do more of them). You can also
partition tables and indexes so that only a portion is scanned. Slow File I/O (slow disks) can
......
The DB File Sequential Read wait event generally indicates a single block read (an index read,
for example). A large number could indicate poor joining orders of tables or unselective indexing.
This number will certainly be large (normally) for a high-transaction, well-tuned system. You
should correlate this wait with other known issues within the STATSPACK report such as
inefficient SQL. Check to ensure index scans are necessary and check join orders for multiple
table joins. The DB_CACHE_SIZE will also be a determining factor in how often these waits show
up; hash-area joins causing problems should show up in the PGA memory but similarly are
memory hogs that can cause high wait numbers for sequential reads or can also show up as
direct path read/write waits. Range scans can read a lot of blocks if the data is spread in many
different blocks (density within blocks could cause issues with range scans, and reverse key
indexes could be pro ......
1.LVM:
[root@vmfs ~]# pvdisplay
--- Physical volume ---
PV Name /dev/sdg
VG Name db_v4
PV Size 2.00 GB / not usable 0
Allocatable yes
PE Size (KByte) 4096
Total PE 511
Free PE 1
Allocated PE 510
PV UUID MlB8lE-H3DL-RCcf-p5Di-J6A2-INLc-zw328m
......
数据表的连接有:
1、内连接(自然连接): 只有两个表相匹配的行才能在结果集中出现
2、外连接: 包括
（1）左外连接(左边的表不加限制)
（2）右外连接(右边的表不加限制)
（3）全外连接(左右两表都不加限制)
3、自连接(连接发生在一张基表内)
select a.studentno, a.studentname, b.classname
from students a, classes b
where a.classid(+) = b.classid;
STUDENTNO STUDENTNAM CLASSNAME
---------- ---------- ------------------------------
1 aa 一年级一班
2 bb 一年级二班
......
今天参加了Oracle & SUN合并后第一次与合作伙伴及客户的通气会。整个会议给我的感觉是：Oracle雄心勃勃，SUN意气风发，而我自己，心怀惴惴。 Oracle有了SUN，那么从硬件到软件Oracle的产品线就十分齐备了。Oracle半年前推出11gR2 for linux，接着for solaris，而至今都没有for windows。这是否意味着：Oracle已有足够能力对其他平台说不。是否意味着：Oracle将借助其数据库市场的领先地位，全面推广for Oracle的Storage、Server、OS、Middleware、APP。如果是，那么Oracle将成为事实上的垄断者。无论SI、Customer，都将受到负面影响。 MySQL怎么办？如果Oracle既不对其支持、也不对其放手，甚至通过蚕食的手段吸收其市场。那后果会怎样？加剧Oracle对企业级数据库市场的垄断？这并非仅是我的悲观论调：今天我在会场上没有听到任何关于MySQL未来的说法，并且现场询问Oracle & SUN的高层官员也没能得到清晰的响应。Oracle官员说不放弃，这不是我们想听到的，我们希望Oracle能对MySQL做出规划，否则鬼才相信它会越来越好。 原SUN的系统总监在� ......
select count(*) from t1;
这句话比较简单，但很有玄机！对这句话运行的理解，反映了你对数据库的理解深度！
建立实验的大表他t1
SQL> conn scott/tiger
已连接。
SQL> drop table t1 purge;
表已删除。
SQL> create table t1 as select * from emp where 0=9;
表已创建。
SQL> insert into t1 select * from emp;
已创建14行。
SQL> insert into t1 select * from t1;
已创建14行。
SQL> /
已创建28行。
SQL> /
已创建56行。
SQL> /
已创建112行。
SQL> /
已创建224行。
SQL> /
已创建448行。
SQL> /
已创建896行。
SQL> /
已创建1792行。
SQL> /
已创建3584行。
SQL> /
已创建7168行。
SQL> /
已创建14336行。
SQL> /
已创建28672行。
SQL> /
已创建57344行。
SQL> commit;
提交完成。
收集统计信息
SQL> execute dbms_stats.gather_table_stats('SCOTT','T1');
PL/SQL 过程已成功完成。
SQL> SET AUTOT TRACE EXP
SQL> SELECT COUNT(*) from T1;
执行计划
-------------------------------------------------- ......
最新文章 :