It is recommended that a resizing procedure be tested before performing it on a filesystem that contains critical data. It is also strongly recommended that data backups are created and verified before resizing filesystems. To assist the reader in becoming familiar with the resizing procedure, the rest of this article describes a scenario in which un-partitioned disk space is used to test logical volume and ext3 filesystem resizing.

In this test procedure, first we create a new partition (/dev/hda2) using un-partitioned disk space. A new volume group (TestVG) and logical volume (TestLV) are then created using a physical volume created on the partition. An ext3 filesystem is then created on the logical volume, it is checked, and then mounted. A new physical volume (/dev/hda3) using the rest of the un-partioned disk space is then created and added to the volume group and logical volume. Finally, the filesystem on the logical volume is resized, and the integrity of the filesystem is checked.

In this test procedure, the parted, lvm, mount, mkfs.ext3, df, e2fsck and ext2online programs are used. The reader is encouraged to become familiar with these programs by consulting the manual pages. For example:

# man parted

PARTED(8)                          GNU Parted Manual          PARTED(8)

NAME
       GNU Parted - a partition manipulation program

SYNOPSIS
       parted [options] [device [command [options...]...]]
...

The parted and lvm programs can be run in either interactive or non-interactive mode. This article restricts all the examples to non-interactive modes. The reader is also encouraged to consult the parted and lvm online help available for all their built in commands to understand the command syntax for these programs.

Creating a new partition for the new physical volume

The parted program can be used to verify that un-partitioned disk space is available using the print command:

# parted /dev/hda print
Disk geometry for /dev/hda: 0.000-76318.054 megabytes
Disk label type: msdos
Minor    Start       End     Type      Filesystem  Flags
1          0.031    101.975  primary   ext3        boot
4      31118.093  76316.594  extended
5      31220.099  76316.594  logical   ext3        lvm
Information: Don't forget to update /etc/fstab, if necessary.

In this case the output of the parted print command shows that there is unallocated space between 101.975 (At the end of partition 1) to 31118.093 (The beginning of partition 4) on the /dev/hda device.

A new partition is created using only some of the available disk space, using the parted mkpart command, then the print command is used to verify:

# parted /dev/hda "mkpart primary 101.976 2500"
Information: Don't forget to update /etc/fstab, if necessary.

# parted /dev/hda print
Disk geometry for /dev/hda: 0.000-76318.054 megabytes
Disk label type: msdos
Minor    Start       End     Type      Filesystem  Flags
1          0.031    101.975  primary   ext3        boot
2        101.975   2502.312  primary   ext3
4      31118.093  76316.594  extended
5      31220.099  76316.594  logical   ext3        lvm
Information: Don't forget to update /etc/fstab, if necessary.

Create the new physical volume on the new partition

The lvm program is used to manipulate LVM2 volume groups, logical volumes and physical volumes. First use the lvm pvs command to list the physical volumes already present. Then the pvcreate command is used to create the new physical volume using the new partition, and the pvs again to verify the new physical volume:

# lvm pvs
  PV         VG         Fmt  Attr PSize  PFree
  /dev/hda5  VolGroup00 lvm2 a-   44.03G    0

# lvm pvcreate /dev/hda2
  Physical volume "/dev/hda2" successfully created

# lvm pvs
  PV         VG         Fmt  Attr PSize  PFree
  /dev/hda2             lvm2 --    2.34G 2.34G

  /dev/hda5  VolGroup00 lvm2 a-   44.03G    0

Create a new volume group for a new logical volume

When creating a new volume group, at least one physical volume must be available. That physical volume must be used to create the new volume group. Notice that a volume group called ‘VolGrouop00′ already exists:

# lvm vgs
  VG         #PV #LV #SN Attr  VSize  VFree
  VolGroup00   1   2   0 wz--n 44.03G    0

# lvm vgcreate TestVG /dev/hda2
  Volume group "TestVG" successfully created

# lvm vgs
  VG         #PV #LV #SN Attr  VSize  VFree
  TestVG       1   0   0 wz--n  2.34G 2.34G
  VolGroup00   1   2   0 wz--n 44.03G    0

Note that new volume groups must be activated using the lvm vgchange -a y command:

# lvm vgchange -a y TestVG
  0 logical volume(s) in volume group "TestVG" now active

Now there is a new directory in /dev for the volume group:

# ls -ld /dev/TestVG
drwx------  2 root root 60 Jan 17 17:48 /dev/TestVG

Create a test logical volume in the new volume group

In this case I wish to allocate all of the volume group’s physical extent (available disk space) to a new logical volume. First I use the lvm vgdisplay command to show details of the TestVG volume group:

# lvm vgdisplay TestVG
  --- Volume group ---
  VG Name               TestVG
  System ID
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  1
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                0
  Open LV               0
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               2.34 GB
  PE Size               4.00 MB
  Total PE              598
  Alloc PE / Size       0 / 0
  Free  PE / Size       598 / 2.34 GB
  VG UUID               ebStj9-3KYx-asoc-JBt3-N9kU-vONW-4VdpTB

The total free physical extent of the volume group is “Free PE / Size 598 / 2.34 GB”, so I will use the value 598 in the lvm lvcreate command to create the new logical volume:

# lvm lvs
  LV       VG         Attr   LSize  Origin Snap%  Move Copy%
  LogVol00 VolGroup00 -wi-ao 43.03G
  LogVol01 VolGroup00 -wi-ao  1.00G

# lvm lvcreate -l598 TestVG -nTestLV
  Logical volume "TestLV" created

# lvm lvs
  LV       VG         Attr   LSize  Origin Snap%  Move Copy%
  TestLV   TestVG     -wi-a-  2.34G
  LogVol00 VolGroup00 -wi-ao 43.03G
  LogVol01 VolGroup00 -wi-ao  1.00G

Now a new device has been added to the /dev/TestVG directory:

# ls -l /dev/TestVG
total 0
lrwxrwxrwx  1 root root 25 Jan 17 17:48 TestLV -> /dev/mapper/TestVG-TestLV

The new device is in fact a symbolic link to /dev/mapper/TestVG-TestLV which is the device node created by the device mapper.

Create a file system on the new logical volume

The new file system on the logical volume is created by using the mkfs.ext3 program:

