core dump文件的设置

core dump文件的设置
core dump文件的设置

core dump文件的设置

在开发过程中,当一个Linux程序异常退出时,我们可以通过core文件来分析它异常的详细原因。缺省情况下,Linux在程序异常时不产生core文件,要想让程序异常退出时产生core dump文件,需要使用ulimit命令更改coredump的设置:

ulimit -c unlimited

上面的命令表示在程序异常时产生core dump文件,并且不对core dump文件的大小进行限制。

上述设置只是使能了core dump功能,缺省情况下,内核在coredump时所产生的core文件放在与该程序相同的目录中,并且文件名固定为core。很显然,如果有多个程序产生core文件,或者同一个程序多次崩溃,就会重复覆盖同一个core文件。

我们通过修改kernel的参数,可以指定内核所生成的coredump文件的文件名。例如,Easwy使用下面的命令使kernel 生成名字为core.filename.pid格式的core dump文件:

echo 'core.%e.%p' >

/proc/sys/kernel/core_pattern

这样配置后,产生的core文件中将带有崩溃的程序名、以及它的进程ID。上面的%e和%p会被替换成程序文件名以及进程ID。

可以在core_pattern模板中使用变量还很多,见下面的列表:

?%% 单个%字符

?%p 所dump进程的进程ID

?%u 所dump进程的实际用户ID

?%g 所dump进程的实际组ID

?%s 导致本次core dump的信号

?%t core dump的时间 (由1970年1月1日计起的秒数)

?%h 主机名

?%e 程序文件名

如果在上述文件名中包含目录分隔符”/“,那么所生成的core文件将会被放到指定的目录中。

需要说明的是,在内核中还有一个与coredump相关的设置,就是/proc/sys/kernel/core_uses_pid。如果这个文件的内容被配置成1,那么即使core_pattern中没有设置%p,最后生成的core dump文件名仍会加上进程ID。

AIX 里面dump文件系统扩充

在errpt中出现E87EF1BE的dump不够的报错 在errpt中出现 E87EF1BE 0926082807 P O dumpcheck The largest dump device is too small. 信息.断定为存放dump文件的lg_dumplv容量不够.一般推荐的dump device 值大小为sysdumpdev –e 估计值的1.5 倍。 需要扩容.扩容步骤如下: 1.查看lg_dumplv大小的估计值 #sysdumpdev -e 0453-041 Estimated dump size in bytes: 1287651328 即1.2G 2.现在lg_dumplv大小 #lslv lg_dumplv 其中PP SIZE: 256 megabyte(s) PPs: 4 经计算,现在容量为1G.需要扩容0.2G 3.查看lg_dumplv所在的vg的容量是否够用 #lsvg rootvg 其中PP SIZE: 256 megabyte(s) TOTAL PPs: 1092 (279552 megabytes) FREE PPs: 826 (211456 megabytes) 经计算,vg剩余容量为206.5G,因为根盘做了镜像.故,可用剩余容量为103G左右.因pp size为256m,故扩容2pps,即0.5G(其实扩1个pp也可以.2个放心点.) 4.扩容操作 extendlv lg_dumplv 2 5.检查当前lg_dumplv的大小. #lslv lg_dumplv 其中PP SIZE: 256 megabyte(s) PPs: 6 即,现在容量为1.5G. 6.使用dumpcheck命令查看,是否还出现errpt信息

LINUX下安装及配置MYSQL详细过程(自己实践总结)

