mysql 表修复 1033错误

查看表报错

show index from table;

ERROR 1033 (HY000): Incorrect information in file: ‘./mysql_db/table.frm

查看表引擎依然报错

alter table table engine=myisam;

ERROR 1033 (HY000): Incorrect information in file: ‘./mysql_db/table.frm’

####

# myisamchk -r -q table 
– check record delete-chain
– recovering (with sort) MyISAM-table ‘table 
Data records: 76205
– Fixing index 1
– Fixing index 2
– Fixing index 3
– Fixing index 4
重启后就可以正常识别到了

简单安全的修复

注释:如果想更快地进行修复,当运行myisamchk 时,你应将sort_buffer_size和Key_buffer_size 变量的值设置为可用内存的大约25% 。

首先,试试myisamchk -r -q tbl_name(-r -q 意味着“快速恢复模式”) 。这将试图不接触数据文件来修复索引文件。如果数据文件包含它应有的一切内容和指向数据文件内正确地点的删除连接,这应该管用并且表可被修复,开始修复下一张表。否则,执行下列过程:

在继续前对数据文件进行备份。

使用myisamchk -r tbl_name(-r 意味着“恢复模式”) 。这将从数据文件中删除不正确的记录和已被删除的记录并重建索引文件。

如果前面的步骤失败,使用myisamchk –safe-recover tbl_name 安全恢复模式使用一个老的恢复方法,处理常规恢复模式不行的少数情况(但是更慢)。

SQL Server 2008图文安装教程

2003的系统安装mssql2008 安装失败,删除msxml软件
从安装程序看,感觉SQL Server 2008的设计更灵活、更精确,安装速度在我的笔记本上装的虚拟机(分配了768M内存)中比较流畅,感觉比2005要好。

SQL Server 2008我们也能从中体验到很多新的特性,但是对于SQL Server 2008安装,还是用图来说话比较好。本文将从SQL Server 2008安装开始讲起。

本来这篇是打算玩玩服务器功能中的第一个:adrms的,没想到装了几次都安装成功,但是有错误,后来没招了,打算将rms的数据库放到sql上来折腾折腾,所以为了不让大家觉得突兀,所以本篇SQL Server 2008安装,SQL Server 2008在企业中也是非常重要的应用,各种财务系统,erp系统,oa系统等都会用到SQL Server 2008数据库,甚至网站也可以用到数据库来作为网站的后台,也算基础的应用吧,咱也来体验下SQL Server 2008吧.

本例拓扑图再次扩大为如图增加一台SQL Server 2008服务器

2011121300111712

下面上正菜,开始安装

放入SQL Server 2008光盘,直接运行吧

2011121300111713

要求安装.NET那就装吧

2011121300111714

嘣,出错了,不能这样装,那么去服务器管理器安装好了

2011121300111715

打开功能安装向导,选择.NET,要求安装.NET所需要的其他角色

2011121300111716

开始安装

2011121300111717

IIS角色,默认好了,我们又不要IIS

2011121300111718

开始安装

2011121300111719

安装完成.

2011121300111720

再次运行SQL Server 2008安装

2011121300111721

单击安装-全新的SQL Server独立安装,如果我们准备好了故障转移群集,那么我们就可以创建故障转移群集SQL

2011121300111722

常规检查

2011121300111723

一笑而过

2011121300111724

选择版本,或者输入密钥自动识别版本

2011121300111725

授权协议

2011121300111726

支持文件安装

2011121300111727

安装完成开始检查自身

2011121300111728

俩警告,一个是.NET警告,说没网络会延迟,或者需要下载文件

2011121300111729

一个数要打开端口,无视了,晚点再打开

2011121300111730

选择安装的功能,SQL数据库和管理工具

2011121300111731

选择实例

2011121300111732

驱动器检查

2011121300111733

选择服务账户,如图选择的是本地系统账户

2011121300111734

验证模式:sql和本地模式两种,输入密码,另外添加管理员,可以添加本地组或者当前用户

2011121300111735

选择汇报微软选项

2011121300111736

运行检查

2011121300111737

信息预览确认

2011121300111738

开始正式安装咯

2011121300111739

安装完成

2011121300111740

单击关闭完成

2011121300111741

开始菜单中的sql2008

2011121300111742

打开smse管理工具

2011121300111743

打开管理工具如图

2011121300111744

新建数据库选项居然有启动ps选项了,集成到sql2008了

2011121300111745

新建数据库页面已经抛弃了sql7.0,只兼容SQL Server 2000了,其他的倒没什么大的变化

2011121300111746

启动ps后如图

2011121300111747

在防火墙中新建入站规则,端口选择1433

