mysql 无法启动的几种常见问题

1、情况一：MySQL的错误日志文件（安装目录\MYOA\data5\机器名.err）会记录如下内容：

InnoDB: Reading tablespace information from the .ibd files...

InnoDB: Error: trying to add tablespace 460 of name '.\td_oa\flow_data_35.ibd'

InnoDB: to the tablespace memory cache, but tablespace

InnoDB: 460 of name '.\td_oa\exam_data.ibd' already exists in the tablespace

解决方法：

1）剪切出安装目录\MYOA\data5\TD_OA的flow_data_35.ibd和flow_data_35.frm两个文件；

2）启动MySQL5_OA服务，使用备份的flow_data_35.sql导入到TD_OA库中。如果提示flow_data_35表已经存在不能导入，则继续按后续步骤执行；

3）在data5下手动建立tmp目录；

4）使用MySQL管理工具或MySQL命令行程序在tmp下建立名称为flow_data_35的表（包含一个字段即可）；

5）将tmp下的flow_data_35.frm和flow_data_35.ibd拷贝到安装目录\MYOA\data5\TD_OA目录下；

6）在MySQL管理工具或MySQL命令行程序中，进入TD_OA库，使用“drop table flow_data_35”命令清除公共表空间中残留的flow_data_35表的相关信息；

7）进入tmp库，删掉flow_data_35表；

8）使用备份的flow_data_35.sql导入到TD_OA库中；

9）如果还有其他表存在该问题，可重复执行4至8步骤。

2、情况二：MySQL的错误日志文件（安装目录\MYOA\data5\机器名.err）会记录如下内容：

130409 15:54:31 [Note] Plugin 'FEDERATED' is disabled.

130409 15:54:31 InnoDB: The InnoDB memory heap is disabled

130409 15:54:31 InnoDB: Mutexes and rw_locks use Windows interlocked functions

130409 15:54:31 InnoDB: Compressed tables use zlib 1.2.3

130409 15:54:32 InnoDB: Initializing buffer pool, size = 1023.0M

InnoDB: VirtualAlloc(1086849024 bytes) failedWindows error 8

130409 15:54:32 InnoDB: Completed initialization of buffer pool

130409 15:54:32 InnoDB: Fatal error: cannot allocate memory for the buffer pool

130409 15:54:32 [ERROR] Plugin 'InnoDB' init function returned error.

130409 15:54:32 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.

130409 15:54:32 [ERROR] Unknown/unsupported storage engine: Innodb

130409 15:54:32 [ERROR] Aborting

解决方法：

此情况出现的原因是myoa\mysql5\my.ini中innodb_buffer_pool_size的值太大，OA服务器 *** 作系统不支持所致。改小后再启动mysql5_OA服务即可，一般保持和数据库大小一致。数据库大小即是myoa/data5的大小。

3、情况三：mysql服务启动不了，事件查看器中显示：The syntax '--log-slow-queries' is deprecated and will be removed in a future release. Please use '--slow-query-log'/'--slow-query-log-file' instead.

解决方法：安装目录\MYOA\data5下的ibdata1、ib_logfile0、ib_logfile1文件属性被设置为只读导致，取消只读控制，重启mysql5_OA服务即可。

4、情况四：MySQL的错误日志文件（data5\机器名.err）会记录如下内容：InnoDB: No valid checkpoint found.

解决方法：此问题找不到检查点，数据库是无效的，此种情况，只能用热备份数据恢复。

5、以上四种情况，是2013版OA系统目前比较常见的mysql服务启动不了的现象和解决办法，大家可作参考，其他情况的话，再具体分析处理。

6、分析思路总结：遇到mysql5_OA服务启动不了的情况，首先查看myoa\data5下的错误日志文件，根据日志中的具体内容进行具体分析。

7、2013版MYSQL服务启动不了（可以尝试强制启动mysql服务）方法如下：

1)打开\MYOA\mysql5\my.ini，去掉innodb_force_recovery=1前边的注释。

2)启动MySQL5_OA服务，此时MySQL处于只读状态，可以导出，不可写入。如果仍不能启动，可以尝试将innodb_force_recovery修改为2、3、4、5、6等，直到可以启动为止。

3)使用MySQL管理工具，将TD_OA等相关的数据库导出为SQL文件。

4)停止MySQL5_OA服务，删除TD_OA下的所有文件、ibdata1、ib_logfile0、ib_logfile1等文件。

5）打开\MYOA\mysql5\my.ini，在innodb_force_recovery=1前边加上#号，将该项注释掉。

6)启动MySQL5_OA服务，然后导入此前备份的SQL文件。