Red Hat Linux下安装及配置MySQL的详细教程 大致思路如下: 1.下载所需的安装包 (Linux下用wget下载,笔者在window下下载的,用XSHELL命令RZ上传到Linux中) 2.安装MySQL 3.创建新用户并授权 安装及配置的详细步骤如下: 第一步:检测系统版本信息 Linux命令:cat/proc/version Linux version2.6.32-220.el6.i686(mockbuild@https://www.360docs.net/doc/8816571786.html,)(gcc version 4.4.520110214(Red Hat4.4.5-6)(GCC))#1SMP Wed Nov908:02:18EST2011 当前Linux版本为RedHat4.4.5-6(为内核版本) Linux命令:cat/etc/issue Red Hat Enterprise Linux Server release6.2(Santiago) Kernel\r on an\m Linux命令:uname-a或getconf LONG_BIT Linux localhost.localdomain2.6.32-220.el6.i686#1SMP Wed Nov908:02:18EST2011i686 i686i386GNU/Linux 可以看到当前系统为32位的(而64位系统会有x64字符串显示出来)。 第二步:根据Linux系统的环境,下载mysql Community Server 官方下载地址:https://www.360docs.net/doc/8816571786.html,/downloads/mysql/ 可以选择【Linux-Generic】,下载对应的RMP包. 由于当前系统为redhat(64位),所以直接选择Oracle&Red Hat Linux4&5。 Mysql安装包有很多,作用也不同,大多数情况下只需要安装MySQL-Server和MySQL-Client,其它包根据需要安装. 32位的下载下面的两个安装包文件:

了解转储(dump)设备

了解转储(dump)设备 David Tansley, 系统管理员, Ace Europe 2012 年7 月30 日 如果发生意外,IBM AIX? 操作系统会崩溃,此时您可能希望能够自动搜集相关信息。利用转储(dump)设备,可在这些设备上部署核心转储功能,从而准备转移到IBM 支持。 简介 如果由于意外事件导致系统崩溃,则会发生核心转储。事实上,并非总在出现系统崩溃时才发生核心转储。然而,在本文中,假定系统崩溃是由于严重事件或用户强制性动作所引起的。转储包含了达到崩溃时内存的内容。就其本质而言,崩溃总是不期而至,因而当崩溃发生时,系统管理员还是应当事先做好防范措施。能够确定崩溃的发生是否是由系统重启引起,此时在错误日志里存在具有标签为SYSDUMP的条目。 在本演示中,我使用的是AIX 7.1。不过,我所讨论的原理也适用于AIX 5.3 和 6.1。 回页首做好准备 要想防范意外的系统崩溃,需要确保具有转储设备逻辑卷(LV),用于在系统恢复时存放转储。然而,如果转储设备不可用,那么应该指定第二转储设备来存放转储。可能人们并不关心系统崩溃何时发生,因而也对进一步研究转储文件不感兴趣。这完全取决于系统所有者。但是,为保障系统正常运行,在rootvg 中包含主转储设备是很好的做法,也是很有必要的。可为转储设备执行镜像,但是,IBM AIX 支持对此发出警告。这是因为崩溃可能会被执行镜像或同步相关,这会导致转储设备上的镜像无效。在某些情况下,转储文件仅会被复制到镜像转储设备(位于镜像磁盘中)的其中一个副本,当系统重启时,很可能仅恢复转储文件副本一半的内容,最好的做法是,将主转储设备放到一个非镜像的磁盘中,将第二设备放到另一个非镜像磁盘中。然而,对rootvg 转储设备执行镜像比较常见。只要第二转储设备不在分页空间中,或不在磁带设备之类的外部设备中,则它可以位于rootvg 内部,也可位于其外部。 回页首转储设备

MySQL主从复制、搭建、状态检查、中断排查及备库重做 实战手册

美河学习在线https://www.360docs.net/doc/8816571786.html, MySQL主从复制 MySQL主从复制、搭建、状态检查、中断排查及备库重做 本文档主要对MySQL主从复制进行简单的介绍,包括原理简介、搭建步骤、状态检查、同步中断及排查、备库重建。

目录 一、MySQL主从复制概述 (2) 1、主从复制简介 (2) 2、主从复制原理、机制 (2) 3、主从复制原理图 (3) 二、MySQL主从复制搭建 (4) 1、Master端配置部署 (4) 2、Slave端配置部署 (4) 3、建立主从同步 (4) 三、主从复制状态检查及异常处理 (6) 1、主从复制状态检查 (6) 2、IO_thread异常 (7) 3、sql_thread异常 (8) 4、主从复制延迟 (9)

一、MySQL主从复制概述 1、主从复制简介 MySQL主从复制就是将一个MySQL实例(Master)中的数据实时复制到另一个MySQL实例(slave)中,而且这个复制是一个异步复制的过程。 实现整个复制操作主要由三个进程完成的,其中两个进程在Slave(sql_thread和IO_thread),另外一个进程在 Master(IO进程)上。 2、主从复制原理、机制 要实施复制,首先必须打开Master端的binary log(bin-log)功能,否则无法实现。因为整个复制过程实际上就是Slave从Master端获取该日志然后再在自己身上完全顺序的执行日志中所记录的各种操作。 复制的基本过程如下: 1)、Slave上面的IO_thread连接上Master,并请求从指定日志文件的指定位置(或者从最开始的日志)之后的日志内容; 2)、Master接收到来自Slave的IO_thread的请求后,通过负责复制的IO进程根据请求信息读取制定日志指定位置之后的日志信息,返回给Slave 的IO_thread。返回信息中除了日志所包含的信息之外,还包括本次返回的信息已经到Master端的bin-log file的以及bin-log pos; 3)、Slave的IO_thread接收到信息后,将接收到的日志内容依次添加到Slave端的relay-log文件的最末端,并将读取到的Master端的 bin-log的文件名和位置记录到master-info文件中,以便在下一次读取的时候能够清楚的告诉Master“我需要从某个bin-log的哪个位置开始往后的日志内容,请发给我”; 4)、Slave的Sql_thread检测到relay-log中新增加了内容后,会马上解析relay-log 的内容成为在Master端真实执行时候的那些可执行的内容,并在本数据库中执行。

dump文件查看器使用方法