# mkfs.ext3 /dev/TestVG/TestLV
mke2fs 1.35 (28-Feb-2004)
max_blocks 627048448, rsv_groups = 19136, rsv_gdb = 149
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
306432 inodes, 612352 blocks
30617 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=629145600
19 block groups
32768 blocks per group, 32768 fragments per group
16128 inodes per group
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912

Writing inode tables: done
inode.i_blocks = 7160, i_size = 4243456
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 35 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.

Then check the file system using e2fsck program:

#  e2fsck -f /dev/TestVG/TestLV
e2fsck 1.35 (28-Feb-2004)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/TestVG/TestLV: 11/306432 files (9.1% non-contiguous), 18728/612352 blocks

Mount the new file system

Before mounting the new file system , I create a new mount point, then mount the new logical volume’s file system on that mount point. After mounting the file system, I ran the df program to verify the disk space available:

# mkdir /mnt/test
# mount /dev/TestVG/TestLV /mnt/test

# df -h /mnt/test
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/TestVG-TestLV
                      2.3G   36M  2.2G   2% /mnt/test

The resize test procedure

This is the general procedure to resize a filesystem. Begin by adding a new physical volume.

Create a new partition that will contain a new physical volume

Using parted as before, I run the print command to view the partitions, and then mkpart to create a new partition:

# parted /dev/hda print
Disk geometry for /dev/hda: 0.000-76318.054 megabytes
Disk label type: msdos
Minor    Start       End     Type      Filesystem  Flags
1          0.031    101.975  primary   ext3        boot
2        101.975   2502.312  primary   ext3
4      31118.093  76316.594  extended
5      31220.099  76316.594  logical   ext3        lvm
Information: Don't forget to update /etc/fstab, if necessary.

There is un-partitioned disk space available between 2502.312 (The end of partition 2) and 31118.093 (The beginning of partition 4):

# parted /dev/hda "mkpart primary 2502.313 31118.092"
Information: Don't forget to update /etc/fstab, if necessary.

# parted /dev/hda print
Disk geometry for /dev/hda: 0.000-76318.054 megabytes
Disk label type: msdos
Minor    Start       End     Type      Filesystem  Flags
1          0.031    101.975  primary   ext3        boot
2        101.975   2502.312  primary   ext3
3       2502.312  31118.093  primary
4      31118.093  76316.594  extended
5      31220.099  76316.594  logical   ext3        lvm
Information: Don't forget to update /etc/fstab, if necessary.

Create the physical volume

The new physical volume is created as before, by running the lvm pvcreate command. The new physical volume will be on /dev/hda3:

# lvm pvs
  PV         VG         Fmt  Attr PSize  PFree
  /dev/hda2  TestVG     lvm2 a-    2.34G    0
  /dev/hda5  VolGroup00 lvm2 a-   44.03G    0

# lvm pvcreate /dev/hda3
  Physical volume "/dev/hda3" successfully created

# lvm pvs
  PV         VG         Fmt  Attr PSize  PFree
  /dev/hda2  TestVG     lvm2 a-    2.34G     0
  /dev/hda3             lvm2 --   27.94G 27.94G
  /dev/hda5  VolGroup00 lvm2 a-   44.03G     0

Add the physical volume to the volume group

The physical volume is added to the TestVG volume group using the lvm vgextend command:

# lvm vgextend TestVG /dev/hda3
  Volume group "TestVG" successfully extended

# lvm pvs
  PV         VG         Fmt  Attr PSize  PFree
  /dev/hda2  TestVG     lvm2 a-    2.34G     0
  /dev/hda3  TestVG     lvm2 a-   27.94G 27.94G
  /dev/hda5  VolGroup00 lvm2 a-   44.03G     0

Extend the logical volume in the volume group

As before, first look at the physical extent of the volume group using the lvm vgdisplay command. It shows that TestVG has 7153 free extents in “Free PE / Size 7153 / 27.94 GB”:

# lvm vgdisplay TestVG
  --- Volume group ---
  VG Name               TestVG
  System ID
  Format                lvm2
  Metadata Areas        2
  Metadata Sequence No  3
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                1
  Open LV               1
  Max PV                0
  Cur PV                2
  Act PV                2
  VG Size               30.28 GB
  PE Size               4.00 MB
  Total PE              7751
  Alloc PE / Size       598 / 2.34 GB
  Free  PE / Size       7153 / 27.94 GB
  VG UUID               ebStj9-3KYx-asoc-JBt3-N9kU-vONW-4VdpTB

I wish to use all the free physical extents on the volume group. I do this using the lvm lvextend command with the option -l+7153 . This adds the 7153 free extents to the logical volume:

# lvm lvextend -l+7153 /dev/TestVG/TestLV
  Extending logical volume TestLV to 30.28 GB
  Logical volume TestLV successfully resized

The file system now has space on the logical volume in which to grow.

Resize the file system

After extending the volume group and the logical volume, it is now possible to resize the file system. This is done using ext2online. First I verify the file system size, perform the resize, and then verify the size again:

# df -h /mnt/test
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/TestVG-TestLV
                      2.3G   36M  2.2G   2% /mnt/test

# ext2online /dev/TestVG/TestLV
ext2online v1.1.18 - 2001/03/18 for EXT2FS 0.5b

# df -h /mnt/test
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/TestVG-TestLV
                       30G   39M   29G   1% /mnt/test

Check the file system integrity after the resize

The file system should be un-mounted before doing a file system check:

#  e2fsck -f /dev/TestVG/TestLV
e2fsck 1.35 (28-Feb-2004)
/dev/TestVG/TestLV is mounted.

WARNING!!!  Running e2fsck on a mounted filesystem may cause SEVERE filesystem damage.

Do you really want to continue (y/n)? no

check aborted.

# umount /mnt/test

#  e2fsck -f /dev/TestVG/TestLV
e2fsck 1.35 (28-Feb-2004)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/TestVG/TestLV: 11/3919104 files (9.1% non-contiguous), 132827/7937024 blocks

Conclusion

The procedure to test online resizing of filesystems is quite complex. So it is important to practice the procedure and become familiar with the programs and commands. Once this is done, and reasonable precautions such as backing up important data are taken, it should be safe to resize your filesystems.

Red Hat’s customer service and support teams receive technical support questions from users all over the world. Red Hat technicians add the questions and answers to Red Hat Knowledgebase on a daily basis. Access to Red Hat Knowledgebase is free. Red Hat Magazine offers a preview into the Red Hat Knowledgebase by highlighting some of the most recent entries. The information provided in this article is for your information only. The origin of this information may be internal or external to Red Hat. While Red Hat attempts to verify the validity of this information before it is posted, Red Hat makes no express or implied claims to its validity.

