如何在MySql中记录SQL日志记录

查了一下资料，My SQL可以用下面方法跟踪sql 语句，以下方法以Windows平台为例，linux雷同：

1 配置myini文件（在安装目录,linux下文件名为mycnf

查找到[mysqld]区段，增加日志的配置，如下示例：[mysqld]log=C:/temp/mysqllog

log_slow_queries=C:/temp/mysql_slowlog

long_query_time=1

log指示日志文件存放目录；

log_slow_queries指示记录执行时间长的sql日志目录；

long_query_time指示多长时间算是执行时间长，单位s。

Linux下这些配置项应该已经存在，只是被注释掉了，可以去掉注释。但直接添加配置项也OK啦。

2 重新启动mysql服务。注意事项：A日志存放目录必须提前存在，否则不能记录日志。这里也局势C:/temp目录必须已经存在

B 日志文件是linux格式的文本，建议用ultraEdit打开，转换为dos格式查看（否则没有换行，看不懂的）

C 服务在启动状态下不能删除日志文件，否则就无法记录sql语句了。

D 不能用ultraEdit直接清除文件内容后保存，否则也记录不下来了。需要重启服务，如果ultraEdit保存了bak，后记录到此文件中。

E 可以用notepad清除文本后保存，可以继续记录日志。

在实际操作中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’,1reconfigure with overrideGo 接着运行以下语句，把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’,0Go 如果没有什么大的问题，刷新一下数据库，数据库AAA又会出现在你面前，但目前恢复工作还没有做完，此时的数据库仍不能工作，还要进行下面的处理，才能真正恢复。 ④利用DTS的导入导出向导，把数据库AAA导入到一个新建数据库BBB中 新建一个数据库BBB; 右击BBB，选择IMPORT功能，打开导入向导; 目标源选择"在SQL Server数据库之间复制对象和数据库"，这样可以把表结构，数据视图和存储过程导入到BBB中 再用此功能把BBB库替换成原来的AAA库即可。 到此为止，数据库AAA就完全恢复。 SQLServer日志文件丢失是一件非常危险的事情，很有可能你的数据库彻底毁坏。SQL Server数据库的恢复都是靠日志文件来完成，所以无论如何都要保证日志文件的存在，它至关重要。为了使我们的数据库万无一失，最好采用多种备份方式相结合，所以我们要从心里重视数据库的管理与维护工作。

简单查看：企业管理器－>管理－>SQL Server日志

或用Log Explorer for SQL Server

下载地址：http://wwatera365net/SoftViewaspSoftID=5745

－intel文件里面安装－

打开log explorer file=>attach log file->选择服务器和登陆方式->connect->

选择数据库->attach->左面对话框中browse->view log->就可以看到log记录了

一、删除LOG

1分离数据库 企业管理器－＞服务器－＞数据库－＞右键－＞分离数据库

2删除LOG文件

3附加数据库 企业管理器－＞服务器－＞数据库－＞右键－＞附加数据库

此法生成新的LOG，大小只有500多K

再将此数据库设置自动收缩

或用代码：

下面的示例分离 pubs，然后将 pubs 中的一个文件附加到当前服务器。

EXEC sp_detach_db @dbname = 'pubs '

EXEC sp_attach_single_file_db @dbname = 'pubs ',

@physname = 'c:\Program Files\Microsoft SQL Server\MSSQL\Data\pubsmdf '

二、清空日志

DUMP TRANSACTION 库名 WITH NO_LOG

再：

企业管理器--右键你要压缩的数据库--所有任务--收缩数据库--收缩文件--选择日志文件--在收缩方式里选择收缩至XXM,这里会给出一个允许收缩到的最小M数,直接输入这个数,确定就可以了

三、如果想以后不让它增长

企业管理器－＞服务器－＞数据库－＞属性－＞事务日志－＞将文件增长限制为2M

sql server数据库使用时间长了，日志文件会很大，占用过多系统资源，数据库可能会报 log full 的错误，甚至磁盘空间占满让数据库处于不可用状态，这个时候我们需要清理数据库：

清理sql server数据库日志可用两种方法：

方法一：清空日志。

1、打开查询分析器，输入命令DUMP TRANSACTION 数据库名 WITH NO_LOG

