SQL SERVER 2000数据库日志文件过大如何解决

SQL SERVER 2000数据库日志文件过大如何解决,第1张

守得云开见月明,花了一个上午结合前辈的博客,终于弄好了sqlserver2008的数据库日志收缩到1MB,分享给大家# 方法步骤1、执行SQL语句改成“简单模式”2、收缩数据库3、执行SQL语句改回“完全模式”## 第一步:执行SQL语句改成“简单模式”USE [master]GOALTER DATABASE  SlowXWebDB (改成你需要进行收缩的数据库名) SET RECOVERY SIMPLE WITH NO_WAITGOALTER DATABASE SlowXWebDB (改成你需要进行收缩的数据库名) SET RECOVERY SIMPLE --改成简单模式GO## 第二步:进行数据库 *** 作相关界面截图和 *** 作假定:数据库名:SlowXWebDB 日志文件名:SlowXWebDB_Log

数据库日志文件过大需要清理1选择数据库右键点击任务-收缩-文件   注意:文件类型选为日志

2如下图选择需要收缩的大小,最小为0MB,本人实测最小只能到1MB,不过已经很满足了哈哈

3点击确认,几十G的日志文件,嗖的一下就瘦身完成了看下数据库日志文件清理后的效果!

## 第三步:执行SQL语句改成“完全模式”USE [master]GOALTER DATABASE SlowXWebDB (改成你需要进行收缩的数据库名)SET RECOVERY FULL WITH NO_WAITGOALTER DATABASE datebaseName(改成你需要进行收缩的数据库名)SET RECOVERY FULL --还原为完全模式GO==最后不要忘记实测下数据库是否能够正常使用==

事物日志文件:存放恢复数据所需的所有信息。

是数据库中已发生的所有修改和执行每次修改的事务的一连串记录。当数据库损坏时,管理员使用事务日志还原数据库。

每一个数据库至少必须拥有一个事务日志文件,允许拥有多个日志文件。

查看sql数据库 *** 作日志的方法步骤:

1、用windows身份验证登陆数据库,点击连接;

2、展开数据库服务器下面的管理SQL Server日志;

3、双击当前可以打开日志文件查看器里面有所有的运行日志;

4、点击任意一行,可以看见具体的信息,错误原因和时间;