dbanotes posted a photo:

dbanotes posted a photo:

dbanotes posted a photo:

dbanotes posted a photo:

dbanotes posted a photo:

dbanotes posted a photo:

dbanotes posted a photo:

修的并不是很难看

dbanotes posted a photo:

dbanotes posted a photo:

dbanotes posted a photo:

dbanotes posted a photo:

上图为一容灾架构图，p_db01和p_db02为用于做双机热备（SG/MC）的生产数据库，p_db01为主库，p_db02为备库，同连在生产数据库的存储eva 6100上；在eva 6100 的存储上做BC。

eva 5k为用于容灾的异地存储，利用CA与eva 6100进行实时同步。db3和db4连在eva 5k上，db3和db4数据库是另外的数据库，但是也利用了eva5k的部分存储。也就是说，eva 5k的部分存储用于CA，部分存储用于另外两个生产数据库。

同时，我们在eva 5k上也进行本地的BC。

综上所述，我们的生产数据库的数据有4份备份：一份是eva 6100上实际用于生产，一份是eva 6100上的通过BC做的mirror clone；一份是在远程的eva 5k上的通过CA实时同步的，一份是在远程对CA的数据再次进行BC是snapshot。

下面对BC和CA技术做一简单的介绍。

一、BC一般用于重要数据的本地备份和快速恢复，是非实时的数据备份。EVA的数据BC有三种方式：
（1）Snapshot：对Vdisk建立某个时间点的复制，该复制盘能给主机使用。但复制盘只是源盘的一个链接当源盘遭到破坏时snapshot也不可用。
（2）Snapclone：对Vdisk建立某个时间点的复制，该复制盘能给主机使用。复制盘是一个独立的盘当源盘遭到破坏时snapclone盘也可用。
（3）Mirrorclone：对Vdisk进行同步镜像复制，该复制盘和源盘时刻保持数据一致。在同步期间不能给主机使用只有源盘出故障或断开同步复制该复制盘才能给主机访问。
其中，mirrorClone可以使用增量备份，因此我们在CA的基础上，可以在主存储采用Mirror Clone本地再做一份备份。每天备份一个时间点用于做灾难恢复（只能恢复至mirror的时间点）。

二、CA不支持Destination端（即远程的存储）的mirrorclone，一般使用snapshot。 使用snapshot必须在一个diskgroup内。
（1）CA的同步模式：
在CA的同步模式，主EVA6K的数据与远端备份EVA5K的数据保持一致，每一次的数据写是在主/备EVA的数据写都完成后，才确认该次数据写完成。
在设置CA软件同步复制时，“Fence level”是指远程镜像数据保护的级别，包括：
（1.1）Data : 保证主EVA的数据和备份EVA的数据完全一致，当对远端EVA的数据写操作失败时，整个数据写失败。
（1.2）Never : 当对远端EVA的数据写操作失败时，主EVA5K将自动断开磁盘镜像，继续进行数据的读写操作，并建立变化数据的bit map，当镜像重新同步时，保证将发生变化的数据拷贝到远端EVA。
（2）CA的异步模式：
在CA的异步模式，对主EVA5K的数据进行立即读写并按循序拷贝远端备份EVA5K；每一次数据写是当主EVA5K的数据写完成后，即确认该次数据写完成；在设置CA软件异步复制时，“Fence level”设置为“async”。

三、生产库存储（eva 6100）备份恢复过程：
备份过程：
（1）预定时间点冻结数据库（数据库处于备份状态，即alter tablespace tablespace_name begin backup）；
（2）解开生产数据vdisk和备份数据的mirror关系；
（3）数据库解冻结（end backup）；
（4）下一个备份时间前一小时重新同步（resync mirror Clone），使备份数据和生产数据重新同步；
（5）循环回第一步；
恢复过程：
当源vdisk出故障时解开数据盘的mirror clone关系，把备份盘放给主机使用。

远程存储（eva 5k）的备份恢复过程：
备份过程：
（1）在预定的时间点冻结数据库（将所有表空间置于backup模式）；
（2）建立snapshot备份；
（3）解冻结数据库（end backup）；
（4）删除上一次的snapshot备份；
（5）循环回第一步；
恢复过程：
（1）Present备份的snapshot盘到主机验证数据；
（2）删除CA关系；
（3）restore备份数据到eva 5k；
（4）反向CA复制，恢复数据到eva 6100

四、容灾场景：
场景一

（1）生产数据库发生故障，或者错误操作，需要利用mirror clone将数据库恢复至前一天的数据：
思路：我们可以用p_db02连至mirror clone的存储，来进行恢复。
（1.1）断开p_db01和p_db02的MC关系
（1.2）执行基于BC数据卷的拆分脚本
（1.3）通过ioscan找到新Present的BC卷
（1.4）做对应VG的export和import
（1.5）修改vg的用户权限
（1.6）激活相关VG
（1.7）启动数据库
sqlplus ” /as sysdba”
SQL>STARTUP NOMOUNT
SQL> recover database until cancel;
–指定当前的redo log文件为恢复的archive log
SQL> alter database open resetlogs;

猜想：此时如果存储部分如果包含active或者current的redolog crash掉，将不能完全恢复。

 

场景二

（2）生产数据库发生故障，或者错误操作，且eva 6k上的mirror clone不可用，需要利用远程的snapshot将数据库恢复至前一天的数据：
（2.1）断开p_db01和p_db02的MC关系
（2.2）执行基于BC数据卷的拆分脚本，将Snapshot卷present到主机上
（2.3）通过ioscan找到新Present的BC卷
（2.4）做对应VG的export和import
（2.5）修改vg的用户权限
（2.6）激活相关VG
（2.7）启动数据库
sqlplus ” /as sysdba”
SQL>STARTUP NOMOUNT
SQL> recover database until cancel;
–指定当前的redo log文件为恢复的archive log
SQL> alter database open resetlogs;

猜想：此时如果存储部分如果包含active或者current的redolog crash掉，也将不能完全恢复。

 

场景三