Windbg-分析Windows蓝屏原因利 软件启动点File——Open Crash Dump,如图: 然后找到你的minidump文件夹,dump文件一般是"时间.dmp"如图: 打开后就会自动分析了。分析完后,看最下面,找到3.probably caused by这一行,如图:看,出来了吧那个myfault.sys文件就是罪魁祸首。 再补充点东西,

导入dump文件分析完毕后,不要关闭,在后面输入!analyze -v ,这个命令可以查看dump 文件的详细情况,如图: 对普通用户有用的还有下面一些信息: 第一行DEFAULT_BUCKET_ID: 错误类型,这个懂点编程和操作系统知识的朋友用得上点第三行PROCESS_NAME: XXX.exe 这个是导致错误的进程,查出是什么文件导致的蓝屏后,再看这里就知道是谁调用了错误文件,比如你查出123.sys导致蓝屏,但你查不到123.sys是哪个程序调用的,就可以用这个方法来看看,比如查出了是456.exe,你就可以在机子上或者网上搜索相关信息了。 好了,到这里相信大家已经学会怎么找到导致系统蓝屏的文件了,接下来怎么办呢?上网查资料,把导致蓝屏的那个文件名在网上搜索,基本就知道是什么文件了,一般网上也有相关的解决办法,看看要删除些什么插件、打什么补丁或者重装软件等等。导致问题的不一定是.sys文件也有可能是.dll,这篇文章只能帮你找出导致蓝屏的元凶,具体的解决办法得上网查。如果是查不到什么信息的.sys或者.dll就要当心了,有可能是病毒或者rootkit 附: windbg基本调试命令: r 可以显示系统崩溃时的寄存器,和最后的命令状态。 dd 显示当前内存地址,dd 参数:显示参数处的内存。 u 可以显示反汇编的指令 !analyze -v 显示分析的详细信息。 kb 显示call stack 内容 .bugcheck 可以显示出错的代码 windbg诊断蓝屏的一点补充

AIX的Dump文件学习笔记(原创)

AIX的Dump文件学习笔记(原创) DUMP文件概述 为了增强故障分析能力,IBM的服务器增加了对设备故障当前环境的保存功能,就是保存一份设备故障时的内存、CPU寄存器、IO等设备的数据和状态信息,如果系统并没有停住,只是某个程序死掉,会产生CORE DUMP,在当前目录下产生一个CORE文件。而如果操作系统死掉,则产生System DUMP或者System Crash,通常会引起系统停机。DUMP的记录如下图所示。 作为一般客户通常只需要收集DUMP信息,并反馈给IBM工程师即可。当发生系统DUMP时,机器将会被宕下来。可能的原因包括:系统在进行内核操作时发生了未知的意外或者不能对其进行正常处理,都会引起DUMP。也可以由系统管理员发出命令,强制系统DUMP。 当系统进行DUMP时,DUMP管理设施自动将内核相关的数据(kernel segment0及其他由内核或者内核扩展程序记录在主DUMP表中的内存块)复制到主DUMP设备。可以把DUMP理解为系统当时的一个快照,供以后分析,分析DUMP可以在其他机器上进行,但需要复制一份此机器的内核程序,即unix_mp或unix_mp64.没有对应于DUMP的内核程序是午饭进行DUMP分析的。 DUMP的生成过程 CORE DUMP的生成过程 在进程运行出现异常行为时,例如无效地址访问、浮点异常、指令异常等,将导致系统转入内核态进行异常处理(即中断处理),向相应的进程发出特定信号例如SIGSEGV、SIGFPE、SIGILL 等。如果应用进程注册了相应信号的处理函数(例如可通过sigaction 注册信号处理函数),则调用相应处理函数进行处理(应用程序可以选择记录信息后生成core dump 并退出);否则将采取默认动作,例如SIGSEGV 的默认动作是生成core dump 并退出程序。 进程coredump 的时候,操作系统会将进程终止并释放其占用的资源,正常情况下,应用进程coredump 不会对系统本身的运行造成危害。当然如果系统中存在与此进程相关的其他进程,则这些进程会受到影响,至于后果则视其对此异常的具体处理而定。 由于相关指令已经包含在可执行文件中,core 文件一般只包含进程异常时相关的内存信息。其格式可参考/usr/include/sys/core.h 或者AIX 帮助文档的“Files Reference”章节。我们一般需要结合core 文件以及可执行程序,来分析问题所在 注:由于进程信号处理本质上是异步的,应用进程注册的信号处理函数中使用的例程需要保证是异步信号安全的,例如不能使用诸如pthread_ 开头的例程。 系统dump 生成过程 系统异常dump 的具体过程与应用进程类似,但由于更接近底层,为了避免问题所在的资源(例如文件系统)正好包含在生成dump 需要使用的资源中,造成dump 无法生成,操作系统一般会用最简单的方式来生成dump。例如系统内存小于4G 的情况下,一般直接将dump 生成在pagingspace 中;大于4G 时,会建专门的lg_dumplv 逻辑卷(裸设备),默认的dump设备/dev/hd6,次设备是/dev/sysdumpnull 保存dump 信息。在系统重启的时候,如果设置的DUMP 转存目录(文件系统中的目录)有足够空间,它将会转存成一个文件系统文件,缺省情况下,是/var/adm/ras/ 下的vmcore* 这样的文件。 下面是常见的转储设备大小规则 当服务器的内存大于4GB时,在安装AIX时,就会为系统dump 创建一专用区域,该逻辑卷名就是lg_dumplv. 其缺省大小是按以下规则分配的: 4GB < = 服务器的内存〈12GB lg_dump 的大小为1GB 12GB < = 服务器的内存〈24GB lg_dump 的大小为2GB 24GB < = 服务器的内存〈48GB lg_dump 的大小为3GB 48GB < = 服务器的内存lg_dump 的大小为4GB 系统dump 一般可以通过升级微码、提高系统补丁级别、升级驱动等方式解决。

