如何查看db2的数据库的日志文件

如何查看db2的数据库的日志文件,第1张

在日常DB2的维护中,transaction log full是比较常见的问题,日志空间使用情况也是我们比较重视的问题,那么如何查看日志空间使用情况呢?

其实昨天在提到归档设置,我们知道DB2 在DATABASE级别有几个参数,如下决定了事物日志的使用空间大小

Log file size (4KB) (LOGFILSIZ) = 60000

Number of primary log files (LOGPRIMARY) = 16

Number of secondary log files (LOGSECOND) = 200

Changed path to log files (NEWLOGPATH) =

Path to log files = /db2inst1_log01/sample

如此我们可以计算分配给日志的空间大约是(200+16)600004/1024/1024大约50GB。

如果日志是单独的文件系统分区,我们在 *** 作系统上即可看到日志空间使用情况,对日志使用情况进行监控,可以看到如下信息:

$ df -g

Filesystem GB blocks Free %Used Iused %Iused Mounted on

/dev/db2inst1_log01 6000 5450 10% 1458 1% /db2inst1_log01

这个需要登录到系统,其实db2pd也是可以看到日志信息的

db2pd -d sample -logs

Database Partition 0 -- Database SAMPLE -- Active -- Up 34 days 17:30:12 -- Date 2013-11-26-104249558342

Logs:

Current Log Number 117123

Pages Written 33697

Cur Commit Disk Log Reads 0

Cur Commit Total Log Reads 0

Method 1 Archive Status Success

Method 1 Next Log to Archive 117123

Method 1 First Failure n/a

Method 2 Archive Status n/a

Method 2 Next Log to Archive n/a

Method 2 First Failure n/a

Log Chain ID 2

Current LSN 0x00001A2DDE649E70

Address StartLSN State Size Pages Filename

0x0700000177B795D0 00001A2CBFD88010 0x00000000 60000 60000 S0117104LOG

0x0700000177B806D0 00001A2CCE7E8010 0x00000000 60000 60000 S0117105LOG

0x0700000177B8B450 00001A2CDD248010 0x00000000 60000 60000 S0117106LOG

0x0700000177B82EF0 00001A2CEBCA8010 0x00000000 60000 60000 S0117107LOG

0x0700000177B9ECD0 00001A2CFA708010 0x00000000 60000 60000 S0117108LOG

0x0700000177BA27D0 00001A2D09168010 0x00000000 60000 60000 S0117109LOG

0x0700000177B79E30 00001A2D17BC8010 0x00000000 60000 60000 S0117110LOG

0x0700000177BAAD50 00001A2D26628010 0x00000000 60000 60000 S0117111LOG

0x0700000177B9FFD0 00001A2D35088010 0x00000000 60000 60000 S0117112LOG

0x0700000177BB44D0 00001A2D43AE8010 0x00000000 60000 60000 S0117113LOG

0x0700000177BD45D0 00001A2D52548010 0x00000000 60000 60000 S0117114LOG

0x0700000177B7F0D0 00001A2D60FA8010 0x00000000 60000 60000 S0117115LOG

0x0700000177B9C850 00001A2D6FA08010 0x00000000 60000 60000 S0117116LOG

0x0700000177B84750 00001A2D7E468010 0x00000000 60000 60000 S0117117LOG

0x0700000177B877D0 00001A2D8CEC8010 0x00000000 60000 60000 S0117118LOG

0x0700000177B857D0 00001A2D9B928010 0x00000000 60000 60000 S0117119LOG

0x0700000177B7DC50 00001A2DAA388010 0x00000000 60000 60000 S0117120LOG

0x0700000177B83750 00001A2DB8DE8010 0x00000000 60000 60000 S0117121LOG

0x0700000177B907B0 00001A2DC7848010 0x00000000 60000 60000 S0117122LOG

0x0700000177B91010 00001A2DD62A8010 0x00000000 60000 60000 S0117123LOG

0x0700000177B9A150 00001A2DE4D08010 0x00000000 60000 60000 S0117124LOG

不过之只能看到当前使用日志和日志文件对应的LSN信息和归档情况,对于使用率还真不能看到。

另外还可以在实例快照中看到,不过在此不示例了。

但是上面我们需要登录到 *** 作系统上,如何在远端通过SQL查询呢,其实DB2还是提供了蛮多的方法。

a通过管理视图查询:

