Ⅰ sql2008R2重启电脑后无法开启SQL服务
这个原因可能是SQL服务的依懒组件或服务被停止,你可以通过查看服务属性,依存关系查看哪些服务停止了.相应启动即可.
Ⅱ SQL Server事务日志的几个常用操作
我们知道，SQL Server事务日志主要是用来记录所有事务对数据库所做的修改，如果系统出现故障，它将成为最新数据的唯一来源。日志的操作常有以下几个应用：
一、事务日志文件LDF的丢失
当我们不小删除或者LDF文件丢失的时候，数据库只剩下MDF文件，此时直接通过附加MDF是无法恢复数据库的，那我们怎么样才能恢复数据库呢?我们可以把SQL Server的日志文件分为两种形式：一类是无活动事务的日志，另一类是有活动事务的日志，我们分别根据两种情况来进行数据库恢复。
1、无活动事务的日志恢复
当文件并没有发生活动性的日志，我们就可以很容易的利用MDF文件就可以直接恢复数据库了，具体操作方法如下：
1)数据库要是没有日志，就会处于置疑的状态，我们先可以通过企业管理器中在对应数据库中点击右键，然后在“所有任务”下选择“分离数据库”把数据库进行分离;
2)利用MDF文件附加数据库生成新的日志文件，可用企业管理器中数据库点击右键选择“所有任务”下的“附加数据库”把数据库附加上。
这样就可以直接恢复好数据库了，而如果数据库的日志文件中含有活动事务，利用此方法就不能恢复数据库，所以得使用下面的方法。
2、有活动事务的日志恢复
当日志发生了事务的记录，丢失的时候，我们采用如下的方法来实现：
1)新建一个同名的数据库，如原数据库名为MYDB，然后停止SQL Server服务器，再把数据库主数据MDF文件移走，然后重新启动SQL Server服务器，新建一个同名的数据库MYDB，然后再停止SQL Server服务器，把移走的MDF文件再覆盖回来，然后再重新启动SQL Server服务器，在默认的情况下，系统表是不允许被修改的，我们需要运行以下语句才可以，在查询分析器中，选择Master数据库，然后执行：
Sp_configure 'allow updates',1
Reconfigure With Override
接着运行以下语句，把Sysdatabases表中MYDB数据库的status属性设为‘37268’,把MYDB数据库设置为紧急模式。
update sysdatabases set status=32768 where name=’MYDB’
然后再把数据库MYDB设置为单用户模式，然后重启SQL Server服务器，并把数据库MYDB设为单用户模式
Sp_dboption 'MYDB','single user', 'true'
Ⅲ sql数据库日志文件
麻烦了，很多DBA不太清楚，数据库的日志装的其实是真正的数据（归档前改变的数据），所以日志文件也是非常重要的。
至于有些数据库的日志文件过大，主要是DBA没有正确的对数据库进行调优设置造成的。
下面的方法也许对你是有用的。
0.备份数据文件'xxzx_discuz_Log.MDF'
1.新建一个同名的数据库'xxzx_discuz'
2.再停掉sqlserver服务(注意不要分离数据库)
3.用原数据库的数据文件'xxzx_discuz_Log.MDF' 覆盖掉新建的数据库
4.再重启sqlserver服务
5.此时打开企业管理器时会出现置疑，先不管，执行下面的语句（注意修改其中的数据库名）
6.完成后一般就可以访问数据库中的数据了。这时,数据库本身一般还有问题,解决办法是：利用数据库的脚本创建一个新的数据库,然后通过DTS将数据导进去就行了.
SQL代码
use master
go
sp_configure 'allow updates',1 reconfigure with override
go
update sysdatabases set status =32768 where name='置疑的数据库名'
go
sp_dboption '置疑的数据库名', 'single user', 'true'
go
dbcc checkdb('置疑的数据库名')
go
update sysdatabases set status =28 where name='置疑的数据库名'
go
sp_configure 'allow updates', 0 reconfigure with override
go
sp_dboption '置疑的数据库名', 'single user', 'false'
go
特别注意最后一步中的说明“这时,数据库本身一般还有问题,解决办法是：利用数据库的脚本创建一个新的数据库,然后通过DTS将数据导进去就行
Ⅳ SQL Server(MSSQLSERVER)服务为什么会启动不了时在哪里看日志信息
我知道啦，真的像网上那个网友说说的那样，其实很多事情都必须自己去琢磨的，我也遇到过此类问题，我还弄了还久大概就一天把，上网找答案，据多时同一个网友的他说只要把SQL的文件解压就还，还有贴图一开始不清不楚，后来自己研究才发现原来真的是这样。我们发现SQL
Server安装目录下的文件夹里的文件大多数是蓝色名字的这说明他们被压缩了，其实我们可以点击整个文件夹右击属性-高级选项点下面的压缩-确定-再回来把那个勾给去掉就把所有的文件一起解压了，可以看到解压回来的文件的文件名字是黑色的这是我们就可以启动服务了。
Ⅳ 如何恢复丢失的SQL Server日志文件
在实际操作中SQLServer日志文件丢失是一件令人十分头疼的事情，以下的文章主要是针对这一问题给出的答案，以下就是正文的主要内容描述。 一、 概述 在应用系统中，数据库往往是最核心的部分，一旦数据库毁坏或损坏，将会带来巨大的损失，所以数据库的管理越来越重要。我们在做数据库管理与维护工作中，不可避免会出现各种各样的错误，本文针对数据库的SQLServer日志文件丢失时如何利用MDF文件恢复数据库的方法进行了研究。 二、 数据库的恢复 当数据库的主数据MDF文件完好无损时，在丢失了LDF文件的情况下，如何利用MDF文件恢复数据库?我们把SQL Server的日志文件分为两类：一类是无活动事务的日志，另一类是含活动事务的日志，根据不同的日志，采取不同的方法来恢复数据库。 1. 无活动事务的日志恢复 无活动事务的日志丢失时，我们很容易利用MDF文件直接恢复数据库，具体方法如下： ①.分离被质疑的数据库，可用企业管理器中的"分离数据库工具"，或者用存储过程sp_detach_db分离数据库; ②利用MDF文件附加数据库生成新的日志文件，可用企业管理器中的"附加数据库"的工具，或者用存储过程sp_attach_single_file_db附加数据库。 如果数据库的日志文件中含有活动事务，利用此方法就不能SQLServer日志文件丢失的恢复数据库。 2. 含活动事务的日志恢复 含有活动事务的日志丢失时，利用上述方法就会出现"数据库和日志文件不符合，不能附加数据库"。对于这种情况下，我们采用如下方法： ①新建同名数据库AAA，并设它为紧急模式 停止SQL Server服务器; 把数据库主数据MDF文件移走; 启SQL Server服务器，新建一个同名的数据库AAA; 停止SQL Server服务器，把移走的MDF文件再覆盖回来; 启动SQL Server服务器，把AAA设为紧急模式，不过默认情况下，系统表是不能随便修改的，必须首先设置一下使其能被修改，运行以下语句即可： Use MasterGosp_configure ’allow updates’,1 reconfigure with override Go 接着运行以下语句，把AAA数据库设为紧急模式，即把Sysdatabases表中AAA数据库的status属性设为’37268’,就表示把AAA数据库处于紧急模式。 update sysdatabases set status=32768 where hame=’AAA’ 如果没有报告什么错误，就可以进行以下操作。 ②设置数据库AAA为单用户模式，并检查数据库 重启SQL Server服务器; 把数据库AAA设为单用户模式 Sp_dboption ’AAA’, ’single user’, ’true’ 运行以下语句，检查数据库AAA DBCC CHECKDB(’AAA’) 如果没有什么大的问题就可以把数据库的状态改回去。 ③还原数据库的状态 运行以下语句，就可以把数据库的状态还原： update sysdatabases set status=28 where name=’AAA’ sp_configure ’allow updates’,0 Go 如果没有什么大的问题，刷新一下数据库，数据库AAA又会出现在你面前，但目前恢复工作还没有做完，此时的数据库仍不能工作，还要进行下面的处理，才能真正恢复。 ④利用DTS的导入导出向导，把数据库AAA导入到一个新建数据库BBB中 新建一个数据库BBB; 右击BBB，选择IMPORT功能，打开导入向导; 目标源选择"在SQL Server数据库之间复制对象和数据库"，这样可以把表结构，数据视图和存储过程导入到BBB中 再用此功能把BBB库替换成原来的AAA库即可。 到此为止，数据库AAA就完全恢复。 SQLServer日志文件丢失是一件非常危险的事情，很有可能你的数据库彻底毁坏。SQL Server数据库的恢复都是靠日志文件来完成，所以无论如何都要保证日志文件的存在，它至关重要。为了使我们的数据库万无一失，最好采用多种备份方式相结合，所以我们要从心里重视数据库的管理与维护工作。
Ⅵ sql server的日志文件能不能删除
数据库在使用过程中会使日志文件不断增加，使得数据库的性能下降，并且占用大量的磁盘空间。SQL Server数据库都有log文件，log文件记录用户对数据库修改的操作。可以通过直接删除log文件和清空日志在清除数据库日志。
一、删除LOG
1、分离数据库。分离数据库之前一定要做好数据库的全备份，选择数据库——右键——任务——分离。
勾选删除连接
分离后在数据库列表将看不到已分离的数据库。
2、删除LOG文件
3、附加数据库，附加的时候会提醒找不到log文件。
删除数据库信息信息的ldf文件：
附加数据库之后将生成新的日志文件log，新的日志文件的大小事504K。
也可以通过命令才完成以上的操作：
use master;
exec sp_detach_db @dbname='TestDB';
exec sp_attach_single_file_db @dbname='TestDB',@physname='D:\Program Files\Microsoft SQL Server\MSSQL10.SQL2008\MSSQL\DATA\TestDB.mdf'
二、清空日志
该命令在SQL Server 2005和2000支持，SQL Server 2008不支持该命令。
DUMP TRANSACTION TestDB WITH NO_LOG
三、收缩数据库文件
DBCC SHRINKFILE ('TestDB_log',1)
四、截断事务日志
BACKUP LOG TestDB WITH NO_LOG
该命令在SQL Server 2008也是不支持，在SQL Server 2005和2000可以使用。
清除SQLServer2005的LOG文件
--最好备份日志，以后可通过日志恢复数据。。。
以下为日志处理方法
一般不建议做第4,6两步
第4步不安全,有可能损坏数据库或丢失数据
第6步如果日志达到上限,则以后的数据库处理会失败,在清理日志后才能恢复.
--*/
--下面的所有库名都指你要处理的数据库的库名
1.清空日志
DUMPTRANSACTION 库名 WITH NO_LOG
2.截断事务日志：
BACKUPLOG 库名 WITH NO_LOG
3.收缩数据库文件(如果不压缩,数据库的文件不会减小
企业管理器--右键你要压缩的数据库--所有任务--收缩数据库--收缩文件
--选择日志文件--在收缩方式里选择收缩至XXM,这里会给出一个允许收缩到的最小M数,直接输入这个数,确定就可以了
--选择数据文件--在收缩方式里选择收缩至XXM,这里会给出一个允许收缩到的最小M数,直接输入这个数,确定就可以了
也可以用SQL语句来完成
--收缩数据库
DBCC SHRINKDATABASE(库名)
--收缩指定数据文件,1是文件号,可以通过这个语句查询到:select * from sysfiles
DBCC SHRINKFILE(1)
4.为了最大化的缩小日志文件(如果是sql 7.0,这步只能在查询分析器中进行)
a.分离数据库:
企业管理器--服务器--数据库--右键--分离数据库
b.在我的电脑中删除LOG文件
c.附加数据库:
企业管理器--服务器--数据库--右键--附加数据库
此法将生成新的LOG，大小只有500多K
或用代码：
下面的示例分离 pubs，然后将 pubs 中的一个文件附加到当前服务器。
a.分离
EXEC sp_detach_db @dbname='库名'
b.删除日志文件
c.再附加
EXEC sp_attach_single_file_db @dbname='库名',
@physname='c:\Program Files\Microsoft SQL Server\MSSQL\Data\库名.mdf'
5.为了以后能自动收缩,做如下设置:
企业管理器--服务器--右键数据库--属性--选项--选择"自动收缩"
--SQL语句设置方式:
EXEC sp_dboption '库名', 'autoshrink', 'TRUE'
6.如果想以后不让它日志增长得太大
企业管理器--服务器--右键数据库--属性--事务日志
--将文件增长限制为xM(x是你允许的最大数据文件大小)
--SQL语句的设置方式:
alterdatabase 库名 modify file(name=逻辑文件名,maxsize=20)
SQL Server 数据库使用时间一长就会导致Log文件逐渐变的庞大, 想备份一下数据库, 想发给谁都很困难
运行下面的语句就可以 清到Log文件只剩下1M左右的空间.
DUMP TRANSACTION 数据库名 WITH NO_LOG
DBCC SHRINKDATABASE('数据库名',TRUNCATEONLY)
不重启SQL服务，删除SQLServer系统日志
SQLServer的系统日志过大，就会引起SQLServer服务器无法启动等一系列问题。今天我遇到了这个问题，在网上搜索了一下，解决方法是删除就 可以了，可是当前的ErrorLog正在被SQL使用无法删除啊，要删除只能停止SQL服务器，难道就没有别得办法了吗？
回答是肯定的：使用以下存储过程：EXEC sp_cycle_errorlog
注释
每次启动 SQL Server时，当前错误日志重新命名为 errorlog.1；errorlog.1 成为 errorlog.2，errorlog.2 成为 errorlog.3，依次类推。sp_cycle_errorlog 使您得以循环错误日志文件，而不必停止而后再启动服务器。
Ⅶ SQL不小心删除日志文后如何恢复SQLSERVER服务
如果你之前的日志文件没有删除，把服务停止，把原来的日志文件拷贝回来然后重启服务。
Ⅷ SQL Server服务启动后自动停止了，并没有报错，查看日志后以下内容，请问该如何恢复
解决方法：
a. 我的电脑--控制面板--管理工具--服务--右键 MSSQLSERVER--属性--登陆--登陆身份--选择"本地系统帐户"。
或:
b.我的电脑--控制面板--管理工具--服务--右键 MSSQLSERVER--属性--登陆--登陆身份--选择"此帐户"--选择 administrator ，密码和确认密码中输入你的administrator密码。
Ⅸ 如何查看sqlserver的启动/停止日志
您好，很高兴为您解答。
缺省情况下，在Program FilesMicrosoft SQL ServerMSSQLLog目录下。最近的错误日志名称是ERRORLOG,如果停止并重启SQL Server，旧的日志将被压缩和新建一个文件。此外，也可以通过DBCC ERRORLOG 命令或者sp_cycle_errorlog 系统存储过程回收错误日志。
[@more@]
以下是一些没有写在文档中但是众所周知的系统存储过程，这些存储过程可以从SQL Server自身读取错误日志。
exec xp_enumerrorlogs 1 will list SQL Engine errorlog file numbers
exec xp_readerrorlog <errorlognumber>, 1 will return the content of the requested Engine errorlog file.
exec xp_enumerrorlogs 2 will list the Agent error log file numbers
exec xp_readerrorlog <errorlognumber>, 2 will return the content of the requested Agent error log file.
举例：
exec xp_enumerrorlogs 2
存档# 日期 日志文件大小(字节)
1 08/06/2012 10:52 11399188
2 07/13/2012 00:58 1048
3 07/13/2012 00:55 1048
4 07/13/2012 00:55 12682508
5 06/16/2012 09:53 12869230
6 05/20/2012 05:38 10492
7 05/20/2012 05:25 11766
8 05/20/2012 05:08 10012278
9 04/29/2012 00:41 15371150
0 08/08/2012 11:30 939606
exec xp_readerrorlog 1, 2
时间 错误级别 内容
2012-07-13 01:07:03.0 3 [393] 正在等待 SQL Server 恢复数据库...
2012-07-13 01:18:29.0 3 [100] Microsoft SQLServerAgent 版本 9.00.1399.06 (内部版本号 x86 unicode 零售): 进程 ID 1996
2012-07-13 01:18:29.0 3 [101] SQL Server SVCTAG-4GCYY2X 版本 9.00.1399 (连接限制: 0)
2012-07-13 01:18:29.0 3 [102] SQL Server ODBC 驱动程序版本 9.00.1399
2012-07-13 01:18:29.0 3 [103] 驱动程序使用的 NetLib 是 DBNETLIB.DLL；本地主机服务器是
2012-07-13 01:18:29.0 3 [310] 检测到 8 个处理器和 4096 MB RAM
2012-07-13 01:18:29.0 3 [339] 本地计算机是 SVCTAG-4GCYY2X，运行的是 Windows NT 5.2 (3790) Service Pack 2
2012-07-13 01:18:29.0 3 [431] 正在填充子系统缓存...
2012-07-13 01:18:36.0 3 [432] 子系统缓存中有 11 个子系统
2012-07-13 01:18:36.0 3 [124] 已成功加载子系统“TSQL”(最大并发数: 160)
2012-07-13 01:18:37.0 3 [124] 已成功加载子系统“ActiveScripting”(最大并发数: 80)
2012-07-13 01:18:37.0 3 [124] 已成功加载子系统“CmdExec”(最大并发数: 80)
2012-07-13 01:18:38.0 3 [124] 已成功加载子系统“Snapshot”(最大并发数: 800)
2012-07-13 01:18:38.0 3 [124] 已成功加载子系统“LogReader”(最大并发数: 200)
~ O(∩_∩)O~