（3）eva 6k存储完全故障，且修复需要一定的时间，为恢复生产，保证系统高可用，需要启用远程的CA的存储：
（3.1）停生产卷数据库；
（3.2）执行基于基于CA的存储复制关系切换脚本
（3.3）通过ioscan找到EVA5000上Present的CA卷
（3.4）做对应VG的export和import
（3.5）修改vg用户权限
（3.6）激活相关VG
（3.7）启动数据库
sqlplus ” /as sysdba”
SQL>STARTUP
（3.8）验证切换至EVA5000的数据库
（3.9）将数据库改为双机模式
（3.10）数据库建立测试数据
（3.11）假设EVA6100已经修复Resume和EVA6100的连接实现反向copy；（EVA5000复制到EVA6100）
（3.12）停MC
（3.13）通过command view failover 主存储到EVA6100；
（3.14）通过做IOSCAN等做数据库VG重新导入
（3.15）启动数据库
（3.16）验证数据库
（3.17）恢复双机环境
（3.18）恢复业务

    今天开了五年陈员工大会，马云和各个子公司的CEO讲了些话，其中一些很有感触。

    1、不后悔昨天所做的事情：这和我自己的做事风格一样，你永远也无法拿今天的心境和环境和昨天的相提并论，所以怀念昨天并后悔是很愚蠢的。

    2、乐观向前看，做新员工的踏脚石：一直保持乐观是件很难的事情，我们需要努力做到，对于我来说没有什么老不老的，心态很重要，我们需要有能力的人，并培养他们给他们机会。

    3、没有人能为你规划，自己规划自己吧，公司也一样，老马遍寻名师和名书也没有找到答案，很多也不靠谱，最靠得住的是最熟悉公司的自己。需要学习老马的探索精神。

    说的太多，记不住，看看会后有谁有记录的，再回味回味！

No TagsNo Tags

In a major change to the Oracle security advisory process and Critical Patch Update documentation, CVE identifiers are now used in place of the Oracle proprietary numbering scheme (i.e., DB01, AS01, APP01, etc.).  Common Vulnerabilities and Exposures (CVE) is a standardized dictionary and identifiers of published security advisories.  The purpose of CVE is to provide a single identifier for security vulnerabilities so that vendors, tools, and organizations can all refer to the same vulnerability with a single identifier.  The format of the CVE identifier is (1) a fixed "CVE" to indicate it is a CVE identifier, (2) the year (i.e., 2008), and (3) a sequential number of when the entry was added to CVE (i.e., 2607).  As an example, the first database vulnerability is CVE-2008-2607.

The previous Oracle proprietary numbering scheme had several issues in relationship to CVE numbering -

1. Oracle provided a mapping to previously released vulnerabilities only for those vulnerabilities in core components like Apache and OpenSSL.  No mapping was provided for previously publicly disclosed vulnerabilities, so there are cases when the same vulnerability has two CVE identifiers.
   
2. A single CVE identifier was usually assigned to multiple vulnerabilities in an almost arbitrary fashion.  This meant that a CVE identifier might include vulnerabilities from multiple components and in the case of the Oracle E-Business Suite across multiple patches.  For Integrigy, this caused problems with our vulnerability scanning tool, AppSentry, since our reports have to handle many-to-many mappings when dealing with CVEs, patches, and vulnerabilities.
   
3. The CVE numbers were usually assigned 1-2 days after the Oracle release.

The CVE identifiers in the Oracle advisory does use a single CVE identifier per vulnerability and maps directly to previously disclosed vulnerabilities (see CVE-2007-1359).  Although it would have been nice if Oracle had included hyperlinks in the advisory to either CVE or NVD for easier access.  It will be interesting to see if CVE-2007-1359 is fixed in this CPU as either CVE-2008-2589, CVE-2008-2594, or CVE-2008-2609, which would reduce the effectiveness of using the CVE identifiers and again result in duplication of vulnerabilities in CVE if CVE identifiers for previously disclosed vulnerabilities are not used.

Using the CVE Identifiers

Additional information on vulnerabilities can be found either in the CVE or the National Vulnerability Database (NVD) sponsored by the Department of Homeland Security.  NVD contains the most detailed information including a break-down of the CVSS2 score and links to external references that may have more information on the vulnerability.  The typical process is that a generic NVD is created with only a reference to the original Oracle advisory.  When there is public disclosure with additional details on the vulnerability, the NVD entry is updated with links to those disclosures.  This process should be much more timely and accurate as most public disclosures will now include the CVE identifier.  Usually, about 30% of the vulnerabilities per quarter will have additional information and the database vulnerabilities typically have more information than the other products.

An example of a fully populated entry is the ModSecurity vulnerability that was previously fixed in ModSecurity 2.1.1 -

http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-1359

An example of an entry with additional details is the buffer overflow in the Oracle AQ package SYS.DBMS_AQELM -

http://nvd.nist.gov/nvd.cfm?cvename=CVE-2008-2607

Shared by Fenng
疾如风、徐如林、侵略如火、不动如山、难知如阴、动如雷

以往的影视作品中，很少看见对阵法的描写。对中国人而言，评书中描写的阵法都带有玄幻色彩，比如杨家将中的天门阵，是一个妖道布下的魔幻阵法，军队进入阵中就­会遭遇飞沙走石等超自然现象，需要找到降龙木一类的法宝方能克敌制胜。

其实，阵法是古代战争不可或缺的作战形式，所谓的行军布阵，行军就是指军队行进到战区的状态，而布阵就是到了战区之后展开作战状态。

影片《赤壁》用了很大篇幅描述古代阵法作战，这在中国电影史上是非常罕见的。冷兵器时代的战争并不是街头混混斗殴，大家拿着刀枪冲上去一阵砍杀，人多势众下手狠毒的就能胜利。在战争中，战斗双方必须要组成战阵，才能发挥各种兵器的优势，说白了就是一大群人如何更有效地发挥自己武器的特长杀死敌人，而好的阵法往往能以寡敌众。博闻网的这篇文章将为您揭开《赤壁》中阵法的作用。

古代阵法的讲究
古人布阵是很有讲究的，一般来说布阵主要得考虑以下几种要素：

• 指挥官的位置
• 阵中兵器的排列分布
• 各兵种的行进速度差异应该如何搭配
• 布阵的地形是否利于兵力展开
• 敌军的武器和兵种以及训练程度