MySQL备份与恢复(PDF版)

下面文章摘录的主题:mysql日志文件,使用mysqld加相应选项来启用某种日志。Mysql 完全备份及恢复:mysqldump对MyISAM或InnoDB完全备份,mysqlhotcopy对MyISAM完全备份。增量备份:使用二进制日志增量备份,使用mysqlbinlog命令恢复二进制日志。 SQL语法备份及恢复。拷贝数据文件备份(对Innodb还需拷贝日志文件)。MyISAM表的检查与修复(另见《MySql存储引擎》)。Innodb表的碎片整理和模糊检查点。 MySQL备份和恢复 作/译者:叶金荣 本文讨论MySQL的备份和恢复机制,以及如何维护数据表,包括最主要的两种表类型:MyISAM和Innodb,文中设计的MySQL版本为 5.0.22。 目前MySQL支持的免费备份工具有:mysqldump、mysqlhotcopy,还可以用SQL语法进行备份:BACKUP TABLE或者SELECT INTO OUTFILE,又或者备份二进制日志(binlog),还可以是直接拷贝数据文件和相关的配置文件。MyISAM表是保存成文件的形式,因此相对比较容易备份,上面提到的几种方法都可以使用。Innodb所有的表都保存在同一个数据文件ibdata1中(也可能是多个文件,或者是独立的表空间文件),相对来说比较不好备份,免费的方案可以是拷贝数据文件、备份binlog,或者用mysqldump。 1、mysqldump 1.1备份 mysqldump是采用SQL级别的备份机制,它将数据表导成SQL脚本文件,在不同的MySQL版本之间升级时相对比较合适,这也是最常用的备份方法。 现在来讲一下mysqldump的一些主要参数: 1.--compatible=name 它告诉mysqldump,导出的数据将和哪种数据库或哪个旧版本的MySQL服务器相兼容。值可以为ansi、mysql323、mysql40、postgresql、oracle、mssql、db2、maxdb、no_key_options、no_tables_options、no_field_options等,要使用几个值,用逗号将它们隔开。当然了,它并不保证能完全兼容,而是尽量兼容。 2.--complete-insert,-c 导出的数据采用包含字段名的完整INSERT方式,也就是把所有的值都写在一行。这么做能提高插入效率,但是可能会受到max_allowed_packet参数的影响而导致插入失败。因此,需要谨慎使用该参数,至少我不推荐。 3.--default-character-set=charset 指定导出数据时采用何种字符集,如果数据表不是采用默认的latin1字符集的话,那么导出时必须指定该选项,否则再次导入数据后将产生乱码问题。 4.--disable-keys 告诉mysqldump在INSERT语句的开头和结尾增加/*!40000ALTER TABLE table DISABLE KEYS*/;和/*!40000ALTER TABLE table ENABLE KEYS*/;语句,这能大大提高插入语句的速度,因为它是在插入完所有数据后才重建索引的。该选项只适合MyISAM表。 5.--extended-insert=true|false 默认情况下,mysqldump开启--complete-insert模式,因此不想用它的的话,就使用本选项,设定它的值为false即可。 6.--hex-blob

如何导入导出MySQL数据库