select DB_NAME, LOG_UTILIZATION_PERCENT, TOTAL_LOG_USED_KB,TOTAL_LOG_AVAILABLE_KB,TOTAL_LOG_USED_TOP_KB, DBPARTITIONNUM from SYSIBMADMLOG_UTILIZATION;

DB_NAME LOG_UTILIZATION_PERCENT TOTAL_LOG_USED_KB TOTAL_LOG_AVAILABLE_KB TOTAL_LOG_USED_TOP_KB DBPARTITIONNUM

-------------------------------------------------------------------------------------------------------------------------------- ----------------------- -------------------- ---------------------- --------------------- --------------

DSS 897 4631824 46955050 16655013 0

非常清楚一目了然吧,对于监控事物日志使用情况,及早发现事务日志空间满问题很有帮助。

b还有一种方法,就是查看快照视图:

select int(total_log_used/1024/1024) as "Log Used (Mb)",int(total_log_available/1024/1024) as "Log Space Free(Mb)",

int((float(total_log_used)/float(total_log_used+total_log_available))100) as "Pct Used",int(tot_log_used_top/1024/1024) as "Max Log Used (Mb)",

int(sec_log_used_top/1024/1024) as "Max Sec Used (Mb)",int(sec_logs_allocated) as "Secondaries" from sysibmadmsnapdb;

Log Used (Mb) Log Space Free(Mb) Pct Used Max Log Used (Mb) Max Sec Used (Mb) Secondaries

------------- ------------------ ----------- ----------------- ------------------ -----------

4544 45833 9 16264 12532 5

1 record(s) selected

其实还有一种通过表函数的方法,不过需要带入参数:

select DB_NAME,TOTAL_LOG_AVAILABLE,TOTAL_LOG_USED,SEC_LOG_USED_TOP,SEC_LOGS_ALLOCATED from table(SNAP_GET_DB('SAMPLE',0))

DB_NAME TOTAL_LOG_AVAILABLE TOTAL_LOG_USED SEC_LOG_USED_TOP SEC_LOGS_ALLOCATED

-------------------------------------------------------------------------------------------------------------------------------- -------------------- -------------------- -------------------- --------------------

SAMPLE 48045192251 4779767749 13141773417 5

1 record(s) selected

看吧,DB2查看日志空间的方法真的很多,不能不说提供了强大的用户接口,就看大家怎么用了。

转载仅供参考,版权属于原作者。祝你愉快,哦

一般是即时备份。做主从。或者是每天增量备份。

本文是在linux下,mysql 4114版本下测试的,经过适当修改可能适合mysql 40,50及其其他版本

本文适合于没有启动复制功能的mysql,如果启动了复制,可能不需要采取这种备份策略或者需要修改相关参数

每个人的备份策略都可能不同,所以请根据实际情况修改,做到举一反三,不要照搬照抄,可能会造成不必要的损失

希望你明白这个脚本要干什么工作!

脚本描述

每7天备份一次所有数据,每天备份binlog,也就是增量备份

(如果数据少,每天备份一次完整数据即可,可能没必要做增量备份)

作者对shell脚本不太熟悉,所以很多地方写的很笨 :)

开启 bin log

在mysql 41版本中,默认只有错误日志,没有其他日志可以通过修改配置打开bin log方法很多,其中一个是在/etc/mycnf中的mysqld部分加入:

[mysqld]

log-bin

这个日志的主要作用是增量备份或者复制(可能还有其他用途)

如果想增量备份,必须打开这个日志

对于数据库 *** 作频繁的mysql,这个日志会变得很大,而且可能会有多个

在数据库中flush-logs,或者使用mysqladmin,mysqldump调用flush-logs后并且使用参数delete-master-logs,这些日志文件会消失,并产生新的日志文件(开始是空的)

所以如果从来不备份,开启日志可能没有必要

完整备份的同时可以调用flush-logs,增量备份之前flush-logs,以便备份最新的数据

完整备份脚本

如果数据库数据比较多,我们一般是几天或者一周备份一次数据,以免影响应用运行,如果数据量比较小,那么一天备份一次也无所谓了

#!/bin/sh

# mysql data backup script

# by scud

# 2005-10-30

#

# use mysqldump --help,get more detail

#

BakDir=/backup/mysql

LogFile=/backup/mysql/mysqlbaklog

DATE=`date +%Y%m%d`

echo " " >> $LogFile

