关注近期几起网站运维事故

最近看到几则新闻，都是和网站运营维护有关的，一个比一个离谱。

第一个是云网主站点不可访问。看新闻是从上午折腾到下午还没有修复。有趣的是出了故障之后云网居然把 IP 指向了 127.0.0.1。这是 8 月 9 号的事情。好像找不到云网任何官方对这次故障的说明，至少我没有找到。

第二个是关于工行的。8 月 15 号到 16 号，工行个人银行服务出现故障。据说是”由于15日是存款利息税下调、系统升级改造、新基金发行和拆分、养老金和工资的发放等业务集中所致”，更具体一点是什么原因，恐怕永远不得而知。要说起银行的 IT 系统建设，那可是天文数字啊。可以不夸张的说，硬件只挑贵的买。业务流程，什么标准化的东西，也都是早早建立起来的，但是，但是，但是，但是，还是不管用。

第三个，”当当当”, 当当网的数据库账户泄漏事件。程序出错页面居然把数据库连接串和密码什么的都打印出来了。不得不佩服一下。

点击查看出错页面的精彩图片

当当用的是 SQL Server.

网站的运维是个高精度而高复杂度的事情，远非弄一堆所谓的花哨流程、买一堆昂贵的机器所能解决一切问题的。

当然类似的事情也不止国内有，Facebook 不也出了个源代码泄漏的事故么。总算和国际接轨了。

最让人晕死的事情是今天 Dreamhost DNS 服务出现问题，导致我这个 Blog 10 来个小时不能访问。

–EOF–

OOW 会议之旅 (5 / End)

关于 Oracle Open World 的最后一篇。记录一些比较有趣的事情。

巧遇 Mugen 同学

第一天下午刚到会场的时候展厅还没有开放，偷着溜了进去。在 ITpub 的展台旁边停留了一会儿。偶然注意到登记簿上第一个会员签名居然是 Mugen。巧的是，转了一圈就看到了他。Mugen 告诉我，他上次考 OCM 就差一道题没有过，很是惋惜。线下的 Mugen, 一点都不向以前网络上的那个 Mugen 那么搞笑，他在 ITpub 上的经典句式”人才啊”让无数人笑倒。Mugen 的 Blog 写的还是挺好玩的，最近买房子那一篇很好看，真情实感。在杭州和他一起吃过饭的，但是总感觉还没有见过他。怪哉。

Biti_rainy 的 GPS 趣事

IT168 请会员吃饭，几十人的大聚餐。我和 Anysql(d.c.b.a) 两个人早早就出发了，出了地铁站走了好远，一身汗。可我们到了好久 Biti 他们才到。原来，他们开车找不到路，在他手里好好的 GPS，交给了 Kamus 就不管用，也不知道是不是盗版的问题，汗一个，在浦东绕了两圈还找不到地下通道入口，不得已开车回了宾馆，打了一辆出租车…

SAP 混进 Oracle 展会

美国那边 Oracle 和 SAP 视同水火，口水仗打的不可开交。可在中国好像不是那么一回事。SAP 在 Oracle Open World 有个展位的。大家看了都笑。

Sun(AMD?)展位的 起不来的 Solaris

Sun_kernel_panic.jpg

应该是 Sun 的展台。因为送的 T-shirt 是 Sun 的，可那件 T-shirt 是 2005 年活动剩下的，可真够节省的。

–EOF–

此文作者:, 位于 MyLife 分类 标签: , , on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.

Oracle 11g INVISIBLE index

oracle11g_logo.gif

这是我的 Oracle 11g 系列的文章之一.

在 Oracle 11g 以前的版本，在一个产品环境评估一个有待添加的索引是个麻烦事情。稍有不慎影响该表 SQL 执行计划走错，就可能带来灾难性的影响。这个问题可能也是 Oracle 比较重视的，在 11g 上新推出了 INVISIBLE 索引。这个索引创建后，默认对于 CBO 是不可见的。也就是说不会影响(抛开 DDL 时候的 SQL 重新解析)现有的 SQL 执行计划。如果要在 Session 级别激活这个索引，需要设置初始化参数: OPTIMIZER_USE_INVISIBLE_INDEXES .