如何导入导出MySQL数据库 1. 概述 MySQL数据库的导入,有两种方法: 1) 先导出数据库SQL脚本,再导入; 2) 直接拷贝数据库目录和文件。 在不同操作系统或MySQL版本情况下,直接拷贝文件的方法可能会有不兼容的情况发生。 所以一般推荐用SQL脚本形式导入。下面分别介绍两种方法。 2. 方法一SQL脚本形式 操作步骤如下: 2.1. 导出SQL脚本 在原数据库服务器上,可以用phpMyAdmin工具,或者m ysqldump(mysql dum p命令位于m ysql/bin/目录中)命令行,导出SQL 脚本。 2.1.1 用phpMyAdmin工具 导出选项中,选择导出“结构”和“数据”,不要添加“Drop DATABASE”和“Drop TABLE”选项。 选中“另存为文件”选项,如果数据比较多,可以选中“gzipped”选项。 将导出的SQL文件保存下来。 2.1.2 用mysqldump命令行 命令格式 mysqldump -u用户名 -p 数据库名> 数据库名.sql 范例: mysqldump -uroot -p abc > abc.sql (导出数据库abc到abc.sql文件) 提示输入密码时,输入该数据库用户名的密码。 2.2. 创建空的数据库 通过主控界面/控制面板,创建一个数据库。假设数据库名为abc,数据库全权用户为abc_f。 2.3. 将SQL脚本导入执行 同样是两种方法,一种用phpMyAdmin(mysql数据库管理)工具,或者mysql命令行。 2.3.1 用phpMyAdmin工具 从控制面板,选择创建的空数据库,点“管理”,进入管理工具页面。 在"SQL"菜单中,浏览选择刚才导出的SQL文件,点击“执行”以上载并执行。 注意:phpMyAdmin对上载的文件大小有限制,php本身对上载文件大小也有限制,如果原始sql文件 比较大,可以先用gzip对它进行压缩,对于sql文件这样的文本文件,可获得1:5或更高的压缩率。 gzip使用方法: # gzip xxxxx.sql

TcpDump文件格式和结构

查看文章 Tcpdump文件格式和结构 2009-04-13 14:07 前言:层层剖析Tcpdump文件格式。 当你在Windows或者Linux环境下用tcpdump命令抓取数据包时,你将得到如下格式的tcpdump文件: 文件头| 数据包头 | 链路层数据 | 数据包头 | 链路层数据 | 数据包头 | 链路层数据 |...... 1. 文件头:每一个文件都以一个24字节的文件头开头。前四个字节是tcpdump 文件标志“A1 B2 C3 D4”或为“D4 C3 B2 A1”。 2. 数据包头 | 链路层数据:文件头之后,就是“数据包头 | 链路层数据”为一组的这样一组组数据。 3. 数据包头长度16个字节,它不是网路上真正传输的数据,它包含的信息主要是截获这个包的时间等信息。数据包头的第8-11和12-15字节(按编程习惯,第一个字节为0字节)表示后面链路层数据包的长度。8-11字节是其理论长度,12-15字节为其实际长度,如果存在截断情况,两者可能不同。如果在tcpdump 命令中使用了 -s 0 参数,则8-11字节和12-15字节应该相等。 从数据包头结束,到长度指明的字节数为止,是实际在网络中传输的链路层数据包。然后,就是下一个数据包头。 4. 链路层数据 链路层数据包格式和传输的方式有关:局域网共享上网,则是RFC894以太网协议,少数情况下是RFC 1042和802.3协议;如果是Modem拨号上网,则是RFC 1055的SLIP协议;如果是ADSL,则是RFC 1548的PPP协议。RFC894/RFC 1042/RFC 1548这三种协议的格式都是: 包头 | IP数据包 |(包尾) 对于RFC894,包头长度为14字节; ------>局域网方式上网; 对于RFC1042,包头长度为22字节; 对于RFC1548,包头长度为5字节;------>ADSL方式上网; 跨过这些包头字节,就是IP数据包了。 5.IP数据包: IP数据包格式为: IP包头 | IP包数据

mysql语句大全

MYSQL常用命令 1.导出整个数据库 mysqldump -u 用户名-p --default-character-set=latin1 数据库名> 导出的文件名(数据库默认编码是latin1) mysqldump -u wcnc -p smgp_apps_wcnc > wcnc.sql 2.导出一个表 mysqldump -u 用户名-p 数据库名表名> 导出的文件名 mysqldump -u wcnc -p smgp_apps_wcnc users> wcnc_users.sql 3.导出一个数据库结构 mysqldump -u wcnc -p -d –add-drop-table smgp_apps_wcnc >d:wcnc_db.sql -d 没有数据–add-drop-table 在每个create语句之前增加一个drop table 4.导入数据库 A:常用source 命令 进入mysql数据库控制台, 如mysql -u root -p mysql>use 数据库 然后使用source命令,后面参数为脚本文件(如这里用到的.sql) mysql>source wcnc_db.sql B:使用mysqldump命令 mysqldump -u username -p dbname < filename.sql C:使用mysql命令 mysql -u username -p -D dbname < filename.sql 一、启动与退出 1、进入MySQL:启动MySQL Command Line Client(MySQL的DOS界面),直接输入安装时的密码即可。此时的提示符是:mysql> 2、退出MySQL:quit或exit 二、库操作 1、、创建数据库 命令:create database <数据库名> 例如:建立一个名为xhkdb的数据库 mysql> create database xhkdb; 2、显示所有的数据库 命令:show databases (注意:最后有个s) mysql> show databases; 3、删除数据库 命令:drop database <数据库名> 例如:删除名为xhkdb的数据库 mysql> drop database xhkdb; 4、连接数据库 命令:use <数据库名> 例如:如果xhkdb数据库存在,尝试存取它: mysql> use xhkdb; 屏幕提示:Database changed

