摘要：
我们知道,在Oracle数据库中,可以通过kill session的方式来终止一个进程,其基本语法结构为: alter system kill session ’sid,serial#’ ; 被kill掉的session,状态会被标记为killed,Oracle会在该用户下一次touch时清除该进程. 我们发现当一个session被kill掉以后，该session的paddr被修改... 阅读全文
摘要：
一。查看oracle数据库是否为归档模式： 1.select name,log_mode from v$database; NAME LOG_MODE ------------------ ------------------------ QUERY NOARCHIVELOG 2.使用ARCHIVE LOG LIST 命令 Database log... 阅读全文
摘要：
通过对典型的query和insert操作的测试，暂时能得出如下结论（可能会受mysql版本，机器配置的影响）： 关于query： 1. 100w是个无索引查询性能的分水岭。 2. 数据量在30w – 200w的区间，在索引高效的情况下，数据库数据量的变化，基本对查询不会产生明显的影响（这也跟查询原理相符） 3. 高效的索引，对查询速度的提高可能是数倍，甚至数十倍的！（这个... 阅读全文
摘要：
这是以前做的一个测试，拿出来给大家作为参考吧 测试表：mqqtest 测试表原始数据量：0 插入数据量：1000w 分三种方法插入作为对比参数： 1.create table as select 方式 2.insert into方式 3.insert /*+append*/ into方式 第一种方法由于是一个ddl操作，不需写回滚段，因此耗时在dbwr 第二种方法是一个dml操作，在默认情况下是... 阅读全文
摘要：
在试验中尝试了2种更新数据的方法： 1.update table set ... where ... 2. 先根据更新条件创建临时表，再删掉未更新之前的表，最后把临时表更名为原始表名 通过试验很明显的可以认识到update的效率是非常之低的。通过在网上跟其他oracle用户的讨论，也都一致的认为，大数据量更新应该采用第二种方法 被更新的表名：test_mt_sms 数据量：1500w左右(具体... 阅读全文
摘要：
通过关联订购关系这个操作做了一个关于join操作的试验。 以前采用上下行表直接关联，2个表数据量大约是2200w左右和1400w左右，并且2个表都是属于宽表，字段内容多，占用空间大，但join的时候用到的字段很少（2个左右），因此很多内存都耗在了存储不必要的字段值。每次关联操作耗时在2个小时以上。 通过细化join相关表后，首先减少了单表的数据元数目，并且只在细化表中只存储了join操作必须的字... 阅读全文
摘要：
众所周知，包括mysql文档上都这么写着：一个时间戳。范围是 '1970-01-01 00:00:00' 到 2037 年间的任意时刻。 但是根据最新发现，竟然不是从这个值开始的，而是从'1970-01-01 08:00:00开始的。看来搞mysql的这群人应该比我们提前1个小时上班^_^ 。不排除跟mysql版本和配置导致这个情况的可能性，借此抛砖引玉，希望能搞明白这个东东 测试版本： ver... 阅读全文