2011121300111748

建立完成,可以在客户端作业了.呵呵,下篇试试rms是否还有错误,再有错误我也郁闷了.

2011121300111749

王的盛宴

503d269759ee3d6df6c03e3143166d224e4a20a44723fefa
《王的盛宴》不仅涵盖了“鸿门宴”这一耳熟能详的典故,

更再现了刘邦与项羽、韩信三位历史人物波澜壮阔的一生。“鸿门宴”、“成也萧何,败也萧何”“霸王别姬”“项庄舞剑意在沛公”等经典典故。

在《王的盛宴》中,将以崭新的历史视角作出全新诠释;

据制作方单方面称:“《王的盛宴》不是对《史记》中鸿门宴等段落的简单翻拍,而是依据近年来最新的考古资料,对这一段史实的重新演绎。”

王的盛宴,华丽的盛宴!

1、我的一生都是鸿门宴。
2、我在外面干的是大事“灭秦”。
3、我他妈喝高了。
4、灭秦不耽误你找女人。
5、刘邦手下大臣找他来商议大事,结果揭开帐篷发现他和人私会,放下帐篷只听刘邦里面来了句,“我一会就完”。
6、项羽是我一生中见过最高尚的人。
7、让理想继续活下去。
8、项羽是贵族,他只在意了自己的光芒,却忽略了他人的欲望。

王侯将相宁有种乎!

2013-购买火车票

1744300

订票神器的 12306 订票助手

除此之外,还有一个木鱼开发的的12306订票助手,支持火狐、傲游、Chrome、搜狗、淘宝浏览器、猎豹浏览器等众多浏览器,具体安装教程请移步官方网站。

  • 谷歌浏览器、猎豹浏览器、360极速浏览器扩展安装地址:点击下载
  • 火狐浏览器脚本地址:点击安装  (需安装 Scriptish扩展)
  • 搜狗浏览器扩展地址:点击下载

cisco交换机端口镜像实现监控

WiresharkPortable软件,这是一个免费的网络封包分析软件,抓包工具

可以针对公共网络进行端口监控

 

114057990

 

环境:

internet防火墙下接入3层switch(cisco 2960)

需要针对主交换机进行端口镜像实现端口监控

 

114436605

fa0/39为监控机器的网络端口

fa0/41为被监视的端口(可以理解为全局网络出入端口)

进入交换机配置可以多种选择,为了方便,个人使用telnet进行网络配置

打开命令提示符

telnet  <ip>—–为主交换机IP地址,输入密码进入用户模式

switch>enable———进入特权模式

switch#config terminal—进入全局设置模式

switch(config)#monitor session 1 destination interface fa0/39 ——镜像目的端口fa0/39(监控端口)

switch(config)#monitor session 1 source interface fa0/41———镜像源端口(被监控的端口)fa0/41

OK,大功告成!退出即可。

 

120227277

 

可以查看局域网内IP流量啦!

线上mysql慢查询优化(转)

mysql的慢查询优化是个老生常谈的话题.本文结生产数据库中遇到的实际问题,举例说明.

开启慢查询支持
首先要开通慢查询日志,修改my.cnf配置文件,添加如下选项:
log-slow-queries = slow.log
long_query_time = 1 —-如果打了patch,可以指定更小的值
log-queries-not-using-indexes

然 后,把slow.log按天来切割,例如 slow.log.20100405

分析慢查询日志

分析慢查询语句的最重要的工具,当然是mysql官方提供的mysqldumpslow了.它的详细用法,请参考我之前的文章
mysqldumpslow -s t -t 5 slow.log.20100405 >analyse.txt
上面的语句将慢查询语句按照总时间排序,不是mysqldumpslow默认的按照语句执行的平均时间排序.原因是,总时间最长的语句,才是真正需要优化的慢查询语句,而且这种语句的优化往往能带来较好的效率提升.

在top5的语句中,我找到了如下的一条sql语句:

Count: 48 Time=206.79s (9926s) Lock=0.00s (0s) Rows=1.0 (48), work[work]@[10.81.6.106]
SELECT MAX(img_id) as max_img_id FROM t_mis_pic WHERE N AND img_id%N=’S’
(每天执行了48次,平均每次206s,绝对是慢的需要优化了)
根据上述的sql语句模型,去slow.log中找到真实的sql语句中的一条:

SELECT MAX(img_id) as max_img_id FROM t_mis_pic WHERE 1 AND img_id%2=’0′;

好了,现在来看看我们有没有可能优化它.

定位问题,优化
分析慢查询语句的工具,首先是explain,如果不能解决,再考虑用profile.
来 show一下表的结构:

