windows日志分析教程 系统日志无法打开怎么解决?

[更新]
·
·
分类:互联网
1675 阅读

windows日志分析教程

系统日志无法打开怎么解决?

系统日志无法打开怎么解决?

WINDOWS7和VISTA操作系统在点日志查看器时,会显示“事件日志服务不可用,请验证服务是否在运行”,给我的第一感觉是权限不够。但网上说法芸芸:
我马上就去『服务』里尝试启动Windows Event Log的服务,结果系统又提示
Windows 无法启动 Windows Event Log 服务 (位于 本地计算机上)。
错误 4201: 无法识别传来的实例名是否为有效的 WMI 数据提供程序。
搜索相关的关键字,查看了几个链接之后,果然大多数的人也是不知道是什么原因导致事件查看器启动不能了,但是人多,点子也多,倒是有不少解决办法(或者说是偏方吧)
以下3种方法,我都尝试了,也没解决,最后参照第3种方法但方式不同解决了。
方法1,取得『%SystemRoot%LogFiles』文件夹和『%SystemRoot%System32wbem』文件夹的权限(包括这两个文件夹的所有子文件夹的权限),简单点说,就是使你当前的帐户拥有这两个文件夹以及它们的子文件夹的绝对控制权限。这是最简单的方法,不少老外说,这样一弄,倒是解决了问题。不过对我的系统,没用;
—————————————————————————————————–
方法2,以不带网络的安全模式启动,运行命令行,输入“net stop winmgmt”(不带引号),确认WMI服务停止后,将『%SystemRoot%System32wbem』下的『Repository』文件夹重命名,然后再次转到命令行,输入“winmgmt /resetRepository”(不带引号),重启系统,测试事件查看器是否工作正常。这个方法据说效果最好,很多人靠这个修复了4201错误。很不走运,这个方法对我的系统还是无效;
—————————————————————————————————–
方法3,删除『%SystemRoot%Logs』文件夹和『%SystemRoot% System32LogFiles』文件夹(不用担心删除后造成不好的结果,系统会自动重新建立它们的),不过由于系统正在访问这两个文件夹里的文件,即使你拥有它们的绝对控制权,你也还是无法删除它们的。此时就需要借助MoveFile这个软件了(下载页面:猛击进入),它可以在系统启动的时候对文件、文件夹进行移动、删除等操作,借助一个批处理,搞定。批处理内容如下:
“X:***movefile.exe” “C:WindowsSystem32LogFiles” “”
“X:***movefile.exe” “C:WindowsLogs” “”
仍然不幸,不能解决。
后来发现,第3种方法本来应该删除C:WindowsSystem32LogFiles和C:WindowsLogs文件夹,但实际上没有删除,于是想到了
—————————————————————————————————–
第4种方法:用unlocker强制删除C:WindowsSystem32LogFiles和C:WindowsLogs文件夹。
用 unlocker删除C:WindowsLogs文件夹倒是比较容易,先解锁,然后删除就行了。但删除C:WindowsSystem32 LogFile文件夹时提示不能马上删除,下次启动时才删除,所以重启系统,结果发现重启后删除了文件中的部分内容,整个文件夹的属性中看到创建日期仍然是以前的日期,修改日期倒是今天,于是判断是删除不彻底。
后来想到了,将C:WindowsSystem32LogFile文件夹改名应该可以,所以就用unlocker改名,仍然需要重启系统,重启后发现重命名成功,系统新建立了个C:WindowsSystem32LogFile文件夹。
这时Windows Event Log(事件查看记录服务)已经成功启了。
—————————————————————————————————–
分析:第3、4其实想法是一样的,就是完全删除那两个目录,然后让windows重新建立,不过不知为什么第3方法不成功。也许vista分配权限的问题?这个就没再研究了,怕把系统给整坏了:)。
使用win7的事件查看器的时候提示“显示事件日志服务不可用,请验证服务是否在运行”,无法使用。在服务管理看到Windows event log没有启动,点击启动的时候出现Windows 无法启动 Windows Event Log 服务 (位于 本地计算机上)。
错误 4201: 无法识别传来的实例名是否为有效的 WMI 数据提供程序
解决方法:
下载unlocker软件 删除C:WindowsSystem32LogFilesWMI的RtBackup文件夹,重启系统即可!

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 status32768 where name’MYDB’
然后再把数据库MYDB设置为单用户模式,然后重启SQL Server服务器,并把数据库MYDB设为单用户模式
Sp_dboption MYDB,single user, true