怎么查看mysql日志

mysql有好几种日志，通常日志，查询缓慢日志，错误日志，默认只有错误日志是开启的，通常日志如果开启会消耗大量系统资源，而且查看也是非常不容易。如果想看哪里出错的话，查询错误日志就可以。通常会在data文件夹下面,服务器名称err就是日志

数据库的安全涉及到各方面，数据的丢失或者篡改将会带来无法估量的损失，所以数据库的安全尤为重要，我们可以通过数据库的日志来分析数据库的安全性，然会针对分析结果采取相应的措施。

db2diag命令，是用来查看db2数据库运行日志信息的，实际上，db2运行日志是记录在db2diaglog文件中，可以 通过此文件，查看记录的有关DB2数据库详细的错误信息，而db2diag只是查看该日志文件的一个小工具而已。db2数据库在运行过程中如果经常有报错的话，这个文件增长的会很快，需要定期清理，备份移走或者删除，通常有两种方法：

可以通过执行db2 get dbm cfg 来查看Diagnostic data directory path(DIAGPATH) 参数的设置。

1、使用db2diag工具，直接执行命令db2diag -A /db2diagbak (备份至/db2diagbak ,使用db2diag -h查看db2diag帮助)，系统会自动移走db2diaglog并将备份的文件名添加上当前日期时间信息。

2、直接备份，在db2停止运行的情况下，将db2diaglog文件备份至其他文件系统，该文件删除后在db2启动后会自动重建。

在SQL Server 70和SQL Server2000中，可以用下面的命令查看：

DBCC log ( {dbid|dbname}, [, type={0|1|2|3|4}] )

参数:

Dbid or dbname - 任一数据库的ID或名字

type - 输出结果的类型:

0 - 最少信息(operation, context, transaction id)

1 - 更多信息(plus flags, tags, row length)

2 - 非常详细的信息(plus object name, index name,page id, slot id)

3 - 每种 *** 作的全部信息

4 - 每种 *** 作的全部信息加上该事务的16进制信息

默认 type = 0

要查看MSATER数据库的事务日志可以用以下命令：

DBCC log (master)

释放日志空间

1清空日志

　 DUMP TRANSACTION 库名 WITH NO_LOG

2截断事务日志：

　 BACKUP LOG 数据库名 WITH NO_LOG

