SQL基础知识

1.有一个数据库200G大小，每天增加50M 允许用户随时访问，制定备份策略（详细说明）。

这种情况可以采用增量备份方式。每周日做一次全备份，周一到周六作增量备份（由于数据量较少，可以考虑每30分钟增量备份一次）。这样可以尽量减少性能消耗，而且如果transaction log丢失的情况下，可以保证最多丢失30分钟数据。

 

2.管理50台数据库，日常工作是检查数据库作业是否完成，你该如何完成这项检查工作？

这个比较简单。在每台机器上建立linkserver，然后在DBA管理服务器上做个分布式视图，每次查询该视图，各个机器上的作业情况一目了然。分布式视图写法：

create view vw_job
   as

select '机器一' as MName,* from linkserver1..sysjobactivity
union all
select '机器二' as MName,* from linkserver2..sysjobactivity
union all
select '机器三' as MName,* from linkserver3..sysjobactivity

 

3.自定义函数和存储过程的区别是什么，什么情况下只能用自定义函数，什么情况下只能用存储过程

这个应该是考察存储过程编写经验。一般自定义函数主要用于其他sql中的调用，如：

select yourfunc(...) from table

这种情况下，一般只能通过函数实现。

存储过程的功能要远远强于函数，例如动态执行sql（sp_executesql）的使用和一些特殊的功能，自定义函数中是不支持的，只能用存储过程实现。

 

SQL server 中的char和varchar区别
具考证：在字符长度一定时CHAR的性能比VARCHAR好，而在长度不确定时，CHAR类型的字段在使用时性能略差。这个在sqlServer数据库下面能够体现，并且这个字段是经常使用的。
区别：
1．CHAR的长度是固 定的，而VARCHAR2的长度是可以变化的， 比如，存储字符串“abc"，对于CHAR (20)，表示你存储的字符将占20个字节(包括17个空字符)，而同样的VARCHAR2 (20)则只占用3个字节的长度，20只是最大值，当你存储的字符小于20时，按实际长度存储。由于char是以固定长度的，所以它的速度会比 varchar快得多!但程序处理起来要麻烦一点，要用trim之类的函数把两边的空格去掉!
2．CHAR的效率比VARCHAR2的效率稍高。
3．目前VARCHAR是VARCHAR2的同义词。工业标准的VARCHAR类型可以存储空字符串，但是oracle不这样做，尽管它保留以后这样做的 权利。Oracle自己开发了一个数据类型VARCHAR2，这个类型不是一个标准的VARCHAR，它将在数据库中varchar列可以存储空字符串的 特性改为存储NULL值。如果你想有向后兼容的能力，Oracle建议使用VARCHAR2而不是VARCHAR。
何时该用CHAR，何时该用varchar2？
CHAR与VARCHAR2是一对矛盾的统一体，两者是互补的关系.
VARCHAR2比CHAR节省空间，在效率上比CHAR会稍微差一些，即要想获得效率，就必须牺牲一定的空间，这也就是我们在数据库设计上常说的‘以空间换效率’。
VARCHAR2 虽然比CHAR节省空间，但是如果一个VARCHAR2列经常被修改，而且每次被修改的数据的长度不同，这会引起‘行迁移’(Row Migration)现象，而这造成多余的I/O，是数据库设计和调整中要尽力避免的，在这种情况下用CHAR代替VARCHAR2会更好一些。
一般地说，只要一个表有一个字段定义为varchar(n)类型，那么其余用char(n)定义的字段实际上也是varchar(n)类型。

如果你的长度本身不长，比如就3～10个字符，那么使用char(n)格式效率比较高，搜索速度快。但是如果有的数据很长，有的数据有比较短，比如注册用户的简介这样的字段，实在没有办法，而且很在乎浪费的空间，那么就用varchar(n)格式。

SQL Server中，varchar和nvarchar如何选择？
varchar在SQL Server中是采用单字节来存储数据的，nvarchar是使用Unico来存储数据的．中文字符存储到SQL Server中会保存为两个字节（一般采用Unico编码），英文字符保存到数据库中，如果字段的类型为varchar，则只会占用一个字节，而如果字段 的类型为nvarchar，则会占用两个字节．
　　正常情况下，我们使用varchar也可以存储中文字符，但是如果遇到操作系统是英文操 作系统并且对中文字体的支持不全面时, 在SQL Server存储中文字符为varchar就会出现乱码(显示为??)．而且正常情况下，主机都会支持中文的环境，所以如果使用varchar来存储数 据，在开发阶段是发现不了的．多数情况下，在布署的时候也不会有问题．
　　但是！如果布署的主机是英文操作系统，并且不支持中文环境，那问 题就出来了．所有的varchar字段在存储中文的时候都会变成乱码（显示为??）．而且一般情况下你不会知道这是因为你采用了错误的数据类型来存储所造 成的，你会试着去装中文字体，试着去设置操作系统的语言环境．．．这些都不能解决问题，唯一能解决问题的是把数据库字段的类型个性为nvarchar（或 者nchar）．对项目管理比较熟悉的朋友应该都知道，到布署阶段再来修改数据库是一个很恐怖的事情．
　　使用nvarchar的另一个非常好处就是在判断字符串的时候可以不需要考虑中英文两种字符的差别．
　　当然，使用nvarchar存储英文字符会增大一倍的存储空间．但是在存储代价已经很低廉的情况下，优先考虑兼容性会给你带来更多好处的．
　　所以在Design的时候应该尽量使用nvarchar来存储数据．只有在你确保该字段不会保存中文的时候，才采用varchar来存储．
varchar(n)
长度为 n 个字节的可变长度且非 Unicode 的字符数据。n 必须是一个介于 1 和 8,000 之间的数值。存储大小为输入数据的字节的实际长度，而不是 n 个字节（如varchar(6),当字段为qqq时，数据库实际占用空间为3个字节，而不是6个字节，但只允许存储6个字节，一般中文占两个字节）。