2、再打开企业管理器--右键你要压缩的数据库--所有任务--收缩数据库--收缩文件--选择日志文件--在收缩方式里选择收缩至: ,这里会给出一个允许收缩到的最小M数,直接输入这个数,确定就可以了。

方法二：有一定的风险性，因为SQL SERVER的日志文件不是即时写入数据库主文件的，如处理不当，会造成数据的损失。

1、删除LOG

分离数据库 企业管理器－＞服务器－＞数据库－＞右键－＞分离数据库

2、删除LOG文件

附加数据库 企业管理器－＞服务器－＞数据库－＞右键－＞附加数据库

此法生成新的LOG，大小只有500多K。

注意：建议使用第一种方法。

如果以后，不想要它变大。

SQL2000下使用：

在数据库上点右键->属性->选项->故障恢复-模型-选择-简单模型。

或用SQL语句：alter database 数据库名 set recovery simple

另外，数据库属性有两个选项，与事务日志的增长有关：

Truncate log on checkpoint

(此选项用于SQL70，SQL 2000中即故障恢复模型选择为简单模型)

当执行CHECKPOINT 命令时如果事务日志文件超过其大小的70% 则将其内容清除在开发数据库时时常将此选项设置为True

定期对数据库进行检查当数据库文件或日志文件的未用空间超过其大小的25%时，系统将会自动缩减文件使其未用空间等于25% 当文件大小没有超过其建立时的初始大小时不会缩减文件缩减后的文件也必须大于或等于其初始大小对事务日志文件的缩减只有在对其作备份时或将Truncate log on checkpoint 选项设为True 时才能进行。

注意：一般立成建立的数据库默认属性已设好，但碰到意外情况使数据库属性被更改，请用户清空日志后，检查数据库的以上属性，以防事务日志再次充满。

方法1：

第一步：

backup

log

database_name

with

no_log

或者

backup

log

database_name

with

truncate_only

--no_log和truncate_only是在这里是同义的，随便执行哪一句都可以

第二步：

1收缩特定数据库的所有数据和日志文件，执行

dbcc

shrinkdatabase

(database_name,[,target_percent])--database_name是要收缩的数据库名称；target_percent是数据库收缩后的数据库文件中所要的剩余可用空间百分比

2收缩一次一个特定数据库中的数据或日志文件，执行

dbcc

shrinkfile(file_id,[,target_size])

--file_id是要收缩的文件的标识

(id)

号,若要获得文件

id，请使用

file_id

函数或在当前数据库中搜索

sysfiles；target_size是用兆字节表示的所要的文件大小（用整数表示）。如果没有指定，dbcc

shrinkfile

将文件大小减少到默认文件大小

两个dbcc都可以带上参数notruncate或truncateonly，具体意思看帮助。

方法2

（这个方法在sqlserver2000的环境下做一般能成功，在sqlserver7及以下版本就不一定了）：

第一步：

先备份整个数据库以备不测

第二步：

备份结束后，在query

analyzer中执行如下的语句：

exec

sp_detach_db

yourdbname,true

--卸除这个db在mssql中的注册信息

第三步：

到日志的物理文件所在的目录中去删除该日志文件或者将该日志文件移出该目录

第四步：

在query

analyzer中执行如下的语句：

exec

sp_attach_single_file_db

yourdbname,'d:\mssql7\data\yourdbname_datamdf'

--以单文件的方式注册该db，如果成功则mssql将自动为这个db生成一个500k的日志文件。

以上方法在清除log日志中均有效。

但，能否让sql

server

不产生log日志呢？以上方法好像均无效。

我这儿正好有个case：

我客户的sql

server每天都会产生4，500m的log日志，每天都清除一下，非常不便。有没有办法实现不产生log日志呢？

我分析了一下客户产生log日志的原因，并且做了相应测试。

客户是每天将数据库清空，从总系统中将数据导入到sql

server里。我感决sqlserver在插入时产生log不大，在delete整个库时产生log极大。

比如：

select

into

test_2

from

b_bgxx

共45000条记录，产生十几m

log，如果

delete

from

test_2

产生80多m

log

，这明显存在问题。

虽然可以换成：

truncate

table

test_2

但我还是希望能找到不产生log的方法。就如oracle不产生归档一样。