SQL Server备份事务日志结尾(Tail)
事务日志结尾经常提交数据库未备份的事务日志内容。基本上，每一次你执行事务日志备份时，你都在执行事务日志结尾的备份。
那为什么会这么设计呢？因为也许由于介质的损坏，当数据库已经不再可用时，麻烦就来了。如果下一个逻辑步骤正好就是要备份当前事务日志的话，可以应用这个备份来使数据库处于等待(Standby)状态。你甚至可以在数据库文件不可用的状态下使用NO_TRUNCATE来备份事务日志，例如：
BACKUP LOG AdventureWorks TO DISK = 'G:\Backups\AdventureWorks_log_tail.bak' WITH NO_TRUNCATE
然后，你可以使用备份日志的结果把处于等待状态的数据“带回”到发生错误之前的状态。
注意：这也是另一个让你把事务日志文件同数据文件放在不同磁盘上的原因。如果它们在同一个磁盘上的话，磁盘损坏了，你就不能从磁盘上再取到事务日志的备份了。
另一个问题是，当你的数据使用批量日志恢复模型时，当前的事务日志只包括最小化的日志事务。在这种情况下，一个事务日志备份需要存储数据页的修改。如果你的数据文件不可用了，你也就不能备份事务了，甚至是带NO_TRUNCATE选项也不行。
最后，如果你使用的是SQL Server 2005或以上版本，每次你要恢复的数据库都是已经存在的数据库，而且是完整或是批量日志恢复模型，而且事务日志包括活动事务的话，那会收到和下面类似的错误信息：
Server: Msg 3159, Level 16, State 1, Line 1
The tail of the log for the database "AdventureWorks" has not been backed up. Use BACKUP LOG WITH NORECOVERY to backup the log if it contains work you do not want to lose. Use the WITH REPLACE or WITH STOPAT clause of the RESTORE statement to just overwrite the contents of the log.
Server: Msg 3013, Level 16, State 1, Line 1
RESTORE DATABASE is terminating abnormally.
上面的信息就是SQL Server在告诉你，事务日志中有些日志记录还没有被备份。假如当前事务日志可以被丢弃的话，你可以使用REPLACE选项来让SQL Server忽略当前的事务日志。如下：
RESTORE DATABASE AdventureWorks from DISK = 'G:\Backups\AdventureWorks_full.bak' WITH REPLACE
本文翻译自sqlbackuprestore，更多精彩内容请浏览http://www.sqlbackuprestore.com
相关文档：
系统环境：Windows 7
软件环境：Visual C++ 2008 SP1 +SQL Server 2005
本次目的：编写一个航空管理系统
这是数据库课程设计的成果，虽然成绩不佳，但是作为我用VC++ 以来编写的最大程序还是传到网上，以供参考。用VC++ 做数据库设计并不容易，但也不是不可能。以下是我的程序界面，后面 ......
1)
假定有一个用户表，表中包含字段：
userid
(int)
、
username
(varchar)
、
password(varchar)
、等，
该表需要设置主键，以下说法正确的是（）。（选择两项）
a)
如果不能有同时重复的
username
和
password
，那么
username
和
password
可以组合在一起作为主键。
......
闪回
1 特征
闪回数据库只是逻辑数据遭到破坏时的手段。
闪回数据库日志必须在数据库恢复区中创建。
闪回日志不需要归档，不能用于物理恢复。
执行闪回数据库操作时，背景进程RVWR就启动了。
2 使用闪回数据库
3种工具，SQL*Plus，RMAN，OEM。
（1）要求
为了使用闪回数据库，数据库必须处于归档日志模式� ......
下列语句部分是Mssql语句，不可以在access中使用。
SQL分类：
DDL—数据定义语言(CREATE，ALTER，DROP，DECLARE)
DML—数据操纵语言(SELECT，DELETE，UPDATE，INSERT)
DCL—数据控制语言(GRANT，REVOKE，COMMIT，ROLLBACK)
首先,简要介绍基础语句：
1、说明： ......
ms sql中的int型默认是4位，mysql的int型默认是11位，前者到后者的移植不会有什么隐患，但是后者到前者的移植就存在位数不够，不能存储大数的隐患。
还有bigint，ms sql是8位，mysql默认是20位。 ......