创建 INVISIBLE 索引

注意新的关键字

SQL> CREATE INDEX emp_ename ON emp(ename)
  2        TABLESPACE users
  3        INVISIBLE;
Index created

USER_INDEXES 视图的新列 VISIBILITY

SQL> select INDEX_NAME ,VISIBILITY from user_indexes;
INDEX_NAME                                                   VISIBILITY
------------------------------------------------------------ ------------------
PK_DEPT                                                      VISIBLE
PK_EMP                                                       VISIBLE
EMP_ENAME                                                    INVISIBLE

观察执行计划的影响

SQL> select count(*) from emp where ename='ADAMS';

COUNT(*)
----------
         1
Execution Plan
----------------------------------------------------------

Plan hash value: 2083865914

---------------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      |     1 |     7 |     3   (0)| 00:00:01 |
|   1 |  SORT AGGREGATE    |      |     1 |     7 |            |          |
|*  2 |   TABLE ACCESS FULL| EMP  |     1 |     7 |     3   (0)| 00:00:01 |
---------------------------------------------------------------------------

告诉优化器使用 INVISIBLE 索引

SQL> alter session set OPTIMIZER_USE_INVISIBLE_INDEXES=true;

Session altered.

SQL> select count(*) from emp where ename='ADAMS';

COUNT(*)
----------
         1

Execution Plan
----------------------------------------------------------
Plan hash value: 1569421590

-------------------------------------------------------------------------------
| Id  | Operation         | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |           |     1 |     7 |     1   (0)| 00:00:01 |
|   1 |  SORT AGGREGATE   |           |     1 |     7 |            |          |
|*  2 |   INDEX RANGE SCAN| EMP_ENAME |     1 |     7 |     1   (0)| 00:00:01 |
-------------------------------------------------------------------------------

值得注意的是 VISIBILITY 索引在 Rebuild 后会变成可见索引：

SQL> select INDEX_NAME ,VISIBILITY from user_indexes;
INDEX_NAME                                                   VISIBILITY
------------------------------------------------------------ ------------------
PK_DEPT                                                      VISIBLE
PK_EMP                                                       VISIBLE
EMP_ENAME                                                    INVISIBLE

SQL> alter index EMP_ENAME rebuild;
=Index altered.

SQL> select INDEX_NAME ,VISIBILITY from user_indexes;

INDEX_NAME                                                   VISIBILITY
------------------------------------------------------------ ------------------
PK_DEPT                                                      VISIBLE
PK_EMP                                                       VISIBLE
EMP_ENAME                                                    VISIBLE
SQL>

这算是个 Bug 么? 还是本身的特性 ?

对于 INVISIBLE 索引，可以修改属性为 VISIBLE。正常的索引也可以修改为 INVISIBLE 状态。如果修改后仍然要使用这个索引，在语句中使用 HINT 即可。我就不一一演示了。

很多人都知道 Oracle 在 OEM 中早就实现了一个类似的功能：Virtual index(虚拟索引)。但是差别也是比较明显的。虚拟索引，真的是虚拟的，并不占用实际的磁盘空间。而 Invisible 索引需要占用磁盘空间。虚拟索引不可以 Alter ，而 Invisible 可以象正常索引那样进行一些维护工作。Invisible 索引的实现思路有些类似 Quest 以前的优化建议，也是直接会在数据库里面创建建议的索引，但是却不能屏蔽对 CBO 的影响。另外一个需要考虑的是 Virtual index 是 OEM 优化包 的功能，需要额外的 License (当然也可以用命令行创建)。

Invisible 对 DBA 来说，对 DBA 调优的时候多了一个更好的可选方法。

–EOF–

Oracle 11g 的 自动内存管理

oracle11g_logo.gif

这是我的 Oracle 11g 系列的文章之一.

Oracle 的 9i/10g 中已经对内存管理逐步做了很大的简化，11g 则更进一步，引入了一个新的概念自动化内存管理(Automatic Memory Management,AMM) . 如果 DBA 真的想偷懒的话，只需要设定两个参数就可以把烦心的事情都交给 Oracle 折腾了(只要 DBA 足够心宽)。PGA 与 SGA 一起搞定。这两个参数分别是：