指挥官一般需要处于一个便于观察指挥但是不容易受到攻击的位置。例如，如果是圆阵的话，指挥官应该处于中心位置可以环顾四周，又能受到足够保护。弓箭手、火枪手这类无法肉搏的兵种必须要有长矛手之类其他步兵的保护。在行进的过程中，阵型的要求必须是各分队间既能够相互掩护，而且还不能互相阻碍。例如，骑兵在行进的状态下往往在主阵的两翼行进，这样，一旦需要进入攻击状态，骑兵分队不会被前边步兵挡住去路。不同的队形要有不同阵法配合，而对付不同的兵种也要用相应的阵法。

一只训练有素的军队的标志就是阵型熟练。孙子兵法中强调的六如（疾如风、徐如林、侵略如火、不动如山、难知如阴、动如雷霆）其实就是要说明阵法操练的最高境界。强大的军队除了要能够把阵型排得整整齐齐之外，还要做到行军的时候阵型不乱，面对强敌冲锋的时候阵型不散，进攻敌军的时候迅速但是阵型不疏。面对不同敌情和地形的时候，阵型能够快速变换。具备这样的条件才是真正的精兵劲旅。

赤壁中又有哪些阵法？请继续阅读

Shared by Herock
用这办法去玩完后，想回北京时该说什么？

某白领接到客户紧急通知，让他第二天到长春签单，于是他急忙订票，发现当天的火车票已经没了，机票也只剩85折的了（公司最多报5折），正在郁闷间，另一个和他关系不错的同事过来伏耳道："......放心吧，我一直都是这么干的！"

于是当日下午，该白领把打印机下一摞打废的A4纸钉在一起，然后打车到国家信访局门口，下车就举着废纸大喊：“长春现在民不聊生啊！”说时迟那时快，一辆依维柯出现在他面前，一群人以迅雷不及掩耳盗铃之势把他推上了车，然后连夜送到长春，一路上管了顿饭还没要钱......

同理，你可以套用说：“贵阳现在民不聊生啊！”，于是有人免费送你去看黄果树；你也可以说：“绵阳现在民不聊生啊！”，于是有人免费送你去看大熊猫；如果你是指尖沙妹妹，远在美国想回祖国探亲，还可以跑到中国驻华盛顿大使馆试一试说：“美国现在民不聊生啊！”，或许有人免费送你到北京看奥运会了。



容我说点陈年往事。 去年的软件产业的数据，尽可能直观的说说，欢迎大家指正。

去年软件产业的总收入5800亿，增长20.8%。就相当于软件产业的GDP是5800亿，占中国总GDP的1/40。假设总共从业人数为140万（大概就是这个数），所以软件行业的人均GDP，就是41万元，是人均GDP的22倍。

按照记者的口气是，从某某大会获悉，2007年软件产业产值已经达5800亿。实际上根本不用去开会，这些数据都能第一时间看到。去年的数据，在信息产业部的网站上，2008年2月3日就出来了，链接见本文最后。

我第一时间看了，幸好当时没写blog，否则就闹笑话了。我把“教训”总结一下。 我当时拿excel加了一下，整整11600亿，1.16万亿啊，当时是有点吃惊了，差不多就是中国总GDP的1/20了。 最近终于从这个错误中反应过来了。你们可以看看，第一列是“软件业务收入”，实际上这是后面的总计。后面的“软件产品收入”“系统集成收入”都是属于分类的统计了。不过这几列，都没有任何直观上的区分，容易弄混，还算情有可原。

回到正题，软件产业在地域上，相当的集中。看看2007年的数据，北京占了21.8%，广东16.9%，江苏，14.35%，上海8.5%。 北京和我想象的差不多。江苏比想象的多，上海比想象的少，不太明白其中的原因。

以下摘录了2007年的前12名，单位亿元。合计 5800.1 北京市 1263.1 广东省 981.2 江苏省 832.4 上海市 494 浙江省 354.3 山东省 302.9 四川省 240.2 辽宁省 234.1 福建省 220 陕西省 144.8 吉林省 93 湖南省 78

其实数据仅仅是问问题的起点。比如，和其他国家横向的比较也很有意义。可惜我还没有找到太多详细的数据，其实本文有点想抛砖引玉的意思，欢迎更多的数据和分析。

具体数据请参照 http://www.miit.gov.cn/art/2008/02/03/art_5104_47694.html
更多的相关数据 http://www.miit.gov.cn/col/col5104/index.html

在他所在的技术部试图开除他后，这位不满的软件工程师劫持了旧金山新的、花费了数百万美元建立计算机系统。除了自己的帐号外，他禁止了所有的管理密码。43岁的网管Terry Childs已被拘留，他拒绝提供密码，技术部只能恢复他们自己的电脑管理访问权。他们担心Childs或他的同伴可能破坏会数十万的敏感文档，包含电子邮件，工资信息，法律执行文档。

在Linux 2.6.25.10稳定版发布的邮件列表上，一位开发者提到了关于修正bug安全影响的披露政策，并再三的强调安全。Linus Torvalds回贴中表示，安全漏洞臭虫只是众多臭虫的一种，过于拔高或赞美安全臭虫的修正者是走在错误的方向上。Linus大神称那帮整天炫耀OpenBSD安全性的家伙其实是一群自慰的猴子，好像除了安全性，没有其它东西能让他们兴奋起来。安全是重要的，但不等于一切。

Shared by Fenng
不知道有人收购我的 dbanotes.net 么? 笑

在全球最发达的传媒地美国正在席卷着一股风潮：收购博客。与前几轮博客网站获得风险投资不同，这轮收购大潮是由权势传统媒体发起的，而此前它们是多么的不屑。

7月11日，消息人士透露，英国卫报传媒集团将以超过3000万美元收购知名科技博客网站paidContent。刚刚过去的5月，《连线》杂志母公司已经宣布2500万美元收购消费电子类报道博客Ars Technica。现在又有消息说，AOL计划拿3000万美元买下TechCrunch。

除了收购，其实过去半年多时间里，传统媒体引入博客网站内容的举动也不少，只不过没有引起太多关注，趁机会简单回顾下：1，WashingtonPost宣布与techcrunch结盟，引入其博客内容；今天看到Om Malik说，GigaOM的内容将会出现在BusinessWeek.com上。

除了收购、合作，其实还有打压者。

当属著名的AP（美联社）。美联社首次提出第三方如何在不侵权的情况下，引用其新闻文章的原则。此举主要针对的是行事向来自由的博客圈，他们常常大段引用美联社的新闻。美联社少见地采取强硬措施，致信给博客网站Drudge Retort，要求其撤下七篇博客文章。