echo " " >> $LogFile

echo "-------------------------------------------" >> $LogFile

echo $(date +"%y-%m-%d %H:%M:%S") >> $LogFile

echo "--------------------------" >> $LogFile

cd $BakDir

DumpFile=$DATEsql

GZDumpFile=$DATEsqltgz

mysqldump --quick --all-databases --flush-logs

--delete-master-logs --lock-all-tables

> $DumpFile

echo "Dump Done" >> $LogFile

tar czvf $GZDumpFile $DumpFile >> $LogFile 2>&1

echo "[$GZDumpFile]Backup Success!" >> $LogFile

rm -f $DumpFile

#delete previous daily backup files:采用增量备份的文件,如果完整备份后,则删除增量备份的文件

cd $BakDir/daily

rm -f

cd $BakDir

echo "Backup Done!"

echo "please Check $BakDir Directory!"

echo "copy it to your local disk or ftp to somewhere !!!"

ls -al $BakDir

上面的脚本把mysql备份到本地的/backup/mysql目录,增量备份的文件放在/backup/mysql/daily目录下

注意:上面的脚本并没有把备份后的文件传送到其他远程计算机,也没有删除几天前的备份文件:需要用户增加相关脚本,或者手动 *** 作

增量备份

增量备份的数据量比较小,但是要在完整备份的基础上 *** 作,用户可以在时间和成本上权衡,选择最有利于自己的方式

增量备份使用bin log,脚本如下:

#!/bin/sh

#

# mysql binlog backup script

#

/usr/bin/mysqladmin flush-logs

DATADIR=/var/lib/mysql

BAKDIR=/backup/mysql/daily

###如果你做了特殊设置,请修改此处或者修改应用此变量的行:缺省取机器名,mysql缺省也是取机器名

HOSTNAME=`uname -n`

cd $DATADIR

FILELIST=`cat $HOSTNAME-binindex`

##计算行数,也就是文件数

COUNTER=0

for file in $FILELIST

do

COUNTER=`expr $COUNTER + 1 `

done

NextNum=0

for file in $FILELIST

do

base=`basename $file`

NextNum=`expr $NextNum + 1`

if [ $NextNum -eq $COUNTER ]

then

echo "skip lastest"

else

dest=$BAKDIR/$base

if(test -e $dest)

then

echo "skip exist $base"

else

echo "copying $base"

cp $base $BAKDIR

fi

fi

done

echo "backup mysql binlog ok"

增量备份脚本是备份前flush-logs,mysql会自动把内存中的日志放到文件里,然后生成一个新的日志文件,所以我们只需要备份前面的几个即可,也就是不备份最后一个

因为从上次备份到本次备份也可能会有多个日志文件生成,所以要检测文件,如果已经备份过,就不用备份了

注:同样,用户也需要自己远程传送,不过不需要删除了,完整备份后程序会自动生成

访问设置

脚本写完了,为了能让脚本运行,还需要设置对应的用户名和密码,mysqladmin和mysqldump都是需要用户名和密码的,当然可以写在脚本中,但是修改起来不太方便,假设我们用系统的root用户来运行此脚本,那么我们需要在/root(也就是root用户的home目录)创建一个mycnf文件,内容如下

[mysqladmin]

password =password

user= root

[mysqldump]

user=root

password=password

注:设置本文件只有root可读(chmod 600 mycnf )

此文件说明程序使用mysql的root用户备份数据,密码是对应的设置这样就不需要在脚本里写用户名和密码了

自动运行

为了让备份程序自动运行,我们需要把它加入crontab

有2种方法,一种是把脚本根据自己的选择放入到/etc/crondaily,/etc/cronweekly这么目录里

一种是使用crontab -e放入到root用户的计划任务里,例如完整备份每周日凌晨3点运行,日常备份每周一-周六凌晨3点运行

其实就是个变量传递的问题,

数据已经被你导入到lsNDBB 中了,这是个成员变量,所以你可以在这个类的其他函数中访问到他,

比如这样:

private void statNDSJ()

{

if(thislsNDBB != null)

{

thislsNDBBSort();

//写库

}

}

以上就是关于如何查看db2的数据库的日志文件全部的内容,包括:如何查看db2的数据库的日志文件、本机运行的MySQL 数据库 如何安全的备份/还原、C#数据统计问题等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!

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

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

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

发表评论

登录后才能评论

评论列表(0条)

保存