SQLServer——数据库恢复
以前做项目，曾经遇到过数据库发生了几乎致命的异常，但是有效的回复，使数据得以保留，避免较大的损失。今天把一些经验整理一下，分享给大家。希望对大家有所帮助。
在恢复的时候，最理想的情况就是你的数据文件和日志文件都完好无损了，这样只需要sp_attach_db，把数据文件附加到新的数据库上即可，或者在停机的时候把所有数据文件(一定要有master等)都copy到原有路径下也行，不过一般不推荐这样的做法，sp_attach_db比较好，虽然麻烦许多。
但是呢，一般数据库崩溃的时候系统是未必能有时间把未完成的事务和脏页等写入磁盘的，这样的情况sp_attach_db就会失败。那么，寄期望于DBA制定了一个良好的灾难恢复计划吧。按照你的恢复计划，还原最新的完全备份，增量备份或者事务日志备份，然后如果你的活动事务日志还能读得出来的话，这样的话你可以还原到崩溃前的状态。
一般的单位都是没有专职的DBA的，如果没有可用的备份，更可能是最近一次备份的时间过于久远而导致不可接受的数据损失，而且你的活动事务日志也处于不可用的状态，那就是最麻烦的情况了。
不幸的是，一般数据库崩溃都是由于存储子系统引起的，而这样的情况是几乎不可能有可用的日志用于恢复的。
首先，你可以试一下sp_attach_single_file_db，试着恢复一下你的数据文件，虽然能恢复的可能性不大，不过假如这个数据库刚好执行了一个checkpoint的话，还是有可能成功的。
我们可以试着重新建立一个Log，先把数据库设置为emergency mode，sysdatabases的status为32768 就表示数据库处于此状态。
不过系统表是不能随便改的，设置一下先Use MasterGosp_configure 'allow updates', 1reconfigure with overrideGo然后 update sysdatabases set status = 32768 where name = '' 现在，祈求满天神佛的保佑吧，重新建立一个log文件。成功的机会还是相当大的，系统一般都会认可你新建立的日志。如果没有报告什么错误，现在就可以松一口气了。
虽然数据是恢复了，可是别以为事情就算完成了，正在进行的事务肯定是丢失了，原来的数据也可能受到一些损坏：
先把SQL Server 重新启动一下，然后检查你的数据库吧；
先设置成单用户模式，然后做dbcc sp_dboption '', 'single user', 'true'DBCC CHECKDB('')；
如果没有什么大问题就可以把数据库状态改回去了，记得别忘了把系统表的修改选项关掉。update sysdatabases set status = 28 where name = '' ，当然你的数据库状�
相关文档：
======================SqlServer大部分知识都在我这脚本里===============
如果你能把数据结构画出来的话，那么你就入门了！！呵呵！！
--查看konwyoumore库是否存在
USE master
IF exists(SELECT * from sysdatabases WHERE name='KnowYouMore')
BEGIN
DROP DATABASE knowyoumore;
END
GO
--创建konwyo ......
基本配置
一、文件系统要求：
1、至少有二个分区；
2、系统分区不小于10G；
3、分区格式必须是NTFS。
二、补丁安装要求：
1、先安装完毕WINDOWS 2000 SP4+冲击波+震荡波补丁；
2、将WINDOWS 2000补丁升级到最新后才可安装cluster 和SQL Server；
3、SQL Server补丁需升级到Service Pack 3。
三、Cluster信息：
1� ......
BULK INSERT
在SQL Server中，BULK INSERT是用来将外部文件以一种特定的格式加载到数据库表的T-SQL命令。该命令使开发人员能够直接将数据加载到数据库表中，而不需要使用类似于Integration Services这样的外部程序。虽然BULK INSERT不允许包含任何复杂的逻辑或转换，但能够提供与格式化相关� ......
SQL Server导出表到EXCEL文件的存储过程:
*--数据导出EXCEL
导出表中的数据到Excel,包含字段名,文件为真正的Excel文件
,如果文件不存在,将自动创建文件
,如果表不存在,将自动创建表
基于通用性考虑,仅支持导出标准数据类型
---*/
/**//*--调用示例
p_exporttb @tbname='地区 ......
