cat /proc/net/dev 通过这个文件可以看到网络流量

 查看全文

这个介绍了mysql的一下关于硬件方面的一些优化，很不错！ 查看全文

Scale-up（纵向扩展）和Scale-out（横向扩展）的解释 查看全文

我有过敏性鼻炎，一到夏天就很难受，现抄录民间偏方，以资大家参考:

 查看全文

SYSDBA不是权限，当用户以SYSDBA身份登陆数据库时，登陆用户都会变成SYS。
sysdba身份登陆可以打开，关闭数据库，创建SPFILE，对数据库进行恢复操作等，而这些是DBA角色无法实现的；
sysdba 是系统权限，dba是用户对象权限；
sysdba，是管理oracle实例的，它的存在不依赖于整个数据库完全启动，只要实例启动了，他就已经存在；
以sysdba身份登陆，装载数据库、打开数据库，只有数据库打开了，或者说整个数据库完全启动后，dba角色才有了存在的基础；
dba是一种role对应的是对Oracle实例里对象的操作权限的集合，而sysdba是概念上的role是一种登录认证时的身份标识而已。而 且,dba是Oracle里的一种对象，Role 和User一样，是实实在在存在在Oracle里的物理对象，而sysdba是指的一种概念上的操作对象，在Oracle数据里并不存在。

innodb_flush_log_at_trx_commit：
主要控制了innodb将log buffer中的数据写入日志文件并flush磁盘的时间点，取值分别为0、1、2三个。0，表示当事务提交时，不做日志写入操作，而是每秒钟将log buffer中的数据写入日志文件并flush磁盘一次；1，则在每秒钟或是每次事物的提交都会引起日志文件写入、flush磁盘的操作，确保了事务的 ACID；设置为2，每次事务提交引起写入日志文件的动作，但每秒钟完成一次flush磁盘操作。显然，设置为0或2可以减小系统的io压力，特别是0 时，速度最快，提高mysql写操作的吞吐量，但mysql或操作系统的崩溃、断电都可能会引起数据的丢失，设置为2时os的崩溃和断电可能会引起数据的 丢失。

innodb_flush_method：

影响了服务器flush数据或日志文件的方法。具体有三个选值：默认的default，innodb使用fsync()函数flush数据和日志文 件；O_DIRECT，innodb使用O_DIRECT的方式打开数据文件，并使用fsync()函数flush数据和日志文 件；O_DSYNC，innodb使用O_SYNC打开并flush日志文件，使用fsync()函数flush数据文件。

注：在类unix操作系统中，文件的打开方式为O_DIRECT会最小化缓冲对io的影响，该文件的io是直接在用户空间的buffer上操作 的，并且io操作是同步的，因此不管是read()系统调用还是write()系统调用，数据都保证是从磁盘上读取的；O_SYNC方式表示以同步io的 方式打开文件，任何写操作都将阻塞到数据写入物理磁盘后才返回。fsync(int filedes)函数只对由文件描述符filedes指定的单一文件起作用，并且等待写磁盘操作结束，然后返回。fdatasync(int filedes)函数类似于fsync，但它只影响文件的数据部分。而除数据外，fsync还会同步更新文件的元信息到磁盘。

sync_binlog:

影响了binary log的fllush，当为1时，每个事物提交后，mysql将用fdatasync()函数将二进制日志同步到磁盘上；当为0时，mysql不会做额外的flush，而是依靠os的flush。

做过一些相应的测试，获得一些以上三参数搭配使用的结论：

1）O_DIRECT的flush_method更适合于操作系统内存有限的情况下（可以避免不必要的对交换空间的读写操作），否则，它会由于禁用了os的缓冲降低对数据的读写操作的效能。

2）Sync_binlog为1时，每个含有修改操作的事物提交后，mysql将把二进制日志同步到磁盘上，增大了io压力，引起相应瓶颈，会降低对数据写操作的效率。而select操作不写入binary log，所以不受任何影响。

3）对于innodb_flush_log_at_trx_commit与innodb_flush_method的不同组合（0|1|2，default|O_DSYNC）（对于O_DIRECT的情况特殊，已经在1）中单独做了总结在此不累述）分析得：

①（0， default）每秒钟调用fsync()同步一次innodb logfile，io压力小，性能高，但可能损失数据；

②（1， default）每秒钟和每次commit调用fsync()同步一次innodb logfile，保证数据完整的同时，加大了io压力，吞吐量相对低；

③（2， default）速度介于前两者之间，也不能完全保证数据的安全；

④（0，O_DSYNC）每秒同步日志及数据文件，吞吐量等情况应与（0， default）基本一致；

⑤（1，O_DSYNC）每秒钟和每次commit同步数据及日志文件，相应于（1， default）情况一致；

⑥（2，O_DSYNC）虽然innodb_flush_log_at_trx_commit设置为2，innodb被告知每次事务提交引起写入 日志文件的动作，每秒钟完成一次flush磁盘操作，但由于O_DSYNC的设置使得os对日志自动做了同步工作，所以吞吐量等情况与（1， default）和（1，O_DSYNC）相一致。

