SQL Server数据库事务日志存储序列
如果你的数据库运行在完整或是批量日志恢复模式下，那么你就需要使用作业(job)来定期备份事务日志，保持你的事务文件大小处在一个可管理的范围。当你需要还原事务日志时，你就需要按照创建事务日志的顺序来恢复它们。你可以参考存在msdb..backupset表中的信息来确定还原文件的顺序，使用FirstLSN和LastLSN列的值作参考。当你备份时，这些备份信息就会存在backupset表中
只要序列处于维护状态下，你就可以使用对应的日志把数据恢复到任意恢复点上。不幸的是，有些实例的序列已经被损坏了。下面两种情况普通是引起损坏的原因：
数据库的恢复模型被切换到了简单(SIMPLE)后，再次被切换回完整或是批量日志。
Backup log命令运行时，附带了TRUNCATE_ONLY/NO_LOG选项。
当上面两种情况发生时，你需要即可做一个数据库的完整备份，作为事务日志恢复的新的恢复点。那么你如何判断序列已经被破坏了呢？
在SQL Server 2000中，这确实有点麻烦。假如数据库恢复模型已经被更改了，或是备份时日志已经被截断了，那么当更改后，你第一次备份事务日志时，SQL Server 2000会显示如下输出：
There is no current database backup. This log backup cannot be used to roll forward a preceding database backup.
Processed 1 pages for database 'logtest', file 'logtest_log' on file 1.
BACKUP LOG successfully processed 1 pages in 0.078 seconds (0.019 MB/sec).
注意这仅仅是个消息。虽然备份依然会成功完成，但却不可用。因为这是个计划作业，所以你什么都看不到，不过当事务日志被截断时，在Windows事件日志中是相关警告日志的。。
注意：如果你正在使用SQL Server 2000，那么日志事务对于数据库是非常重要的，所以要在Windows事件日志中不间断的监控日志事务事件。
假如你既没有关注警告消息，也没有监控Windows事件日志，那么基本上你就是有一批不可恢复的事务日志备份。SQL Server不应该警告我们吗？不应该停止无效的备份吗？假如你正在使用SQL Server 2005，那么答案肯定是应该的，而且它也是这么做的。下面就是当日志备份序列被毁坏时显示的消息:
Server: Msg 4214, Level 16, State 1, Line 1
BACKUP LOG cannot be performed because there is no current database backup.
Server: Msg 3013, Level 16, State 1, Line 1
BACKUP LOG is terminating abnormally.
是不是好多了。总之，如果你正在使用SQL Server 2000，你需要关�
相关文档：
动态语句
1 :普通SQL语句可以用exec执行
Select * from tableName
exec('select * from tableName')
exec sp_executesql N'select * from tableName' -- 请注意字符串前一定要加N
2:字段名，表名，数据库名之类作为变量时，必须用动态SQL
declare @fname varchar(20)
set @fname = 'FiledName'
Select @fnam ......
一、常用数据类型：
Number：数字类型
Int：整数型
Pls_integer：整数型，产生溢出的错误
Binary_integer：整数型
Char：定长字符，最长255个字符
Varchar2：变长字符，最长2000个字符
Long：变长字符，最长2GB
Date：日期型
Boolean：布尔型
二、定义常量
格式：常量名 constant &nbs ......
所测试环境为：Ms sqlserver 2008，visual studio 2008
测试数据为10万条
Linq方式 代码：
/// <summary>
/// Linq 方式
/// </summary>
public static void Linq_insert()
{
DataClassesDataContext dataContext = new DataClassesDataContext();
......
处理SQL Server数据库中的孤立用户(图)
把数据库从一个服务器实例附加和恢复到另一个实例中是数据库管理员执行的常见的任务。附加或者恢复一个数据库之后，之前在数据库中创建和配置的登录名已经不能访问了。这个问题最常见的症状是应用程序会遇到登录失败的错误，或者是当你试着把登录名添加到数据库中时，你可能会得到一 ......
--自己很愚蠢的做法，以为直接删除数据库用户名，再从新创建用户登录名和数据库用户名。
--自己以为可以直接创建与之原先一样的数据库登录名就可以
--但这些操作是不起作用的
--原因
--当映射孤立用户时，主从数据库中的SID将分配给孤立用户，所以每次一个数据库备附加或者还原时，--SID在SQL Server 登录名和数据库用� ......