驱动蓝屏后调试DUMP文件 无PDB文件

关于分析DUMP文件的一些想法: 在分析一个驱动蓝屏的时候,如果有驱动的PDB文件就很容易找到出错的地方,然是如果没有PDB文件,往往比较麻烦,只能给出个大题的东西,今天调试了一下DUMP文件,有点感触,先来分析一下, 双机调试的方法不说了,直接开始调试:加载驱动文件,直接蓝屏了,这个时候WINDBG 给出了一下提示: FOLLOWUP_IP: HelloDDK+5ae f7c455ae 8be5 mov esp,ebp BUGCHECK_STR: 0x7E DEFAULT_BUCKET_ID: NULL_DEREFERENCE LAST_CONTROL_TRANSFER: from f7c455ae to 8060d589 STACK_TEXT: f7a01c54 f7c455ae 00000000 0000000a 0000000a nt!ProbeForWrite+0x39 WARNING: Stack unwind information not available. Following frames may be wrong. f7a01c74 f7c45504 f7a01d4c 805777f1 864d2b10 HelloDDK+0x5ae f7a01c7c 805777f1 864d2b10 860cd000 00000000 HelloDDK+0x504 f7a01d4c 80577901 800008a8 00000001 00000000 nt!IopLoadDriver+0x66d f7a01d74 80535c32 800008a8 00000000 865b4020 nt!IopLoadUnloadDriver+0x45 f7a01dac 805c71e0 f7a69cf4 00000000 00000000 nt!ExpWorkerThread+0x100 f7a01ddc 80542e12 80535b32 00000001 00000000 nt!PspSystemThreadStartup+0x34 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16 SYMBOL_STACK_INDEX: 1 SYMBOL_NAME: HelloDDK+5ae FOLLOWUP_NAME: MachineOwner MODULE_NAME: HelloDDK IMAGE_NAME: HelloDDK.sys DEBUG_FLR_IMAGE_TIMESTAMP: 4d60d8a6 STACK_COMMAND: .cxr 0xfffffffff7a01880 ; kb FAILURE_BUCKET_ID: 0x7E_HelloDDK+5ae

mysql5.7最优配置文件模板

竭诚为您提供优质文档/双击可除mysql5.7最优配置文件模板 篇一:mysql5.7的主从配置以及备份 引言:最近有几个项目开始尝试使用mysql5.7,听说是增加不少新的特性。性能也比前面的版本来得好。只是听说而已,目前都还只在测试中的。前面的版本,比如5.1。我 们备份一般是用xtraback,用该工具备份,数据库不会锁表。但不幸的是,目前xtraback最新的版本都还不支持对 mysql5.7的备份的。没办法了,只能使用老方法了,没错就是用mysqldump了。下面就让我们开始吧。 一、主从配置 首先,要在主库上创建一个用于主从同步的数据库账号。 1、主库上备份 以往我们新增加一个从库,都得先到主库或者更旧的从库上拿取一份最新的数据库备份文件,解压并在新从库上还原的。如果备份文件是用xtraback备份的,还原并不难的。现在的问题是mysql5.7不支持用xtraback工具备份的。只能用mysqldump备份,如下 mysqldump-p–opt–default-character-set=utf8–

extended-insert=true–single-transaction-R– flush-logs–master-data=1– all-databases>/root/xxx.sql 分析一下上面这个语句 –opt会lock本次需要备份的所有表,因为本次备份的是dbname数据库,所以会锁住dbname的所有表; –master-data=1,该选项将binlog的位置和文件名追加到输出文件中。如果为1,将会输出changemasteR命令;如果为2,输出的changemasteR命令前添加注释信息。该选项将打开–lock-all-tables选项,除非– single-transaction也被指定(在这种情况下,全局读锁在开始导出时获得很短的时间;其他内容参考下面的– single-transaction选项)。该选项自动关闭–lock-tables 选项; –single-transaction,该选项在导出数据之前提交一个beginsql语句,begin不会阻塞任何应用程序且能保证导出时数据库的一致性状态。它只适用于多版本存储引擎,仅innodb。本选项和–lock-tables选项是互斥的,因为locktables会使任何挂起的事务隐含提交。要想导出大表的话,应结合使用–quick选项 –extended-insert,使用具有多个Values列的inseRt 语法。这样使导出文件更小,并加速导入时的速度。默认为

使用dump文件分析系统蓝屏原因

使用dump文件分析系统蓝屏原因 出处:https://www.360docs.net/doc/8816571786.html,/746253/709702 目录 1 什么是dump文件 2 如何让系统在崩溃时记录dump文件 3 使用Debugging Tools for Windows (windebug)来分析dump文件 3.1 什么是windebug 3.2 windebug最新版安装方法(此方法为在线安装) 3.3 windebug的symbol符号文件的路径配置 3.4 dump文件的分析