我想强调的是：无论是收购合作还是打压，都证明了博客网站（media）作为一种有商业价值的媒体平台的存在，这也间接证明了博客作为一种内容写作方式对传统媒体所带来的冲击；博客网站正在不同的垂直细分领域瓜分着传统大报的读者，碎片化，再中心化。

至于博客媒体存在的诸如过分依赖于人的问题，留给时间去解决吧。

粗略去挖掘支撑博客网站平台运行的要素，无碍乎媒体存在的两个端子：内容和广告。在内容上，博客media满足了细分人群的内容需求，同时又极具互动的亲近感，跟作者貌似人对人的交流是传统媒体永远都做不到的；

在广告上，博客media实现精准的定位和交互，这也是我在上周提出“2.0社会化营销加速”的一个论据。显然，社会化媒体的崛起和获认可，是社会化营销崛起的前提。当然，社会化媒体的形式还有很多，除了Digg、techmeme，还有facebook、LinkedIn、MySpace,、Bebo，还有Twitter、friendfeed等等，本质则是信息流的控制。

预告下：我最近有精力会写下“博客会话”，我认为是SNS与博客争论的核心。

Shared by Fenng
T-Shirt 还有没？

再次发下，历时一个多月，从设计到制作，我们选的是170克莱卡棉，40支，白色丝网，黑色烫金，收腰版型（胖子有些不适合，不过我们ued没很胖的，呵呵），白色的我们作为赠品，黑色的我们自己穿，图案作了很多，最终大家选择了这个，印有我们的五个职位。




其他设计秀：

Bryce Harrington最近对UI的主流做法提出了质疑，他认为“现今流行的、以文档编制概念为基础创建的UI范式”并不符合大多数人使用计算机的目的。实际上他是主张，知识型工作者更多的是处理信息流，而非传统的文档

Shared by QienKuen
反正是照做了，不知之前和之后的区别是啥。

虽然 Firefox 3 相比 Firefox 2 在执行效能上有了很大的进步，但时间用长了还是让人颇有一种执行缓慢的感觉。OK，那就让我们来做一些优化，使 Firefox 3 运行更快些吧。

减少 Awesome Bar 显示数量

Firefox 3 新引入的 Awesome Bar 功能，我真的是很喜欢。我只需输入极少的字便能获得想要打开网页的建议。对我来说，默认的 Awesome Bar 显示数量似乎有些偏多。它经常要在停顿一小会儿后，才能完全显示出来。为了改善这个问题，我们可以通过减少 Awesome Bar 的显示数量来解决。具体操作步骤如下：

1. 在 Firefox 地址栏输入“about:config”，在确认警告信息后进入 Firefox 配置页面。
2. 在 Filter 过滤框输入“browser.urlbar.maxRichResults”（或直接复制）。
3. 我们可以看到 Awesome Bar 默认的显示数量是 12。双击该条目可以更改为自己想要显示的数目。当我设置为 5 后，这种停顿的现象终于消失了。

增大磁盘缓存容量

随着 Firefox 打开的页面愈加增多，Firefox 似乎也变得有些迟钝起来。如果你担心 Firefox 同时会吃掉更多的系统内存，让其他程序无容身之地，那么可以增大 Firefox 的磁盘缓存容量。具体操作步骤为：

1. 地址栏输入“about:config”，并进入其配置页面。
2. Filter 过滤框输入“browser.cache.disk.capacity”。
3. Firefox 默认的磁盘缓存容量为 50000，也就是 50000 KB。假如你的系统内存在 512 MB 至 1 GB 之间，不妨将该值调大些，如设成“150000”。

让 Firefox 在最小化时释放内存

当 Firefox 最小化时，我们可以让它把占用的部分内存释放出来以供其他程序使用。具体操作步骤为：

1. 在地址栏输入“about:config”进入其配置页面。
2. 右击点选“New->Boolean”。
3. 在打开的对话框中输入“config.trim_on_minimize”。
4. 点击 OK 后，接着选择 true。
5. 重启 Firefox。

Filed under: Tips | Permalink | Add to del.icio.us | Email this | 19 comments

本文将介绍 AIX 上的系统资源控制器相关的各方面内容，如基本概念、配置、启动、修改以及一些常用的子系统的介绍。本文是摘自 IBM 红皮书《IBM Certification Study Guide - pSeries AIX System Administration》。

早上哪吒弹出来的消息有一半都是关于Twitter 收购Summize的，虽然交易细节不会公布，但是这宗显然不大的收购事件确实让人们都很关注。原因很简单，Twitter的核心架构已经越来越完善（希望如此），正在走向外围的各种服务，并期待产生更多的商业模型。

这是一个典型的技术趋势驱动的创业案例。从最早的试验产品到如今，我不仅是用户，还和Twitter团队进行实际的交流，已经看到这个大趋势的形成。过去人们还在着急Twitter 如何能够盈利，其实完全不必担心，因为这个核心计算模式的形成，会在周边形成大量的混搭应用。而这些混搭应用创造的情景已经可以和真实世界刹那生经济往来，这意味着盈利。

那么多次大家对Twitter都能够容忍它的速度、当机、乱套，都是因为其中隐藏的巨大诱惑力，那就是普世的“思想外泄”(Leak of Mind)。只有思想不断地泄露，才会有分享主义，才会产生社会性媒体的密集管道，才会形成巨大的微经济生态体系，微观的共同人性会有大数效应。围绕Twitter这个吸引子的商业应用会逐步外旋到各个领域，也会出现无数的新分裂（例如最近也很红火的Plurk)。关键的问题是如何打造一个技术服务架构，让未来能够更加稳固，这一点Twitter做的不算差。未来围绕Twitter应用的投资大幕还会进一步拉开...

dbanotes posted a photo:

估计这封邮件还是比较能够迷惑人的

以往的影视作品中，很少看见对阵法的描写。对中国人而言，评书中描写的阵法都带有玄幻色彩，比如杨家将中的天门阵，是一个妖道布下的魔幻阵法，军队进入阵中就­会遭遇飞沙走石等超自然现象，需要找到降龙木一类的法宝方能克敌制胜。

其实，阵法是古代战争不可或缺的作战形式，所谓的行军布阵，行军就是指军队行进到战区的状态，而布阵就是到了战区之后展开作战状态。

