A. sql优化器基于规则优化器和基于成本优化器的区别
Oracle有两种优化器：RBO和CBO。 RBO的最大的问题在于它是靠硬编码在ORACLE数据库代码中的一系列规定的规则来决定目标SQL的执行计划的，而并没有考虑目标SQL中所涉及的对象的时间数据量，实际数据分布情况，这样一旦规定规则并不适用于该SQL中所涉及的实际对象时，RBO根据规定规则产生的执行计划就很可能不是当前情况下的最优执行计划了。
下面我们来看如下的例子：
select * from EMP_TEMP where manager_id=100;
假设在EMP_TEMP的manager_id上事先有名为IDX_MGR_TEMP的单键值B数索引，如果我们用的是RBO，则不管EMP_TEMP的数据量多大，也不管MANAGER_ID的数据分布如何，ORACLE执行的时候始终会选择做对IDX_MGR_TEMP的范围索引扫描，并回表取得EMP_TEMP中的记录。ORACLE是不会选择全表扫描EMP_TEMP表的，因为对于RBO而言，全表扫描的等级值要高于索引范围扫描值的等级值。
RBO的这种选择在表EMP_TEMP的数据量不大，而且满足manager_id=10的条件的记录少的情况下是影响不大的，如果表EMP_TEMP的数据量非常大，例如1000万条记录，
而且这1000万条记录的MANAGER_ID的值都是100，在这种极端的情况下，如果是RBO,显然它任然用IDX_MGR_TEMP索引范围扫描，这个时候性能肯定是很差的。因为相当于以单块顺序扫描所有的1000万行索引，然后再回表1000万次。显然没有使用多块以全表扫描方式直接扫描表EMP_TEMP的执行效率高。所以为了解决RBO的这个先天的缺陷，从ORACLE 7开始，ORACLE就引入了CBO。CBO在选择目标SQL的执行计划时，是用执行成本作为判断原则的。CBO会从目标SQL诸多可能的执行路径中选择一条成本值最小的执行路径作为其执行计划，各条执行路径的成本是根据目标SQL语句所涉及的表，索引，列等相关对象的统计信息计算出来的。这些信息存储在ORACLE的数据库的数据字典里，且从多个维度描述了ORACLE数据库里相关对象的实际数据量，实际数据分布等详细信息。
NOTE:ORACLE在对一条执行路径计算成本时，并不一定从头到尾完整计算完，只是要ORACLE在计算过程中发现算出来的部分成本值已经大于之前保存下来的到目前为止的最小成本值，就会马上终止对当前执行路径成本值的计算，并转而开始计算下一条新的执行路径的成本。这个过程会一直持续下去，直到目标SQL的给各个可能的执行路径全部计算完毕或已经达到预先定义好的待计算的执行路径数量的阀值。
RBO是根据硬编码在ORACLE数据库中来决定目标SQL的执行计划的，并没有考虑目标SQL所所涉及的对象的实际数据量，实际分布情况等。而CBO则恰恰相反，它会根据目标SQL的相关的对象的实际数据量，实际数据分布情况的统计信息来决定其执行计划，即意味着CBO是随着目标SQL中所涉及的对象的统计信息的变化而变化的。这就意味着只有统计信息相对准确，则用CBO来解析目标SQL会比同等条件下的RBO来解析得到正确执行计划的概率要高。
当然CBO并不是完美的，它的缺陷主要表现在：
1，CBO会默认目标SQL语句的WHERE条件中出现的各个列之间是独立的，没有关系的。
2，CBO会假设所有的目标SQL都是单独执行的，并且互不干扰。
3，CBO对直方图统计信息有诸多限制。
4，CBO在解析多个表关联的目标SQL时，可能会漏掉正确的执行计划。
B. 如何用SQL语言实现数据库空间容量报警
CREATE OR REPLACE PROCEDURE "P_DBSPACE_ALERT"
as
begin
insert into tsy_op_log
SELECT s_tsy_op_log.nextval,3,0,65537,sysdate,0,7,'数据库报警 '||'最高级别 '||' 表空间'||F.TABLESPACE_NAME||'用
了'||
TO_CHAR ((T.TOTAL_SPACE - F.FREE_SPACE),'999,999.99')||',空闲'||
TO_CHAR (F.FREE_SPACE, '999,999.99') ||',空闲百分比'||
TO_CHAR ((ROUND ((F.FREE_SPACE/T.TOTAL_SPACE)*100)),'999.99')||' %,请及时增加表空间容量' PER_FREE,3,100,0,0
FROM (
SELECT TABLESPACE_NAME,
SUM (BLOCKS*(SELECT VALUE/1024 FROM V$PARAMETER
WHERE NAME = 'db_block_size')/1024
) FREE_SPACE
FROM DBA_FREE_SPACE
GROUP BY TABLESPACE_NAME
) F,
(
SELECT TABLESPACE_NAME,
SUM (BYTES/1048576) TOTAL_SPACE
FROM sys.DBA_DATA_FILES
GROUP BY TABLESPACE_NAME
) T
WHERE F.TABLESPACE_NAME = T.TABLESPACE_NAME
AND (ROUND ((F.FREE_SPACE/T.TOTAL_SPACE)*100)) < 10;
insert into tsy_op_log
SELECT s_tsy_op_log.nextval,3,0,65537,sysdate,0,7,'数据库报警 '||'最高级别 '||owner||'用户的'||object_type||'
'||object_name|| '无效了',3,100,0,0 FROM dba_objects WHERE status<>'VALID' and owner=SYS_CONTEXT
('USERENV','CURRENT_USER') and object_type not in('PACKAG','EPACKAGE BODY','PROCEDURE');
insert into tsy_op_log
select s_tsy_op_log.nextval,3,0,65537,sysdate,0,7,'数据库报警 '||'最高级别 '||SYS_CONTEXT
('USERENV','CURRENT_USER')||'用户的 索引'||' '||index_name|| '无效了',3,100,0,0 from user_indexes where
status<>'VALID' and status<> 'N/A';
commit;
end;
--建立job
--建立数据库报警的job
BEGIN
sys.dbms_scheler.create_job(
job_name => '"TEST"."AFC_TABLESPACE_ALERT"',
job_type => 'PLSQL_BLOCK',
job_action => 'begin
P_DBSPACE_ALERT;
end;',
repeat_interval => 'FREQ=HOURLY',
start_date => to_timestamp_tz('2010-02-04 00:00:00 Asia/Shanghai', 'YYYY-MM-DD HH24:MI:SS TZR'),
job_class => 'AFC_AUTO_TASKS',
comments => 'AFC_TABLESPACE_ALERT',
auto_drop => FALSE,
enabled => FALSE);
sys.dbms_scheler.set_attribute( name => '"TEST"."AFC_TABLESPACE_ALERT"', attribute => 'job_priority', value =>
2);
sys.dbms_scheler.set_attribute( name => '"TEST"."AFC_TABLESPACE_ALERT"', attribute => 'job_weight', value =>
1);
sys.dbms_scheler.set_attribute( name => '"TEST"."AFC_TABLESPACE_ALERT"', attribute => 'restartable', value =>
TRUE);
sys.dbms_scheler.enable( '"TEST"."AFC_TABLESPACE_ALERT"' );
END;
/
C. SQL Server中所说的“脏页”是什么意思
SQL Server的工作原理：不能直接修改硬盘上的数据，而是先将数据从硬盘读入到内存的data cache，然后在内存中修改（被修改过的页称为脏数据页），最后再从内存回写到硬盘。下述进程都可能将脏页回写到硬盘。
一、Checkpoint（检查点）
Checkpoint会搜索整个data cache，将脏页回写到硬盘。
以下情况通常会触发checkpoint：
1、运行Checkpoint 命令。
2、使用alter database往数据库中添加了文件，或者从数据库中删除了文件。
3、备份数据库。在数据库备份之前，数据库引擎会自动执行检查点，以便在备份中包含对数据库数据页面的全部更改。
4、正常关闭SQL Server，并且不使用NOWAIT选项。
5、SQL Server预计的恢复时间超过了恢复间隔（recovery interval）。该值默认为0，即由SQL Server自动配置，一般为1分钟。一般情况下，按最低每分钟10MB日志进行设计。
以下特殊情况也会触发checkpoint：
1、当恢复模式为简单时，如果日志文件的空闲空间低于70%。例外的情况是：如果日志文件是由于一个事务长时间执行而且尚未结束（意味着没有空间可释放）导致空闲空间低于70%，则不会触发checkpoint。
2、当恢复模式为大容量日志时，对数据库做了一个大容量操作。
checkpoint对数据库的影响：
1、当数据库重启时，SQL Server将从checkpoint 完成的这个时间点开始恢复，即在此之后做redo（前滚）。这种机制加速了恢复的进度。
2、当恢复模式为简单时，checkpoint在把脏页回写到硬盘后，就去截断日志（将VLF的状态从2改为0）。
二、Lazywriter（惰性编辑器）
SQL
Server为每一个NUMA（非一致性内存访问）配备一个Lazywriter线程。Lazywriter被定期唤醒后，就去扫描与NUMA节点中的
data cache，检查自由列表（free list）。如果列表的大小低于某个阀值（这个阀值取决于data
cache的总大小）意味着内存压力，Lazywriter就去扫描data
cache，将其中一些页标记到自由列表，表示这是空闲内存；如果这些页中有脏页，就回写到硬盘。
当Lazywriter察觉到系统有内存压力时，它会增加或减少自由列表上的数据页，使操作系统的可用物理内存保持在4.8~5.2MB，以防止分页。
Lazywriter自SQL Server 2005被引入。它与checkpoint的主要区别：checkpoint不会去修改自由列表。
这是一个周期运行的线程，默认情况下，每隔一秒钟运行一次。
三、Worker Thread（工作线程）
SQL Server 启动时，同时启动30~40个工作线程，用于完成客户端连接提出的各种操作请求。当客户端连接增加时，SQL
Server会自动启动新的工作线程。当某个工作线程空闲15分钟，就会被关闭；当空闲内存不够时，某些工作线程也会被关闭（x86环境）。在x86环
境，每个工作线程至少占用0.5MB内存；在x64环境，每个工作线程至少占用2MB内存。
当worker线程察觉内存压力时，它会扫描data cache，把一段时间内未被访问的数据页添加到自由列表；如果这些页中有脏页，就回写到硬盘。
D. sql server 数据表与access数据表部分字段如何同步
Access 没学过，orcle倒是了解一点，sql server还是很认真的学过的
sql学习心得:SQL SERVER 2005学习心得
一、数据库设计方面
1、字段类型。
varchar(max)\nvarchar(max)类型的引入大大的提高了编程的效率，可以使用字符串函数对CLOB类型进行操
作，这是一个亮点。但是这就引发了对varchar和char效率讨论的老问题。到底如何分配varchar的数据，是否
会出现大规模的碎片？是否碎片会引发效率问题？这都是需要进一步探讨的东西。
varbinary(max)代替image也让SQL Server的字段类型更加简洁统一。
XML字段类型更好的解决了XML数据的操作。XQuery确实不错，但是个人对其没好感。（CSDN的开发者应
该是相当的熟了！）
2、外键的级联更能扩展
可能大部分的同行在设计OLTP系统的时候都不愿意建立外键，都是通过程序来控制父子数据的完整性。但是
再开发调试阶段和OLAP环境中，外键是可以建立的。新版本中加入了SET NULL 和 SET DEFAULT 属性，能够
提供能好的级联设置。
3、索引附加字段
这是一个不错的新特性。虽然索引的附加字段没有索引键值效率高，但是相对映射到数据表中效率还是提高了
很多。我做过试验，在我的实验环境中会比映射到表中提高30%左右的效率。
4、计算字段的持久化
原来的计算字段其实和虚拟字段很像。只是管理方面好了而已，性能方面提高不多。但是SQL2005提供了计算
字段的持久化，这就提高了查询的性能，但是会加重insert和update的负担。OLTP慎用。OLAP可以大规模使
用。
5、分区表
分区表是个亮点！从分区表也能看出微软要做大作强SQL Server的信心。资料很多，这里不详细说。但是重点
了解的是：现在的SQL Server2005的表，都是默认为分区表的。因为它要支持滑动窗口的这个特性。这种特性
对历史数据和实时数据的处理是很有帮助的。
但是需要注意的一点，也是我使用过程中发现的一个问题。在建立function->schema->table后，如果在现有
的分区表上建立没有显式声明的聚集索引时，分区表会自动变为非分区表。这一点很让我纳闷。如果你觉得我
的非分区索引无法对起子分区，
你可以提醒我一下呀！没有任何的提醒，直接就变成了非分区表。不知道这算不算一个bug。大家也可以试试
。
分区表效率问题肯定是大家关心的问题。在我的试验中，如果按照分区字段进行的查询（过滤）效率会高于未
分区表的相同语句。但是如果按照非分区字段进行查询，效率会低于未分区表的相同语句。但是随着数据量的
增大，这种成本差距会逐渐减小，趋于相等。（500万数量级只相差10%左右）
6、CLR类型
微软对CLR作了大篇幅的宣传，这是因为数据库产品终于融入.net体系中。最开始我们也是狂喜，感觉对象数
据库的一些概念可以实现了。但是作了些试验，发现使用CLR的存储过程或函数在达到一定的阀值的时候，系
统性能会呈指数级下滑！这是非常危险的！只使用几个可能没有问题，当一旦大规模使用会造成严重的系统性
能问题！
其实可以做一下类比，Oracle等数据库产品老早就支持了java编程，而且提供了java池参数作为用户配置接口
。但是现在有哪些系统大批使用了java存储过程？！连Oracle自己的应用都不用为什么？！还不是性能有问题
！否则面向对象的数据库早就实现了！
建议使用CLR的地方一般是和应用的复杂程度或操作系统环境有很高的耦合度的场景。如你想构建复杂的算法
，并且用到了大量的指针和高级数据模型。或者是要和操作系统进行Socket通讯的场景。否则建议慎重！
7、索引视图
索引视图2k就有。但是2005对其效率作了一些改进但是schema.viewname的作用域真是太限制了它的应用面
。还有一大堆的环境参数和种种限制都让人对它有点却步。
8、语句和事务快照
语句级快照和事务级快照终于为SQL Server的并发性能带来了突破。个人感觉语句级快照大家应该应用。事务
级快照，如果是高并发系统还要慎用。如果一个用户总是被提示修改不成功要求重试时，会杀人的！
9、数据库快照
原理很简单，对要求长时间计算某一时间点的报表生成和防用户操作错误很有帮助。但是比起Oracle10g的闪
回技术还是细粒度不够。可惜！
E. mysql的bin-log压缩阀值是多少
在row模式下，bin-log中可以不记录执行的sql语句的上下文相关信息，仅仅需要记录哪一条记录被修改了，修改成什么信样了，所以row的日志内容会非常清楚的记录下每一行数据修改的细节，非常容易理解。
而且不会出现在某些特定情况下的存储过程和function，以及trigger的调用和处罚无法被正确复制问题。
F. sql 分数字段分段统计
//尝试下面的sql--目测可以的
selectuid,score,t2.flagfrom[dbo].[table1]ast1
leftjoin[dbo].[table2]ast2
ont1.score>=t2.range_maxandt1.score<=t2.range_min
G. sql中怎么给一个变量设置阈值
Sql中如何给变量赋值使用set关键字。例表格tt结构如图：下面语句声明一个@ii_test的整型变量，然后给变量赋值，并在SQL查询中调用变量
H. sql 触发器 阻止多条delete
instead of 触发器(针对一次删除多条)
create trigger club_messages_delete
on club_messages
instead of delete
as
begin
delete from club_Reply where messagesID in (select messagesID from deleted)
delete from club_messages where messagesID in (select messagesID from deleted)
end
after 触发器(针对多条)
create trigger club_messages_delete
on club_messages
after delete
as
begin
delete from club_Reply where messagesID in (select messagesID from deleted)
end
其实根据你的设计方案,我想根本就可以不用触发器,一条留言只对应一条回复,这样的话可以把留言ID作为留言回复的外键,把删除规则设为层叠就可以了
I. 表空间超过阀值怎么解决
你用什么数据库，如果是sqlserver的话压缩一下数据库吧，可以清理大量的日志