1 什么是dump文件 当系统崩溃在蓝屏瞬间,系统会形成一个扩展名为dmp的存储器转储文件,默认存储位置为C:\WINDOWS\Minidmp。 2 如何让系统在崩溃时记录dump文件 A.右击“我的电脑”选择“属性”,在“系统属性”对话框中选择“高级” B.在“启动和故障恢复”中选择“设置”,具体设置如下图所示

3 使用Debugging Tools for Windows (windebug)来分析dump文件 3.1什么是windebug windebug是微软发布的一款相当优秀的源码级(source-level)调试工具,可以用于Kernel模式调试和用户模式调试,还可以调试Dump文件。 3.2 windebug最新版安装方法(此方法为在线安装) A.从https://www.360docs.net/doc/8816571786.html,/download/en/details.aspx?displaylang=en&id=8279下载 B.安装netFramework2.0 C.运行1中下载的winsdk_web.exe

一次外部数据导入mysql数据库的经历

一次外部数据导入mysql数据库的经历 1背景描述 在工作中难免遇到需要将有些外部数据导入到数据库中,我最近遇到了一次,当时首选方案是通过mysql的load data infile命令导入,在测试库测试时提示load data infile不能使用,检查生产同样不能使用(ERROR 1148 (42000): The used command is not allowed with this MySQL version)。换种方法,找一个能使用load data infile 的mysql库导入数据,之后将导入的数据通过mysqldump方式导出,最后在将导出的数据导入需要导入的库。方法可行但是没找到能使用load data infile 的库,方法被否决,最后通过ue手工拼sql语句进行了导入。此类任务还会遇到不能每次通过手工拼sql来实现,这次数据是388万行还在编辑软件可以承受的范围,假如上亿行呢,编辑工具就不能胜任了,下面是几种可行方法。 2实现方法一:通过脚本循环文件拼成sql 语句,利用mysql -e进行单行执行。 2.1脚本核心 2.2说明:此方法经过测试速度方面不是很理想。

3实现方法二:通过脚本循环数据拼成sql 语句,将sql语句写入文本文件,之后利用mysql < 文本文件执行插入。 3.1脚本核心 3.2说明:此方法适合拼sql语句效率比方法一快很多。 4实现方法三:在mysql可以重启的情况下修改secure_file_prive参数使其允许load data方式导入数据 4.1第一步:修改https://www.360docs.net/doc/8816571786.html,f,添加secure_file_priv=''

调试SQLSERVER生成dump文件的方法

调试SQLSERVER生成dump文件的方法 我们知道调试程序主要有两种方法 一种是:live debugging (附加进程使进程hang住)生产环境最好不要live debugging 一种是:post-mortem debugging or reading dump files (生成dump文件然后进行分析) 现在介绍一下如何生成dump文件,以及各种方法的差异 第一步:确定SQLSERVER的进程ID 由于我的机器安装了四个SQLSERVER实例,所以看到会有四个进程 方法1:在cmd窗口输入下面命令 tasklist | find /i "sqlservr" 方法2:打开任务管理进行查看

方法3:在SSMS里执行下面sql语句 SELECT SERVERPROPERTY('PROCESSID') AS sqlpid 方法4:从SQL errorlog里获取进程ID EXEC[sys].[sp_readerrorlog]

第二步:生成DUMP文件 方法1:使用SqlDumper 最一般的方法就是使用SQLSERVER内部的SqlDumper程序,如果使用默认安装路径default installation path 会是 C:\Program Files\Microsoft SQL Server\100\Shared

语法如下: SqlDumper 如果对语法不太熟悉,可以使用/? 查看帮助

mariadb数据库主从复制配置方法

主从复制包含两个步骤: 在master 主服务器(组)上的设置,以及在slave 从属服务器(组)上的设置. 一、Master主机配置 [root@master~]yum install mariadb-server -y [root@master~]systemctl start mariadb [root@master~]# mysql MariaDB [(none)]>create database cd; MariaDB [(none)]>use cd; MariaDB [(none)]>create table test1 (id int); 字段名数据类型 MariaDB [(none)]>show tables; 停止mysql主服务 [root@master~]systemctl stop mariadb 配置mysql主要同步的数据库名字并开启对应的二进制日志 [root@master~]vim /etc/https://www.360docs.net/doc/8816571786.html,f [mysqld] server-id=1 log-bin=master-bin binlog-do-db=cd binlog-ignore-db=mysql 开始配置log-bin导致服务器无法启动,可能是因为二进制目录权限不足,所以还是转到当前目录方便

重新启动 [root@master~]systemctl restart mariadb 授权 MariaDB [(none)]>grant replication slave on *.* to slave@10.1.42.212 identified by "123456"; MariaDB [(none)]>FLUSH PRIVILEGES; 在从slave上测试登录: [root@slave ~]# mysql -h 10.1.42.211-u slave -p123456 查看状态,这步很关键,两个参数在slave启动时候会用到 把主的原始数据传给从: [root@master~]mysqldump -u root -p cd> all1.sql [root@master~]scp all1.sql 10.1.42.212:/root 二、Slave主机配置