7)检查数据库，将无法通过该方法恢复的数据表，通过之前自动备份的SQL文件进行恢复。

在企业的经营发展过程当中，数据库安全问题始终是一个重大问题。如果企业想要顺利发展，对这方面的问题进行防范和控制是非常有必要的。在实际的工作中，想要防范和控制问题，就必须先对这部分的内容有所了解，那么，企业数据库一般存在哪些安全问题呢?今天小编就为大家做个详细介绍。

企业数据库安全问题很多，具体有不良的口令政策、SQL注入等，这些问题中，有来自企业员工本身的 *** 作失误，也有数据库自带的一些安全隐患。比如说口令政策，这就是由于人员的偷懒。很多企业的管理人员在工作过程中的疏忽大意，使得企业员工还在选择一些被淘汰的加密方式，这种工作方式很容易就会导致企业数据库被入侵，另外，有的企业虽然数据库加密系统已经非常完善了，但是 *** 作者为了省事，让系统自动记录密码，或者直接将一些密钥等加密工具长时间插在电脑主机上，也会为企业数据安全埋藏隐患。

如果说不良的口令政策是员工工作上的问题，那么SQL注入就是数据库层面的问题了。数据库本身的安全性不是非常高，因此如果数据库接受了用户提供的不干净的，或者没有经过验证的数据所产生的SQL注入，就会为SQL注入攻击敞开大门。比如说，通过修改从基于网络的格式收到的信息，攻击者能够提供恶意的SQL请求并且直接把指令发送到数据库中。

这上边就是企业在日常工作过程当中常见的一些数据库安全问题介绍了，那么，对于这部分的问题，我们还是应该具体问题具体分析，比如说对于不良的口令政策，企业一方面应该加强自己企业内部的一些密钥管理。一方面可以提供一些较为安全的登录方式。另外一方面，还应该在平时的工作过程中对员工进行定期的培训，提高他们的安全意识。

而对于数据库安全问题中的SQL注入，最好的办法还是在企业中购买一款高质量的安全防护软件。在这里，小编为大家推荐的是上讯信息的WEB安全网关(WAF)，这款产品的专业性强，安全度高，能够有效减少企业数据库受到SQL注入攻击的可能性，如果大家想要购买一款高质量的安全防护软件，选择上讯信息的WEB安全网关(WAF)准没错的。

数据库慢一般有三种情况

逐渐变慢

突然变慢

不定时变慢

第一种情况 逐渐变慢 要建立一个长期的监控机制 比如 写个shell脚本每天的忙时(通常 ~ etc )定时收集os neork db的信息 每个星期出report对收集到的信息进行分析 这些数据的积累 可以决定后期的优化决策 并且可以是DBA说服manager采用自己决策的重要数据 DBA的价值 就在每个星期的report中体现

第二种情况 突然变慢 也是最容易解决的 先从业务的角度看是DB的使用跟以前有何不同 然后做进一步判断 硬件/网络故障通常也会引起DB性能的突然下降

第一步: 察看DB/OS/NEORK的系统log 排除硬件/网络问题

第二步 察看数据库的等待事件 根据等待事件来判断可能出问题的环节 如果 没有等待事件 可以排除数据库的问题 如果有等待时间 根据不同的等待事件 来找引起这些事件的根源

比如latch free等跟SQL parse有关系的等待事件 OS的表现是CPU 的占用率高

db file scattered read等跟SQL disk read有关系的等待时间 OS的表现是iostat可以看到磁盘读写量增加

第三步: 察看os的信息 CPU/IO/MEMORY等

a Cpu 的占用率

CPU占用率与数据库性能不成反比 CPU占用率高 不能说明数据库性能慢 通常情况 一个优化很好 而且业务量确实很大的数据库 CPU的占用率都会高 而且会平均分布在每个进程上 反过来 CPU的占用率都会高也不代表数据库性能就好 要结合数据库的等待事件来判断CPU占用率高是否合理

如果某个进程的cpu占用高 肯定是这个进程有问题 如果 不是oracle的进程 可以让application察看是否程序有死循环等漏洞 如果 是oracle的进程 可以根据pid查找oracle数据字典看看这个进程的发起程序 正在执行的sql语句 以及等待事件 然后 不同情况使用不同的方法来解决

b IO

排除硬件的IO问题 数据库突然变慢 一般来说 都是一个或几个SQL语句引起的

如果IO很频繁 可以通过优化disk reads高的TOP SQL来解决 当然这也是解决IO问题的最笨也是最有效的办法

OS以及存储的配置也是影响IO的一个重要的原因