MEMORY_TARGET--操作系统的角度上 Oracle 所能使用的最大内存值。动态参数
MEMORY_MAX_TARGET--MEMORY_TARGET所能设定的最大值。非动态可调。

Tip: 如果使用的是 pfile，设定了 MEMORY_TARGET 而没有指定 MEMORY_MAX_TARGET 的值，则实例启动后 MEMORY_MAX_TARGET 的值与 MEMORY_TARGET 相等。如果 pfile 中指定了 MEMORY_MAX_TARGET 而没有指定 MEMORY_TARGET ，实例启动后 MEMORY_TARGET 为 0 。

AMM 在后台会启动一个内存管理(Memory Manager, mman)进程。
因为 AMM 的引入，Oracle 内存管理更加灵活多样。 组合出来有 5 种内存管理形式.

  • 自动内存管理
  • 自动共享内存管理
  • 手工共享内存管理
  • 自动 PGA 管理
  • 手动 PGA 管理

1) 自动内存管理

默认安装的实例即是 AMM 方式。如下

SQL> show parameters target 
NAME                                 TYPE                   VALUE
------------------------------------ ---------------------- ------------------------------
archive_lag_target                   integer                0
db_flashback_retention_target        integer                1440
fast_start_io_target                 integer                0
fast_start_mttr_target               integer                0
memory_max_target                    big integer            1216M
memory_target                        big integer            1216M
pga_aggregate_target                 big integer            0
sga_target                           big integer            0

要注意到 SGA_TARGET 和 都为 0 。

2.自动共享内存管理(Automatic Shared Memory Management, ASMM)

这是 10g 引入的管理方式，要使用这种方式，需要设置初始化参数 MEMORY_TARGET=0 ，然后显式的指定 SGA_TARGET 的值。

SQL> alter system set sga_target=1024m scope=both;
alter system set sga_target=1024m scope=both
*
ERROR at line 1:
ORA-02097: parameter cannot be modified because specified value is invalid
ORA-00839: SGA_TARGET cannot be modified to the specified value
SQL> alter system set memory_target=0 scope=both;
System altered.
SQL> alter system set sga_target=1024m scope=both;
System altered.
SQL>

这两个参数的修改是有严格顺序的，如果不遵守倒也没问题–Oracle 会报告错误。

3.手工共享内存管理

这个又更加原始了一些。因为原始，所以新的初始化参数 SGA_TARGET 与 MEMORY_TARGET 都要设置为 0. 然后手工设定 share_pool_size 、db_cache_size 等 sga 参数。要注意 RESULT_CACHE_SIZE 参数是 11g 新引入的，用来缓存 SQL 结果。

4.自动 PGA　内存管理

如果使用 AMM ， 则对 PGA 不用操心。如果要做到精细控制而切换到自动 PGA　内存管理模式，需要设定WORKAREA_SIZE_POLICY ＝ AUTO(默认即为 AUTO)，然后需要指定 PGA_AGGREGATE_TARGET 的值。如需要精确控制PGA，则 WORKAREA_SIZE_POLICY ＝ MANUAL .(Thanks vongates)

5.手动 PGA 管理

前提是 WORKAREA_SIZE_POLICY = manual ,然后分别指定 SORT_AREA_SIZE 等 PGA 相关的参数。估计现在没有人干这个吃力不讨好的事情了。这个模式大可以忽略。

AMM 的限制

如果初始化参数 LOCK_SGA ＝ true ，则 AMM 是不可用的。

相关动态视图

V$MEMORY_DYNAMIC_COMPONENTS
V$MEMORY_RESIZE_OPS

11g 在简化 DBA 基本工作上还是下了很大功夫。可是这样也掩盖了一些技术细节，Oracle 正在逐步把内存的管理变成一个黑盒子，当然这也也是相关算法更加稳定作为基础的。总体来说，利大于弊。11g DBA, 准备好了没有?

–EOF–