show create table t_mis_pic \G
Table: t_mis_pic
Create Table: CREATE TABLE `t_mis_pic` (
`img_id` bigint(20) unsigned NOT NULL,
`add_time` int(10) unsigned NOT NULL,
`is_del` tinyint(3) unsigned NOT NULL default ‘0’,
PRIMARY KEY (`img_id`),
KEY `add_time` (`add_time`,`is_del`)
) ENGINE=InnoDB DEFAULT CHARSET=gbk
1 row in set (0.00 sec)

可以看到,img_id列上是有主键的.

再explain一下:
Explain SELECT MAX(img_id) as max_img_id FROM t_mis_pic WHERE 1 AND img_id%2=’0′ \G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: t_mis_pic
type: index —-对整个索引的扫描
possible_keys: NULL
key: add_time —-利用了索引,但是不是主键索引,只是 add_time索引本身包含了主键列,比表的数据小,所以mysql选择了它
key_len: 5
ref: NULL —-无法根据条件来实现过滤和快速查找
rows: 89964741 —–快要1亿的数据,全索引扫描,导致了慢查询
Extra: Using where; Using index —利用到了索引和where条件语句

上面的分析已经很清楚了,mysql无法有效的利用主键索引,而且由于数据量太大,导致了慢查询语句.再来看看表的状态:
show table status like ‘t_mis_pic’ \G

Rows: 85532594
Avg_row_length: 55
Data_length: 4771020800
Max_data_length: 0
Index_length: 2581594112

从上面的统计中,看到索引的量占到了数据的一半以上,都很巨大.所以mysql 即使扫描索引也需要很长的时间.现在我们已经知道问题所在了,那么我们应该怎么优化它呢?

从 SELECT MAX(img_id) as max_img_id FROM t_mis_pic WHERE 1 AND img_id%2=’0′;
这句话来分析,是想要找到最大的为偶数的img_id.那么我们正好可以利用img_id上的主键索引,先直接找到img_id的最大值,然后找到小于等于这个最大值的并且为偶数的 img_id值,就是我们想要的结果.

先explain一下:

explain select MAX(img_id) as max_img_id FROM t_mis_pic \G:

rows: NULL
Extra: Select tables optimized away

结果表明,mysql不用查询表就可以得到最大的img_id值.那么我们继续改写
SELECT MAX(img_id) as max_img_id FROM t_mis_pic WHERE 1 AND img_id%2=’0′ 这条语句:
select img_id as max_img_id
FROM t_mis_pic
where img_id<=(select MAX(img_id) FROM t_mis_pic) —–wehre条件已经成为where img_id<=常数
and img_id%2=0 —-限制 img_id为偶数
order by img_id desc —-利用 img_id上的索引,从最大的img_id开始,往前寻找为偶数的img_id
limit 1 —返回符合条件的最大的img_id

根据上面的分析,再来explain一下看看是 否符合我们的预期:

explain select img_id as max_img_id FROM t_mis_pic where img_id<=(select MAX(img_id) FROM t_mis_pic) and img_id%2=0 order by img_id desc limit 1 \G

*************************** 1. row ***************************
id: 1
select_type: PRIMARY
table: t_mis_pic
type: range —-mysql仍然进行索引扫描,但是此处是 range扫描,不需要扫描整个index.
possible_keys: PRIMARY
key: PRIMARY
key_len: 8
ref: NULL
rows: 23548910 —–sql语句本身只需 要返回一行,并不需要检查23548910 这么多行,此处的数字可以忽略.实际上,mysql最多只需要扫描2行.
Extra: Using where; Using index —–mysql扫描的是索引,而不是表本身
*************************** 2. row ***************************

rows: NULL
Extra: Select tables optimized away —-优化的不能再优化了

在备机上执行这条语句,瞬间即可完成.这个慢查询语句可以完全消除.

回头看看slow.log的每天统计结果中, SELECT MAX(img_id) as max_img_id FROM t_mis_pic WHERE N AND img_id%N=’S’ 语句每天执行48次,每次执行平均时间为200s左右,而优化后,执行的时间可以忽略不计,效果还是非常明显的.

其他方法
既然所有的查询都用的是img_id%2这个条件,那么我们可以给该表增加一列,存储的值就是img_id%2后的结果.然后再给这一列建立索引.但是速度仍然比不上上面改写后的sql语句,究其原因,因为img_id%2的结果不是奇数就是偶数,区分度太小,给这样的列建立索引的效果就不明显了.事实上,在其他商业数据库中,比如oracle,它的函数索引就是这个原理.针对这个例子,oracle的位图索引就更快了.