四 如何利用LogMiner分析Oracle 的日志文件 虽然说LogMiner是Oracle i才推出来 但我们同样可以用它来分析Oracle 的日志文件 只不过稍微麻烦了一点 并且有一定的限制 下面是具体做法 我们首先复制Oracle i的$ORACLE_HOME/rdbms/admin/dbmslmd sql脚本到Oracle 数据库所在主机的同样目录 这个脚本用于创建dbms_logmnr_d包(注意 Oracle i中还将创建dbms_logmnr包) 如果是 脚本名字为dbmslogmnrd sql 然后在Oracle 的数据库上运行这个脚本 之后使用dbms_logmnr_d build过程创建字典信息文件 现在我们就可以把Oracle 的归档日志连同这个字典信息文件复制到Oracle i数据库所在的主机上 之后在Oracle i数据库中从上面分析过程的第三步开始分析Oracle 的日志 不过 dbms_logmnr start_logmnr()中使用的是Oracle 的字典信息文件 按照我前面所说的那样 如果不是字典文件 我们则可以直接将Oracle 的归档日志复制到Oracle i数据库所在主机 然后对它进行分析 其实这里涉及到了一个跨平台使用LogMiner的问题 笔者做过试验 也可以在Oracle i中来分析Oracle i的日志 但这些都是有所限制的 主要表现在 LogMiner所使用的字典文件必须和所分析的日志文件是同一个数据库所产生的 并且该数据库的字符集应和执行LogMiner数据库的相同 这很好理解 如果不是同一个数据库所产生就不存在对应关系了 生成日志的数据库硬件平台和执行LogMiner数据库的硬件平台要求一致 *** 作系统版本可以不一致 笔者做试验时(如果读者有兴趣可以到我网站上下载试验全过程 因为太长就不放在这里了) 所用的两个数据库 *** 作系统都是Tru UNIX 但一个是 V A 另一个则是V F 如果 *** 作系统不一致则会出现下面的错误 ORA : file /data /cyx/logmnr/arch_ _ arc cannot be openedORA : cannot open archived log /data /cyx/logmnr/arch_ _ arc ORA : skgfifi: file header information is invalidORA : at SYS DBMS_LOGMNR line ORA : at line 五 分析v$logmnr_contents 前面我们已经知道了LogMiner的分析结果是放在v$logmnr_contents中 这里面有很多信息 我们可以根据需要追踪我们感兴趣的信息 那么我们通常感兴趣的有哪些呢? 追踪数据库结构变化情况 即DDL *** 作 如前所述 这个只有Oracle i才支持 SQL> select timestamp sql_redo from v$logmnr_contents where upper(sql_redo) like %CREATE% ;TIMESTAMP SQL_REDO : : create table t (c number); 追踪用户误 *** 作或恶意 *** 作 例如我们现实中有这样需求 有一次我们发现一位员工通过程序修改了业务数据库信息 把部分电话的收费类型改成免费了 现在就要求我们从数据库中查出到底是谁干的这件事?怎么查?LogMiner提供了我们分析日志文件的手段 其中v$logmnr_contents的SESSION_INFO列包含了下面的信息 login_username=NEW_ client_info= OS_username=oracle Machine_name=phoenix OS_terminal=ttyp OS_process_id= OS_program name=sqlplus@phoenix (TNS V V ) 虽然其中信息已经很多了 但在我们的业务数据库中 程序是通过相同的login_username登录数据库的 这样单从上面的信息是很难判断的 不过我们注意到 因为公司应用服务器不是每个人都有权限在上面写程序的 一般恶意程序都是直接通过他自己的PC连到数据库的 这就需要一个准确的定位 IP追踪是我们首先想到的 并且也满足我们的实际要求 因为公司内部IP地址分配是统一管理的 能追踪到IP地址我们就可以准确定位了 但从面的SESSION_INFO中我们并不能直接看到IP 不过我们还是有办法的 因为这个SESSION_INFO里面的内容其实是日志从V$SESSION视图里提取的 我们可以在生产数据库中创建一个追踪客户端IP地址的触发器 create or replace trigger on_logon_triggerafter logon on databasebegin dbms_application_info set_client_info(sys_context( userenv ip_address ));end;/现在 我们就可以在V$SESSION视图的CLIENT_INFO列中看到新登录的客户端IP地址了 那么上面的提出的问题就可以迎刃而解了 假如被更新的表名为HMLX 我们就可以通过下面的SQL来找到所需信息 SQL > select session_info sql_redo from v$logmnr_contents where upper(operation) = UPDATEand upper(sql_redo) like %HMLX% /SESSION_INFO SQL_REDO login_username=C client_info= OS_username=sz xjs chengyx Machine_name=GDTEL\SZ XJS CHENGYXupdate C HMLX set NAME = free where NAME = and ROWID = AAABhTAAFAAABRaAAE ; lishixinzhi/Article/program/Oracle/201311/17810

1设计一张日志表 字段包含 lid(编号)luser( *** 作者)ldate( *** 作时间)lcontext( *** 作描述)2编写一个类Log,里面有添加日志的静态方法(就是写插入一条记录到日志表),以后想添加一条日志的时候就直接调用该方法3使用,例如现在刚刚添加了一新人员的信息,那么可以调用Log类的静态方法插入一条日志。4查看日志,可以把查看日志的方法写在Log类里面,或者单独写都行。 日志的查询就是对日志表的查询,可以实现多种查询方式,例如按时间,按 *** 作者,按内容模糊查找等。 这种方法以前做过几次了,看是不是你想要的。

以上就是关于SQL SERVER 2000数据库日志文件过大如何解决全部的内容,包括:SQL SERVER 2000数据库日志文件过大如何解决、数据库事务日志定义、如何查看数据库日志等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/sjk/10074948.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-05-05
下一篇 2023-05-05

发表评论

登录后才能评论

评论列表(0条)

保存