影片《赤壁》用了很大篇幅描述古代阵法作战，这在中国电影史上是非常罕见的。冷兵器时代的战争并不是街头混混斗殴，大家拿着刀枪冲上去一阵砍杀，人多势众下手狠毒的就能胜利。在战争中，战斗双方必须要组成战阵，才能发挥各种兵器的优势，说白了就是一大群人如何更有效地发挥自己武器的特长杀死敌人，而好的阵法往往能以寡敌众。博闻网的这篇文章将为您揭开《赤壁》中阵法的作用。

古代阵法的讲究
古人布阵是很有讲究的，一般来说布阵主要得考虑以下几种要素：

• 指挥官的位置
• 阵中兵器的排列分布
• 各兵种的行进速度差异应该如何搭配
• 布阵的地形是否利于兵力展开
• 敌军的武器和兵种以及训练程度

指挥官一般需要处于一个便于观察指挥但是不容易受到攻击的位置。例如，如果是圆阵的话，指挥官应该处于中心位置可以环顾四周，又能受到足够保护。弓箭手、火枪手这类无法肉搏的兵种必须要有长矛手之类其他步兵的保护。在行进的过程中，阵型的要求必须是各分队间既能够相互掩护，而且还不能互相阻碍。例如，骑兵在行进的状态下往往在主阵的两翼行进，这样，一旦需要进入攻击状态，骑兵分队不会被前边步兵挡住去路。不同的队形要有不同阵法配合，而对付不同的兵种也要用相应的阵法。

一只训练有素的军队的标志就是阵型熟练。孙子兵法中强调的六如（疾如风、徐如林、侵略如火、不动如山、难知如阴、动如雷霆）其实就是要说明阵法操练的最高境界。强大的军队除了要能够把阵型排得整整齐齐之外，还要做到行军的时候阵型不乱，面对强敌冲锋的时候阵型不散，进攻敌军的时候迅速但是阵型不疏。面对不同敌情和地形的时候，阵型能够快速变换。具备这样的条件才是真正的精兵劲旅。

赤壁中又有哪些阵法？请继续阅读

Shared by Fenng
对于 Memcached 来说，已经没有任何秘密可言

下面是《memcached全面剖析》的第三部分。

发表日：2008/7/16
作者：前坂徹(Toru Maesaka)
原文链接：http://gihyo.jp/dev/feature/01/memcached/0003

memcached是缓存，所以数据不会永久保存在服务器上，这是向系统中引入memcached的前提。 本次介绍memcached的数据删除机制，以及memcached的最新发展方向——二进制协议（Binary Protocol） 和外部引擎支持。

memcached在数据删除方面有效利用资源

数据不会真正从memcached中消失

上次介绍过， memcached不会释放已分配的内存。记录超时后，客户端就无法再看见该记录（invisible，透明）， 其存储空间即可重复使用。

Lazy Expiration

memcached内部不会监视记录是否过期，而是在get时查看记录的时间戳，检查记录是否过期。 这种技术被称为lazy（惰性）expiration。因此，memcached不会在过期监视上耗费CPU时间。

LRU：从缓存中有效删除数据的原理

memcached会优先使用已超时的记录的空间，但即使如此，也会发生追加新记录时空间不足的情况， 此时就要使用名为 Least Recently Used（LRU）机制来分配空间。 顾名思义，这是删除“最近最少使用”的记录的机制。 因此，当memcached的内存空间不足时（无法从slab class 获取到新的空间时），就从最近未被使用的记录中搜索，并将其空间分配给新的记录。 从缓存的实用角度来看，该模型十分理想。

不过，有些情况下LRU机制反倒会造成麻烦。memcached启动时通过“-M”参数可以禁止LRU，如下所示：

$ memcached -M -m 1024

启动时必须注意的是，小写的“-m”选项是用来指定最大内存大小的。不指定具体数值则使用默认值64MB。

指定“-M”参数启动后，内存用尽时memcached会返回错误。 话说回来，memcached毕竟不是存储器，而是缓存，所以推荐使用LRU。

memcached的最新发展方向

memcached的roadmap上有两个大的目标。一个是二进制协议的策划和实现，另一个是外部引擎的加载功能。

关于二进制协议

使用二进制协议的理由是它不需要文本协议的解析处理，使得原本高速的memcached的性能更上一层楼， 还能减少文本协议的漏洞。目前已大部分实现，开发用的代码库中已包含了该功能。 memcached的下载页面上有代码库的链接。

• http://danga.com/memcached/download.bml

二进制协议的格式

协议的包为24字节的帧，其后面是键和无结构数据（Unstructured Data）。 实际的格式如下（引自协议文档）：

 Byte/     0       |       1       |       2       |       3       |   
    /              |               |               |               |   
   |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
   +---------------+---------------+---------------+---------------+
  0/ HEADER                                                        /   
   /                                                               /   
   /                                                               /   
   /                                                               /   
   +---------------+---------------+---------------+---------------+
 24/ COMMAND-SPECIFIC EXTRAS (as needed)                           /   
  +/  (note length in th extras length header field)               /   
   +---------------+---------------+---------------+---------------+
  m/ Key (as needed)                                               /   
  +/  (note length in key length header field)                     /   
   +---------------+---------------+---------------+---------------+
  n/ Value (as needed)                                             /   
  +/  (note length is total body length header field, minus        /   
  +/   sum of the extras and key length body fields)               /   
   +---------------+---------------+---------------+---------------+
  Total 24 bytes

如上所示，包格式十分简单。需要注意的是，占据了16字节的头部(HEADER)分为 请求头（Request Header）和响应头（Response Header）两种。 头部中包含了表示包的有效性的Magic字节、命令种类、键长度、值长度等信息，格式如下：

Request Header

 Byte/     0       |       1       |       2       |       3       |
    /              |               |               |               |
   |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
   +---------------+---------------+---------------+---------------+
  0| Magic         | Opcode        | Key length                    |
   +---------------+---------------+---------------+---------------+
  4| Extras length | Data type     | Reserved                      |
   +---------------+---------------+---------------+---------------+
  8| Total body length                                             |
   +---------------+---------------+---------------+---------------+
 12| Opaque                                                        |
   +---------------+---------------+---------------+---------------+
 16| CAS                                                           |
   |                                                               |
   +---------------+---------------+---------------+---------------+