3收缩数据库文件(如果不压缩,数据库的文件不会减小

　 企业管理器--右键你要压缩的数据库--所有任务--收缩数据库--收缩文件

　 --选择日志文件--在收缩方式里选择收缩至XXM,这里会给出一个允许收缩到的最小M数,直接输入这个数,确定就可以了

　 --选择数据文件--在收缩方式里选择收缩至XXM,这里会给出一个允许收缩到的最小M数,直接输入这个数,确定就可以了

　 也可以用SQL语句来完成

　 --收缩数据库

　 DBCC SHRINKDATABASE(客户资料)

　 --收缩指定数据文件,1是文件号,可以通过这个语句查询到:select from sysfiles

　 DBCC SHRINKFILE(1)

4为了最大化的缩小日志文件(如果是sql 70,这步只能在查询分析器中进行)

　 a分离数据库:

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

　 b在我的电脑中删除LOG文件

　 c附加数据库:

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

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

　 或用代码：

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

　 a分离

　 E X E C sp_detach_db @dbname = 'pubs'

　 b删除日志文件

　 c再附加

　 E X E C sp_attach_single_file_db @dbname = 'pubs',

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

5为了以后能自动收缩,做如下设置:

　 企业管理器--服务器--右键数据库--属性--选项--选择"自动收缩"

　 --SQL语句设置方式:

　 E X E C sp_dboption '数据库名', 'autoshrink', 'TRUE'

6如果想以后不让它日志增长得太大

　 企业管理器--服务器--右键数据库--属性--事务日志

　 --将文件增长限制为xM(x是你允许的最大数据文件大小)

　 --SQL语句的设置方式:

　 alter database 数据库名 modify file(name=逻辑文件名,maxsize=20)

特别注意：

　 请按步骤进行,未进行前面的步骤,请不要做后面的步骤

　 否则可能损坏数据库

　 一般不建议做第4,6两步

　 第4步不安全,有可能损坏数据库或丢失数据

　 第6步如果日志达到上限,则以后的数据库处理会失败,在清理日志后才能恢复

另外提供一种更简单的方法，建议大家使用。

更简单的方法：

1。右建数据库属性窗口--故障还原模型--设为简单

2。右建数据库所有任务--收缩数据库

3。右建数据库属性窗口--故障还原模型--设为大容量日志记录

其实这说起来还是满复杂的```你这要是看不懂的话``我看你就叫些专业人士来搞吧```你这问题我是按下面漫漫试,试好的 连接到 SQL Server 的实例时收到错误消息：“Cannot open user default database”（无法打开用户默认数据库） 全文原因 用户默认数据库在连接时不可用。这可能是因为该数据库： 处于可疑模式。 不再存在。 处于单用户模式，并且唯一可用的连接已由其他用户或事物使用。 已被分离。 已设置为 RESTRICTED_USER 状态。 处于脱机状态。 设置为紧急状态。 不具有映射到用户的登录帐户，或者该用户已被拒绝访问。 此外，该登录帐户可能是多个组的成员，且其中一个组的默认数据库在连接时不可用。 SQL Server 2005 在 SQL Server 2005 中，可以使用 sqlcmd 实用程序更改默认数据库。为此，请按照下列步骤 *** 作： 1 单击“开始”，单击“运行”，键入 cmd，然后按 Enter。 2 根据 SQL Server 登录使用的身份验证种类，请使用以下方法之一： 如果 SQL Server 登录使用 Microsoft Windows 身份验证连接到该实例，请在命令提示符处键入以下内容，然后按 Enter： sqlcmd –E -S InstanceName –d master 如果 SQL Server 登录使用 SQL Server 身份验证连接到该实例，请在命令提示符处键入以下内容，然后按 Enter： sqlcmd -S InstanceName -d master -U SQLLogin -P Password 注意：InstanceName 是要连接到的 SQL Server 2005 实例的名称的占位符。SQLLogin 是已删除其默认数据库的 SQL Server 登录的占位符。Password 是 SQL Server 登录密码的占位符。 3 在 sqlcmd 提示符处，键入以下内容，然后按 Enter： Alter LOGIN SQLLogin WITH DEFAULT_DATABASE = AvailDBName 注意：AvailDBName 是可由实例中 SQL Server 登录访问的现有数据库的名称的占位符。 4 在 sqlcmd 提示符处，键入 GO，然后按 Enter。 SQL Server 2000 和 SQL Server 70 在 SQL Server 2000 和 SQL Server 70 中，可以使用 osql 实用程序更改默认数据库。为此，请按照下列步骤 *** 作： 1 在命令提示符处，键入以下内容，然后按 Enter： C:\>osql -E 2 在“osql”提示符处，键入以下内容，然后按 Enter： 1>sp_defaultdb 'user's_login', 'master' 3 在第二个提示符处，键入以下内容，然后按 Enter： 2>go 更简单明了的： 无法打开用户默认数据库，登录失败,这也是SQL Server使用者熟悉的问题之一。在使用企业管理器、查询分析器、各类工具和应用软件的时候，只要关系到连接SQL Server数据库的时候，都有可能会碰到此问题,引起此错误发生的原因比较多,下面我们就来详细分析引起此问题的原因以及解决办法。 一、原因 登录帐户的默认数据库被删除。 二、解决方法： (1)、使用管理员帐户修改此帐户的默认数据库 1、打开企业管理器,展开服务器组,然后展开服务器 2 展开"安全性",展开登录，右击相应的登录帐户，从d出的菜单中选择，属性 3、重新选择此登录帐户的默认数据库 (2)、若没有其他管理员登录帐户，无法在企业管理器里修改，使用isql命令行工具 isql /U"sa" /P"sa的密码" /d"master" /Q"exec sp_defaultdb N'sa', N'master'" 如果使用Windows验证方式，使用如下命令： isql /E /d"master" /Q"exec sp_defaultdb N'BUILTIN\Administrators', N'master'" 注:上述isql命令可以直接在命令提示符下输入。 第二篇： 无法打开用户默认数据库 登录失败 无法打开用户默认数据库，登录失败,这也是SQL Server使用者熟悉的问题之一。在使用企业管理器、查询分析器、各类工具和应用软件的时候，只要关系到连接SQL Server数据库的时候，都有可能会碰到此问题,引起此错误发生的原因比较多,下面我们就来详细分析引起此问题的原因以及解决办法。 一、原因 登录帐户的默认数据库被删除。 二、解决方法： (一)、使用管理员帐户修改此帐户的默认数据库 1、打开企业管理器,展开服务器组,然后展开服务器 2 展开"安全性",展开登录，右击相应的登录帐户，从d出的菜单中选择，属性 3、重新选择此登录帐户的默认数据库 -- 登录都没法，安全性节点似乎没法打开。 (二)、若没有其他管理员登录帐户，无法在企业管理器里修改，使用isql命令行工具 isql /U"sa" /P"sa的密码" /d"master" /Q"exec sp_defaultdb N'sa', N'master'" 如果使用Windows验证方式，使用如下命令： isql /E /d"master" /Q"exec sp_defaultdb N'BUILTIN\Administrators', N'master'" 参考:微软中文知识库文章：如何解决 SQL Server 2000 中的连接问题 地址： >

四，服务器故障排查方法总结

问题描述：

每当出现网站访问不了的时候，估计应该就是服务器出现故障了，这个时候大部分情况都是属于数据库出现问题。

查找步骤：

1、查找top检查服务器负载是否有问题

一般网站访问不了，top显示的负载都是很大的，这个时候可以看到mysql的进程占用资源很高，往往就是mysql发生故障了

2、在服务器中查看网站的访问记录

这些访问记录存储在：/home/对应的网站名/access-logs/对应的网站名

可以先通过tail查看，查看出异常的ip的时候可以通过grep进行过滤查看，在这个文件一般都可以找到恶意爬虫、恶意访问的记录，这些往往有可能是导致mysql数据库挂掉的原因。

3、这个时候先对数据库进行重启，对apache进行重启

service mysql restart

service >

‍测试环境中出现了一个异常的告警现象：一条告警通过 Thanos Ruler 的 >

分析

下面我们开始分析这个问题。综合第一节的描述，初步的猜想是告警在到达 AlertManager 前的某些阶段的处理过程太长，导致告警到达 AlertManager 后就已经过了自动解决时间。我们从分析平台里一条告警的流转过程入手，找出告警在哪个处理阶段耗时过长。首先，一条告警的产生需要两方面的配合：

metric 数据

告警规则

将 metric 数据输入到告警规则进行计算，如果符合条件则产生告警。DMP 平台集成了 Thanos 的相关组件，数据的提供和计算则会分开，数据还是由 Prometheus Server 提供，而告警规则的计算则交由 Thanos Rule（下文简称 Ruler）处理。下图是 Ruler 组件在集群中所处的位置：

看来，想要弄清楚现告警的产生到 AlertManager 之间的过程，需要先弄清除 Ruler 的大致机制。官方文档对 Ruler 的介绍是：You can think of Rule as a simplified Prometheus that does not require a sidecar and does not scrape and do PromQL evaluation (no QueryAPI)。

不难推测，Ruler 应该是在 Prometheus 上封装了一层，并提供一些额外的功能。通过翻阅资料大致了解，Ruler 使用 Prometheus 提供的库计算告警规则，并提供一些额外的功能。下面是 Ruler 中告警流转过程：

首先，图中每个告警规则 Rule 都有一个 active queue（下面简称本地队列），用来保存一个告警规则下的活跃告警。

其次，从本地队列中取出告警，发送至 AlertManager 前，会被放入 Thanos Rule Queue（下面简称缓冲队列），该缓冲队列有两个属性：

capacity（默认值为 10000）：控制缓冲队列的大小，

maxBatchSize（默认值为 100）：控制单次发送到 AlertManager 的最大告警数

了解了上述过程，再通过翻阅 Ruler 源码发现，一条告警在放入缓冲队列前，会为其设置一个默认的自动解决时间（当前时间 + 3m），这里是影响告警自动解决的开始时间，在这以后，有两个阶段可能影响告警的处理：1 缓冲队列阶段2 出缓冲队列到 AlertManager 阶段（网络延迟影响）由于测试环境是局域网环境，并且也没在环境上发现网络相关的问题，我们初步排除第二个阶段的影响，下面我们将注意力放在缓冲队列上。通过相关源码发现，告警在缓冲队列中的处理过程大致如下：如果本地队列中存在一条告警，其上次发送之间距离现在超过了 1m（默认值，可修改），则将该告警放入缓冲队列，并从缓冲队列中推送最多 maxBatchSize 个告警发送至 AlertManager。反之，如果所有本地队列中的告警，在最近 1m 内都有发送过，那么就不会推送缓冲队列中的告警。也就是说，如果在一段时间内，产生了大量重复的告警，缓冲队列的推送频率会下降。队列的生产方太多，消费方太少，该队列中的告警就会产生堆积的现象。因此我们不难猜测，问题原因很可能是是缓冲队列推送频率变低的情况下，单次推送的告警数量太少，导致缓冲队列堆积。下面我们通过两个方面验证上述猜想：首先通过日志可以得到队列在大约 20000s 内推送了大约 2000 次，即平均 10s 推送一次。结合缓冲队列的具体属性，一条存在于队列中的告警大约需要 (capacity/maxBatchSize)10s = 16m，AlertManager 在接收到告警后早已超过了默认的自动解决时间（3m）。其次，Ruler 提供了 3 个 metric 的值来监控缓冲队列的运行情况：

thanos_alert_queue_alerts_dropped_total

thanos_alert_queue_alerts_pushed_total

thanos_alert_queue_alerts_popped_total

通过观察 thanos_alert_queue_alerts_dropped_total 的值，看到存在告警丢失的总数，也能佐证了缓冲队列在某些时刻存在已满的情况。

解决通过以上的分析，我们基本确定了问题的根源：Ruler 组件内置的缓冲队列堆积造成了告警发送的延迟。针对这个问题，我们选择调整队列的 maxBatchSize 值。下面介绍一下这个值如何设置的思路。由于每计算一次告警规则就会尝试推送一次缓冲队列，我们通过估计一个告警数量的最大值，得到 maxBatchSize 可以设置的最小值。假设你的业务系统需要监控的实体数量分别为 x1、x2、x3、、xn，实体上的告警规则数量分别有 y1、y2、y3、、yn，那么一次能产生的告警数量最多是(x1 y2 + x2 y2 + x3 y3 + + xn yn)，最多推送（y1 + y2 + y3 + + yn）次，所以要使缓冲队列不堆积，maxBatchSize 应该满足：maxBatchSize >= (x1 y2 + x2 y2 + x3 y3 + + xn yn) / (y1 + y2 + y3 + + yn)，假设 x = max(x1,x2, ,xn), 将不等式右边适当放大后为 x，即 maxBatchSize 的最小值为 x。也就是说，可以将 maxBatchSize 设置为系统中数量最大的那一类监控实体，对于 DMP 平台，一般来说是 MySQL 实例。

注意事项

上面的计算过程只是提供一个参考思路，如果最终计算出该值过大，很有可能对 AlertManager 造成压力，因而失去缓冲队列的作用，所以还是需要结合实际情况，具体分析。因为 DMP 将 Ruler 集成到了自己的组件中，所以可以比较方便地对这个值进行修改。如果是依照官方文档的介绍使用的 Ruler 组件，那么需要对源码文件进行定制化修改。

‍‍

以上就是关于怎么查看mysql日志全部的内容，包括:怎么查看mysql日志、数据库历史diag.log怎么看、sql server 2008怎么查看日志文件等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！