今天一个朋友让我帮他处理以下1张3.78亿数据的表，需要导出2010年的数据到另外1张表，我查了下2010年的数据就有1.8，然后我修改了一下my.cnf的部分参数： 查看全文

SET SERVEROUTPUT ON
SET LINESIZE 1000
SET FEEDBACK OFF
set long 999999
SET PAGESIZE 1000
set heading off


EXECUTE DBMS_METADATA.SET_TRANSFORM_PARAM(DBMS_METADATA.SESSION_TRANSFORM,'STORAGE',false);


SELECT concat(DBMS_METADATA.GET_DDL(U.OBJECT_TYPE, u.object_name),'
/')
FROM USER_OBJECTS u
where U.OBJECT_TYPE IN ('PROCEDURE');


SELECT concat(DBMS_METADATA.GET_DDL(U.OBJECT_TYPE, u.object_name),';') as text
FROM USER_OBJECTS u
where U.OBJECT_TYPE IN ('TABLE');
 查看全文

vmware server 2.0 好像不支持克隆，不知道是不是我使用的是免费版的原因，今天我来克隆一下,结果成功克隆！ 查看全文

 查看全文

$ cat ttt.txt
username provinceid cityid
12071582 25 511
26368019 20 20
32292363 991 998
2705053 20 754
28840159 20 754
20792273 20 751
25024068 23 23

sed 1d ttt.txt | awk '{print "update tabname set province_id = "$2" , city_id = "$3" where username = ""'反斜杠''"$1"'反斜杠'';"}'

要拼出sql语句来！

ref:http://haohetao.javaeye.com/blog/671733

 查看全文

CREATE TABLE t(
class1 VARCHAR2(2 BYTE),
calldate DATE,
callcount INTEGER
);

INSERT INTO t(class1, calldate, callcount)
VALUES ('1', TO_DATE ('08/08/2005', 'MM/DD/YYYY'), 40);

INSERT INTO t(class1, calldate, callcount)
VALUES ('1', TO_DATE ('08/07/2005', 'MM/DD/YYYY'), 6);

INSERT INTO t(class1, calldate, callcount)
VALUES ('2', TO_DATE ('08/08/2005', 'MM/DD/YYYY'), 77);

INSERT INTO t(class1, calldate, callcount)
VALUES ('3', TO_DATE ('08/09/2005', 'MM/DD/YYYY'), 33);

INSERT INTO t(class1, calldate, callcount)
VALUES ('3', TO_DATE ('08/08/2005', 'MM/DD/YYYY'), 9);

INSERT INTO t(class1, calldate, callcount)
VALUES ('3', TO_DATE ('08/07/2005', 'MM/DD/YYYY'), 21);

COMMIT ;

oracle：

WMSYS.WM_CONCAT

SQL> select class1,wmsys.wm_concat(callcount) from t group by class1;

CLASS1 WMSYS.WM_CONCAT(CALLCOUNT)
------ --------------------------------------------------------------------------------
1 40,6
2 77
3 33,9,21

mysql :

group_concat

select class1,group_concat(callcount) from t group class1;

注意：group_concat(callcount)可能被截断，因为有个参数规定了这个结果的长度，如果很长，需要修改这个参数！

ref：http://www.ningoo.net/html/2008/how_to_do_string_aggregate_on_oracle.html

[root@db2 libexec]# ./mysqld --verbose --help | grep -A 1 'Default options'
Default options are read from the following files in the given order:
/etc/my.cnf ~/.my.cnf /usr/local/service/mysql3306/etc/my.cnf

[root@db2 libexec]# ./mysqld --verbose --help | grep -A 1 'Default options'
Default options are read from the following files in the given order:
/etc/my.cnf ~/.my.cnf /usr/local/service/mysql3306/etc/my.cnf

my.cnf里加了innodb_data_file_path = ibdata1:10M:autoextend

然后建了一个表插入大量数据后，

du -sh ibdata1

43M

但是将该参数修改为：

innodb_data_file_path = ibdata1:43M;ibdata2:10M:autoextend

后重启数据库，抱错：

InnoDB: Error: data file /usr/local/service/mysql-3306/var/ibdata1 is of a different size
InnoDB: 2688 pages (rounded down to MB)
InnoDB: than specified in the .cnf file 2752 pages!
InnoDB: Could not open or create data files.
InnoDB: If you tried to add new data files, and it failed here,
InnoDB: you should now edit innodb_data_file_path in my.cnf back
InnoDB: to what it was, and remove the new ibdata files InnoDB created
InnoDB: in this failed attempt. InnoDB only wrote those files full of
InnoDB: zeros, but did not yet use them in any way. But be careful: do not
InnoDB: remove old data files which contain your precious data!
100611 1:22:55 [ERROR] Default storage engine (InnoDB) is not available
100611 1:22:55 [ERROR] Aborting

难道ibdata1实实在在是43M阿，为什么还报大小不对呢？奇怪！

然后我 ll ibdata1

-rw-rw---- 1 mysql mysql 44040192 Jun 11 01:27 ibdata1

然后把参数修改为：

innodb_data_file_path = ibdata1:44040192;ibdata2:10M:autoextend

然后重启数据库，发现数据库启动正常！