Response Header

 Byte/     0       |       1       |       2       |       3       |
    /              |               |               |               |
   |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
   +---------------+---------------+---------------+---------------+
  0| Magic         | Opcode        | Key Length                    |
   +---------------+---------------+---------------+---------------+
  4| Extras length | Data type     | Status                        |
   +---------------+---------------+---------------+---------------+
  8| Total body length                                             |
   +---------------+---------------+---------------+---------------+
 12| Opaque                                                        |
   +---------------+---------------+---------------+---------------+
 16| CAS                                                           |
   |                                                               |
   +---------------+---------------+---------------+---------------+

如希望了解各个部分的详细内容，可以checkout出memcached的二进制协议的代码树， 参考其中的docs文件夹中的protocol_binary.txt文档。

HEADER中引人注目的地方

看到HEADER格式后我的感想是，键的上限太大了！现在的memcached规格中，键长度最大为250字节， 但二进制协议中键的大小用2字节表示。因此，理论上最大可使用65536字节（2¹⁶）长的键。 尽管250字节以上的键并不会太常用，二进制协议发布之后就可以使用巨大的键了。

二进制协议从下一版本1.3系列开始支持。

外部引擎支持

我去年曾经试验性地将memcached的存储层改造成了可扩展的（pluggable）。

• http://alpha.mixi.co.jp/blog/?p=129

MySQL的Brian Aker看到这个改造之后，就将代码发到了memcached的邮件列表。 memcached的开发者也十分感兴趣，就放到了roadmap中。现在由我和 memcached的开发者Trond Norbye协同开发（规格设计、实现和测试）。 和国外协同开发时时差是个大问题，但抱着相同的愿景， 最后终于可以将可扩展架构的原型公布了。 代码库可以从memcached的下载页面 上访问。

外部引擎支持的必要性

世界上有许多memcached的派生软件，其理由是希望永久保存数据、实现数据冗余等， 即使牺牲一些性能也在所不惜。我在开发memcached之前，在mixi的研发部也曾经 考虑过重新发明memcached。

外部引擎的加载机制能封装memcached的网络功能、事件处理等复杂的处理。 因此，现阶段通过强制手段或重新设计等方式使memcached和存储引擎合作的困难 就会烟消云散，尝试各种引擎就会变得轻而易举了。

简单API设计的成功的关键

该项目中我们最重视的是API设计。函数过多，会使引擎开发者感到麻烦； 过于复杂，实现引擎的门槛就会过高。因此，最初版本的接口函数只有13个。 具体内容限于篇幅，这里就省略了，仅说明一下引擎应当完成的操作：

• 引擎信息（版本等）
• 引擎初始化
• 引擎关闭
• 引擎的统计信息
• 在容量方面，测试给定记录能否保存
• 为item（记录）结构分配内存
• 释放item（记录）的内存
• 删除记录
• 保存记录
• 回收记录
• 更新记录的时间戳
• 数学运算处理
• 数据的flush

对详细规格有兴趣的读者，可以checkout engine项目的代码，阅读器中的engine.h。

重新审视现在的体系

memcached支持外部存储的难点是，网络和事件处理相关的代码（核心服务器）与 内存存储的代码紧密关联。这种现象也称为tightly coupled（紧密耦合）。 必须将内存存储的代码从核心服务器中独立出来，才能灵活地支持外部引擎。 因此，基于我们设计的API，memcached被重构成下面的样子：

重构之后，我们与1.2.5版、二进制协议支持版等进行了性能对比，证实了它不会造成性能影响。

在考虑如何支持外部引擎加载时，让memcached进行并行控制（concurrency control）的方案是最为容易的， 但是对于引擎而言，并行控制正是性能的真谛，因此我们采用了将多线程支持完全交给引擎的设计方案。

以后的改进，会使得memcached的应用范围更为广泛。

总结

本次介绍了memcached的超时原理、内部如何删除数据等，在此之上又介绍了二进制协议和 外部引擎支持等memcached的最新发展方向。这些功能要到1.3版才会支持，敬请期待！

这是我在本连载中的最后一篇。感谢大家阅读我的文章！

下次由长野来介绍memcached的应用知识和应用程序兼容性等内容。

dbanotes posted a photo:

估计这封邮件还是比较能够迷惑人的

dbanotes posted a photo:

在中国，什么样的人最爱索要贿赂？根据最近的一项方法不尽科学的调查来看，答案是那些许诺办事结果不会有麻烦的政府官员。

©作者：eygle 发布在 eygle.com

去年曾经帮助客户处理了一则ORA-07445的错误，当时客户的症状是每个月出一次07445错误，然后Down机。
主机上SUN V880，采用的双机热备的系统。第一次出现故障是在2007年6月左右。我在9月底帮助客户解决了问题。

昨天客户找到我，说数据库7月初又出现了07445错误，我摘录一下错误信息：

Exception signal: 11 (SIGSEGV), code: 1 (Address not mapped to object), addr: 0x166, PC: [0x10289ce30, 000000010289CE30]
*** 2008-07-11 23:58:40.743
ksedmp: internal or fatal error
ORA-07445: exception encountered: core dump [000000010289CE30] [SIGSEGV] [Address not mapped to object] [0x000000166] [] []
Current SQL information unavailable - no session.

我开玩笑说，一年了，数据库旧病复发！数据库问题不会复发么？会的，不要以为这是玩笑。
如果一个问题可能会反复出现，那它就一定会反复出现，系统会在一定周期内出问题，数据库逢节假就问题频发。
还有些上市公司，总是在出财报时出现问题，所以，墨菲定律无处不在。

上一次我在客户现场待了三天，解决问题之后稳定运行了9个月，也算是不错的业绩了，可是客户总是在问题解决之后就觉得不再需要技术人员了。这是做技术的悲哀。

-The End-

相关文章|Related Articles

• ORA-00704 与 bootstrap 错误
  
• 成功优化案例:解决ERP系统更新性能问题
  
• 解决ORA-600 [qmxiUnpPacked2]错误一则
  
• 成功恢复案例:解决字典表误Truncate故障
  
• 497天是一个轮回-记Linux时钟的回转
  

评论数量(6)|Add Comments

本文网址：http://www.eygle.com/archives/2008/07/again_ora_07445.html

dbanotes posted a photo:

估计这封邮件还是比较能够迷惑人的