比如 最常见的HP unix下异步IO的问题 如果DBA GROUP没有MLOCK的权限 ORACLE是不使用AIO的 偏偏OS与DB的两方的admin如果配合不够好地话 这个配置就很容易给漏掉了

c Memory

第二种情况与memory的关系比较小 只要SGA区配置合理没有变化 一般来说 只要不是Application Memory leak 不会引起突然变慢的现象

第三种情况 不定时变慢 是最难解决的 现场出现的问题原因也是五花八门千奇百怪 最重要的是 出现慢的现象时 以最快的速度抓取到最多的信息以供分析 先写好抓取数据的shell 脚本 并在现象发生时及时按下回车键

一个例子

数据库突然变慢

背景: 一个新应用上线后 数据库突然变慢

第一步 调查新应用

据开发人员讲新应用访问的都是新建立的表 表的数据量很小 没有复杂的SQL查询

查询 v$sqlarea 分别按照disk_reads / buffer_gets / executions 排序 TOP SQL 中没有新应用的SQL 排除新应用数据库访问照成的性能问题

第二步 察看数据库log/ OS log

数据库log中可以看到大量的ORA 错误 以及大量的dump文件 分析dump文件(时间久了 没有dump文件可参考 具体细节没法描述下来 ) 发现是新应用通过dblink访问remote DB时生成的dump文件 应用开发人说没法修改 Oracle也没有相应的patch解决

OS log中没有错误信息

第三步 察看statspack report

从wait events中看到 Top event是 buffer busy waits db file parallel write 等于IO相关的等待事件

从buffer busy waits 的统计信息来看 是等待data block

还有些physical reads等信息与从前比没有太多的异常

Tablespace 的IO reads/writes也没有异常 但是wait明显增加

初步确定是IO问题

第四步 察看OS的信息

top 命令(输出为实验室数据 仅作格式参考)

load averages: : :

processes: sleeping zombie stopped on cpu

CPU states: % idle % user % kernel % iowait % swap

Memory: M real M free M swap in use M swap free

PID USERNAME THR PRI NICE SIZE RES STATE TIME CPU MAND

a K K cpu/ : % top

mpgj M K sleep : % view_server

当时现场数据显示 iowait 值与以前相比大很多 没有异常进程

sar –d (输出为实验室数据 仅作格式参考)

SunOS sc Generic_ sun u / /

: : device %busy avque r+w/s blks/s avwait avserv

sd

sd a

sd b

sd c

sd g

当时现场数据显示 放数据文件的设备 avwait avque blks/s值偏大

第五步 察看数据库的等待事件

一个大业务量的数据库如果性能不好的话 一般来说都会有大量的等待事件 上百个等待事件很常见 我通常会按照EVENT进行group

Select count(*) event from v$session_wait where event not in ( *** on timer pmon timer rdbms ipc message SQL*Net message from client ) group by event order by desc

输出结果显示最多的等待事件是buffer busy waits

进一步分析 找出等待的原因

Select count(*) p p p from v$session_wait where event = buffer busy waits group by p p p

在buffer busy waits等待事件中

P = file#

P = block#

P = id ( 此id对应为等待的原因)

按照p p p group是为了明确buffer busy waits的等待集中在哪些对象上

Metalink对buffer busy waits等待事件的描述有如下一段话

If P shows that the buffer busy wait is waiting for a block read to plete then the blocking session is likely to be waiting on an IO wait (eg: db file sequential read or db file scattered read for the same file# and block#

输出结果显示 等待分布在多个不同的对象上 等待原因为 waiting for a block read to plete 进一步分析为IO的问题

如果 buffer busy waits等待集中在某个对象上 说明有hot block 通过重新rebuild这个对象增加freelist来解决 RAC环境增加freelist group

通过以下SQL可以找到具体的object

Select owner segment_name segment_type from dba_extents where file_id=P and P beeen block_id and block_id+blocks

P P 是上面v$session_wait查出的具体的值

第六步 明确原因 找出解决步骤

分析

磁盘的IO流量增加

磁盘的IO等待增加

DB的IO流量没有增加

DB的IO等待增加

由 可以推出 有数据库以外的IO访问磁盘

察看磁盘配置 该VG只存放了数据库数据文件和数据库系统文件 排除数据文件 产生IO的是数据库系统文件

数据库系统文件一般来说不会产生IO 有IO读写的地方只有log和dump文件

结论 ora 产生的大量core dump文件堵塞IO

解决办法

消除ora (应用不改的情况下 无法解决)

把dump目录指向别的VG

让oracle尽量少的去写core dump文件

background_core_dump = partial

lishixinzhi/Article/program/Oracle/201311/18969

---