windows 下 自动备份mysql数据库--按时间命名备份文件

windows 下自动备份mysql数据库--按时间命名备份文件 1、复制date文件夹备份 ============================ 假想环境: MySQL 安装位置:C:\MySQL 论坛数据库名称为:bbs 数据库备份目的地:C:\db_bak\ ============================ 新建db_bak.bat,写入以下代码 *******************************Code Start***************************** net stop mysql xcopy c:\mysql\data\bbs\*.* c:\db_bak\bbs\%date:~0,10%\ /S /I net start mysql *******************************Code End ***************************** 然后使用Windows的“计划任务”定时执行该批处理脚本即可。(例如:每天凌晨3点执行back_db.bat)解释:备份和恢复的操作都比较简单,完整性比较高,控制备份周期比较灵活,例如,用%date:~0,10%。此方法适合有独立主机但对mysql没有管理经验的用户。缺点是占用空间比较多,备份期间mysql会短时间断开(例如:针对30M左右的数据库耗时5s左右),针对%date:~0,10%的用法参考。 2、mysqldump备份成sql文件 ============== 假想环境: MySQL 安装位置:C:\MySQL 论坛数据库名称为:bbs MySQL root 密码:123456 数据库备份目的地:D:\db_backup\ 脚本: *******************************Code Start*****************************

系统蓝屏,死机抓取dump方法

系统蓝屏,死机抓取dump方法 1:首先声明,介于很多情况下机器不明原因死机,重启或者蓝屏。影响了很多问题的排查。于此,写此贴跟进,以方便对此问题有应对之策,乃下下策。实在无招的情况下,才建议是用。 2:暂时我们先不讨论在有网维大师客户端的情况下的一些设置,先对正常系统状态下的蓝屏设置进程系统调校。 3:蓝屏文件需要debugview查看,要有一定的反向工程基础,代码编写能力和汇编理解能力。 废话不多说。请看实际内容: 1:先在注册表里添加一项键值,以实现机器死机的情况下,触发蓝屏的操作。 Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\Param eters] "PollingIterations"=dword:00002ee0 "PollingIterationsMaximum"=dword:00002ee0 "ResendIterations"=dword:00000003 "LayerDriver JPN"="kbd101.dll" "LayerDriver KOR"="KBD101A.DLL" "CrashOnCtrlScroll"=dword:00000001 含义:是在 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters 下面新建一个DWORD的值CrashOnCtrlScroll为1 重新引导后,寻找两次scrolllock键击,同时右ctrl键也被压下。 这样就可以提取到死机,无响应的dump文件 注意:使用手动提取dump文件,必须是ps2键盘 2:下图的相关设置:

JavaCore HeapDump文件及其分析方法

产生时间 Java程序运行时,有时会产生JavaCore及HeapDump文件,它一般发生于Java程序遇到致命问题的情况下。 ?有时致命问题发生后,Java应用不会死掉,还能继续运行; ?但有时致命问题发生,Java进程会死掉; 为了能够保留Java应用发生致命错误前的运行状态,JVM在死掉前产生两个文件,分别为JavaCore及HeapDump文件。 有何区别 JavaCore是关于CPU的,而HeapDump文件是关于内存的。 ?JavaCore文件主要保存的是Java应用各线程在某一时刻的运行的位置,即JVM执行到哪一个类、哪一个方法、哪一个行上。它是一个文本文件,打开后可以看到每一个线程的执行栈,以stack trace的显示。通过对JavaCore文件的分析可以得到应用是否“卡”在某一点上,即在某一点运行的时间太长,例如数据库查询,长期得不到响应,最终导致系统崩溃等情况。 ?HeapDump文件是一个二进制文件,它保存了某一时刻JVM堆中对象使用情况,这种文件需要相应的工具进行分析,如IBM Heap Analyzer这类工具。这类文件最重要的作用就是分析系统中是否存在内存溢出的情况。 怎么生成 这两个文件可以用手工的方式生成,当我们会遇到系统变慢或无响应的情况,这时就以采用手工的方式生成JavaCore及HeapDump文件。 在Unix/Linux上,产生这两个文件的方法如下: # ps -ef | grep java user 46164582017:30 pts/0 00:00:00 grep java root 558010 Oct27 ? 00:02:27/usr/bin/java -server -XX:PermSize=64M-XX:MaxPermSi ze=128m-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.uti l.logging.config.file=/usr/local/tomcat8090/conf/logging.properties-Djava.endorsed.dirs=/u sr/local/tomcat8090/endorsed -classpath :/usr/local/tomcat8090/bin/bootstrap.jar -Dcatali na.base=/usr/local/tomcat8090-Dcatalina.home=/usr/local/tomcat8090 -Djava.io.tmpdir=/ usr/local/tomcat8090/temp org.apache.catalina.startup.Bootstrap start # kill -3 5580

相关文档
最新文档