V$SGASTAT 可看实际的使用情况
Redo log buffer一般在５Ｍ内，可通过v$sessuon_wait看是否等，v$sysstat
可也通过报警文件看是否等切换，方法可加组。可通过nologging（数据库也要设定支持nologging）方法减少日志文件产生量。
java_pool 没有设定时，使用shared_pool_size
3.6.1.3.1 shared_pool
本缓冲区用于sql语句，pl sql等的对象保存
Cursor_sharing{Exact|Similar|force} 游标共享设定
Force方式适用OLTP数据库，Exact方式适合数据仓库，similar为智能方式
hard parses 硬SQL语句分析，每秒要底于100次,小要加大shared_pool
soft parse 软SQL语句分析，OLTP要达90%以上，小要加大shared_pool
不建议用无命名PL SQL段
如果有大PL SQL(存储过程)对象可强制保存于内存，也可加大SHARED_POOL_RESERVED_SIZE，大小不可过SHARED_POOL_SIZE的50%，不然实例不能起动
3.6.1.3.2 db_cache
本缓冲区用于数据库数据对象保存
db_cache_advice 为on，可以提出通过企业管理器看到系统建议
通过select * from v$system_event 进行系统查看。
发现存在free buffer waits，说明不能将data buffer及时写入data file;
可通过增加加CPU后，加db_writer_processes=CPU数改善。
也 可设disk_asynch_io为true,使用异步IO（前提同要操作系统支持）db_writer_processes=1时（只有一个CPU的情 况下），也可通加大dbwr_io_slaves来改善。db_writer_processes>1,不可用本功能
调整效果排序：异步IO>CPU>dbwr_io_slaves
Buffer Busy Waits大说明出现IO冲突
Buffer Busy Waits 大 和 dbbock大说明全表扫描多，说明数据不能读入，可加大
db_cache_size来改善.
Undo block大要加大回滚段（手动管理方式，９Ｉ默认是自动管理）
undo header 大要加大回滚段（手动管理方式，９Ｉ默认是自动管理）
db_cache命中率99%，不是唯一因素，关系是不要出现等待。建议达90%以上。
内存使用建议：
系统可以设三个缓冲区，建表时可设定用那个缓冲区（默认在db_cache_size）
db_cache_size （默认区）
db_keep_cache_size （常访问，小于db_keep_cache_size的10%的表可放于本区）
db_recycle_cache_size （一个事物完成后常时间不再使用，或两倍大小于缓冲区）
3.6.2 排序的优化
9I 为专用服务器时系统变量workarea_size_policy 设定为auto, statistics_level设定为 TYPICAL 可获取v$pga_target_advice中的优化建议。参数pga_aggregate_target值为所有连接用户可用排序内存。
9I为共享服务器时workarea_size_policy设定为menaul, sort_area_size值为每用户排序内存。
如果内存不足将使用TEMP表空间进行排序,排序使用比率disk/meme应小于5%
尽量少用排序,如果使用排序功能，尽量在字段上加索引进行优化。
SQL 分析模式:RBO(基于规则)方案小表(驱动表)放在最后,优先使用索引,对SQL语句要求严格(8I以前的模式);CBO （基于开销）根据统计值进行选择开销最少,性能最优的最佳方式进行,但本方式DBA(使用analyze table语句)要定期进行分析统计.系统设定通过optimizer_mode 系统参数
说明: 指定优化程序的行为。如果设置为 RULE, 就会使用基于规则的优化程序, 除非查询含有提示。如果设置为 CHOOSE, 就会使用基于成本的优化程序, 除非语句中的表不包含统计信息。ALL_ROWS 或 FIRST_ROWS
始终使用基于成本的优化程序。
值范围: RULE | CHOOSE | FIRST_ROWS | ALL_ROWS
默认值: CHOOSE
｛rule（RBO）|choose（自动选择）|fist_rows| fist_rows_n|all_row｝
3.6.3 统计信息
进行某表的统计分析
EXECUTE dbms_stats.gather_table_stats ('HR','EMPLOYEES');
查看结果
SELECT num_rows, blocks, empty_blocks as empty, avg_space, chain_cnt, avg_row_len FROM dba_tables WHERE owner = 'HR' AND table_name = 'EMPLOYEES';
4 设计工具
统一使用sybase power designer设计工具，在该工具上完成物理模型的设计。所有的数据库对象尽可能在物理模型上进行设计，而且每个物理模型都要有相应的文字描述。
所有的数据库对象变更以数据库物理模型为基准。为了避免字符敏感问题，产生的脚本以大写字母为标准。
数据库设计14个要点
数据库设计中的14个技巧
数据库的设计有很多技巧，以下就介绍其中的几种，是许多人在大量的数据库分析与设计实践中，逐步总结出来的。对于这些经验的运用，读者不能生帮硬套，死记硬背，而要消化理解，实事求是，灵活掌握。并逐步做到：在应用中发展，在发展中应用。
4.1 原始单据与实体之间的关系
可以是一对一、一对多、多对多的关系。在一般情况下，它们是一对一的关系：即一张原始单据对应且只对应一个实体。在特殊情况下，它们可能是一对多或多对一的关系，即一张原始单据对应多个实体，或多张原始单据对应一个实体。这里的实体可以理解为基本表。明确这种对应关系后，对我们设计录入界面大有好处。
〖例1〗：一份员工履历资料，在人力资源信息系统中，就对应三个基本表：员工基本情况表、社会关系表、工作简历表。这就是“一张原始单据对应多个实体”的典型例子。
4.2 主键与外键
一般而言，一个实体不能既无主键又无外键。在E－R 图中, 处于叶子部位的实体, 可以定义主键，也可以不定义主键(因为它无子孙), 但必须要有外键(因为它有父亲)。 主键与外键的设计，在全局数据库的设计中，占有重要地位。当全局数据库的设计完成以后，有个美国数据库设计专家说：“键，到处都是键，除了键之外，什么也没有”，这就是他的数据库设计经验之谈，也反映了他对信息系统核心(数据模型)的高度抽象思想。因为：主键是实体的高度抽象，主键与外键的配对，表示实体之间的连接。
4.3 基本表的性质
基本表与中间表、临时表不同，因为它具有如下四个特性： (1) 原子性。基本表中的字段是不可再分解的。
(2) 原始性。基本表中的记录是原始数据（基础数据）的记录。
(3) 演绎性。由基本表与代码表中的数据，可以派生出所有的输出数据。 (4) 稳定性。基本表的结构是相对稳定的，表中的记录是要长期保存的。
理解基本表的性质后，在设计数据库时，就能将基本表与中间表、临时表区分开来。
4.4 范式标准
基本表及其字段之间的关系, 应尽量满足第三范式。但是，满足第三范式的数据库设计，往往不是最好的设计。为了提高数据库的运行效率，常常需要降低范式标准：适当增加冗余，达到以空间换时间的目的。
〖例2〗：有一张存放商品的基本表，如表1所示。“金额”这个字段的存在，表明该表的设计不满足第三范式，因为“金额”可以由“单价”乘以“数量”得到，说明“金额”是冗余字段。但是，增加“金额”这个冗余字段，可以提高查询统计的速度，这就是以空间换时间的作法。
在Rose 2002中，规定列有两种类型：数据列和计算列。“金额”这样的列被称为“计算列”，而“单价”和“数量”这样的列被称为“数据列”。 表1 商品表的表结构
商品名称 商品型号 单价 数量 金额 电视机 29吋 2,500 40 100,000
4.5 通俗地理解三个范式
通俗地理解三个范式，对于数据库设计大有好处。在数据库设计中，为了更好地应用三个范式，就必须通俗地理解三个范式(通俗地理解是够用的理解，并不是最科学最准确的理解)：
第一范式：1NF是对属性的原子性约束，要求属性具有原子性，不可再分解；