nvarchar(n)
包含 n 个字符的可变长度 Unicode 字符数据。n 的值必须介于 1 与 4,000 之间。字节的存储大小是所输入字符个数的两倍。

 

SQL 2005 的新特性是什么 ？  与oracle 有什么区别？
SQL 2005 的新特性一般都是和Oracle学的。
下面是当时被leimin逼着写的，你可以做个参考：
一、数据库设计方面
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的闪回技术还是细粒度不够。可惜！
10、Mirror
Mirror可以算是SQL Server的Data guard了。但是能不能被大伙用起来就不知道了。
二、开发方面
1、Ranking函数集
其中最有名的应该是row_number了。这个终于解决了用临时表生成序列号的历史，而且SQL Server2005的row_number比Oracle的更先进。因为它把Order by集成到了一起，不用像Oracle那样还要用子查询进行封装。但是大家注意一点。如下面的例子：
select ROW_NUMBER() OVER (order by aa)
from tbl
order by bb
会先执行aa的排序，然后再进行bb的排序。
可能有的朋友会抱怨集成的order by，其实如果使用ranking函数,Order by是少不了的。如果担心Order by会影响效率，可以为order by的字段建立聚集索引，查询计划会忽略order by 操作（因为本来就是排序的嘛）。
2、top
可以动态传入参数，省却了动态SQL的拼写。
3、Apply
对递归类的树遍历很有帮助。
4、CTE
个人感觉这个真是太棒了！阅读清晰，非常有时代感。
5、try/catch
代替了原来VB式的错误判断。比Oracle高级不少。
6、pivot/unpivot
个人感觉没有case直观。而且默认的第三字段（还可能更多）作为group by字段很容易造成新手的错误。
 
三、DBA管理方面
1、数据库级触发器
记得在最开始使用2k的时候就要用到这个功能，可惜2k没有，现在有了作解决方案的朋友会很高兴吧。
2、多加的系统视图和实时系统信息
这些东西对DBA挑优非常有帮助，但是感觉粒度还是不太细。
3、优化器的改进
一直以来个人感觉SQL Server的优化器要比Oracle的聪明。SQL2005的更是比2k聪明了不少。（有次作试验发现有的语句在200万级时还比50万级的相同语句要快show_text的一些提示没有找到解释。一直在奇怪。）
论坛例子：
http://community.csdn.net/Expert/topic/4543/4543718.xml?temp=.405987
4、profiler的新事件观察
这一点很好的加强了profiler的功能。但是提到profiler提醒大家注意一点。windows2003要安装sp1补丁才能启动profiler。否则点击没有反应。
5、sqlcmd
习惯敲命令行的朋友可能会爽一些。但是功能有限。适合机器跑不动SQL Server Management Studio的朋友使用。
四、遗憾
1、登陆的控制
始终遗憾SQL Server的登陆无法分配CPU/内存占用等指标数。如果你的SQL Server给别人分配了一个只可以读几个表的权限，而这个家伙疯狂的死循环进行连接查询，会给你的系统带来很大的负担。而SQL Server如果能像Oracle一样可以为登陆分配如：5%的cpu，10%的内存。就可以解决这个漏洞。
2、数据库物理框架没有变动
undo和redo都放在数据库得transaction中，个人感觉是个败笔。如果说我们在设计数据库的时候考虑分多个数据库，可能能在一定程度上避免 I/O效率问题。但是同样会为索引视图等应用带来麻烦。看看行级和事务级的快照数据放在tempdb中，就能感觉到目前架构的尴尬。
3、还是没有逻辑备份
备份方面可能还是一个老大难的问题。不能单独备份几个表总是感觉不爽。灵活备份的问题不知道什么时候才能解决。
4、SSIS(DTS)太复杂了
SQL Server的异构移植功能个人感觉最好了。（如果对比过SQL Server的链接服务器和Oracle的透明网关的朋友会发现SQL Server的sp_addlinkedserver(openquery)异构数据库系列比Oracle真是强太多了。）
以前的DTS轻盈简单。但是现在的SSIS虽然功能强大了很多，但是总是让人感觉太麻烦。看看论坛中询问SSIS的贴子就知道。做的功能太强大了，往往会有很多用户不会用了。

与oracle 有什么区别？
这个问题相当变态！不同点我能给他讲一天！首先名字就不一样嘛！！ ：）