eygle.com   eygle.com
eygle.com  
 
Digest Net: November 2011 Archives

November 2011 Archives

文章来源: http://www.chinabyte.com/303/12190303.shtml

2011年10月28日,阿里巴巴集团采用Oracle PeopleSoft 企业人力资本管理(HCM)构建了集团统一的阿里HR信息化建设平台(简称e-HR平台),成功实现了集团内人才开发、培训、绩效评估、薪资等管理工作的规范化、流程化和自动化,全面提高了人力资源管理工作效率,满足了集团内部组织变化和核心价值观传承的需求,支持了企业的快速发展和业务增长。

  阿里巴巴成立于1999年,是中国最大的电子商务公司,它拥有的互联网用户遍布全球,成立之初只有18人。现在该公司在中国、香港、台湾、日本、韩国、英国和美国等国家和地区已拥有2万多名员工。

  阿里巴巴走向成功离不开人力资本战略。阿里巴巴一直在努力推进企业价值观和员工素质的融合发展,为不同类型的员工提供不同的职业发展通道和广阔的成长空间,不断满足企业战略发展所需。

  为了充分发挥人才的价值,更好地管理人力资本,进而提升组织关键能力和核心竞争力,阿里巴巴组织IT 和管理方面的专家进行了人力资源管理的咨询论证,并经过广泛市场调研和严密选型,选择了PeopleSoft HCM软件构建统一的e-HR平台。

  在甲骨文合作伙伴毕博管理咨询公司的协助下,阿里巴巴实施了核心人力资源管理(Core HR)、薪资与福利管理、电子绩效管理、培训管理等诸多模块,并与财务管理等系统实现了充分集成与全面整合,构建统一规范的e-HR平台,为集团提供了人员信息和组织信息的单一可信数据源,并可与其他系统进行分享。由此,阿里巴巴在全球化背景下的人力资本的理念、价值观体系及相关活动项目都得以充分推行和落实。

  借助PeopleSoft HCM软件,阿里巴巴成功将e-HR平台推广到包含港台和海外子公司在内的所有子公司,所有分支机构能同时开展人力资源管理工作,实现了整个集团的人力资 源工作流程规范化和自动化,显著提高了人力资源管理的精确性和工作效率,并从容应对了企业员工人数从2000人到2万多人的急剧扩张、业务高速发展、组织 机构和人员全面改制重组的巨大挑战。

  此外,利用PeopleSoft HCM 电子绩效管理模块,阿里巴巴构建了一个集团统一标准的全过程跟踪绩效管理平台,显著提高了绩效和评估等工作的时效性和可靠性,同时通过全新的绩效考核机制 提升了员工的企业价值观绩效,并通过对人力资源数据的智能分析为管理层战略决策提供了有效支撑。

  更重要的是,在本次部署PeopleSoft HCM软件中,阿里巴巴通过自主创新不断对新平台进行调整,完善和丰富系统功能,取得了让新平台更加适应集团发展需求的重要成功,如在将原来的一家公司拆 分为集团子公司架构的组织重组过程中,集团内部不断磨合沟通,寻求最佳解决办法,最终圆满完成了架构调整、流程设置、人员配置等。

  甲骨文高管及客户相关引言

  阿里巴巴集团e-HR资深经理宗鸣表示:"通过实施基于PeopleSoft 人力资源解决方案的e-HR 平台,阿里巴巴的人力资源政策制度和统一流程在整个集团得到了更加有效无误的贯彻,人力资源部门的员工也从事务性的工作中逐步被释放出来,帮助我们实现了'让人力资源管理实践更加开放简单'的目标。"

  甲骨文公司大中华区人力资本管理业务发展总监叶天禄表示:"人才是一个企业保持持续快速发展的关键资本,发现人才、管理人才并给予其符合企业业 务发展所需的技能、发掘人才潜力,成为了每个企业的管理之重。作为同类最佳的人力资本管理软件,Oracle PeopleSoft 企业人力资本管理(HCM)软件,可帮助企业通过对人进行投资而使其增值并创造新的价值,增强企业核心竞争力。"

  甲骨文公司副总裁及大中华区管理软件业务总经理潘杰君表示:"甲骨文全面、开放、集成的应用软件解决方案适用于所有规模的不同行业企业,并为这 些企业提供了全方位的选择。借助甲骨文业界领先的应用软件产品和解决方案,我们致力于帮助更多的客户优化企业绩效,实现显著的业务增长。"


ORA-600 [25012] 错误的因果与消除

转摘崔华的文章,最近碰到多次 25012 (  http://dbsnake.com/2011/02/ora-600-25012-reco.html

ora-600[25012]错误的本质原因是因为oracle在构造一致读的过程中发现undo blockrdba不对了,说到底还是因为块的损坏,解决方法就是往前递增全库的SCN,使oracle不产生一致读就可以了。当然,如果这个块已经坏的面目全非,那上述这种方法也不一定行。

 

我们来看一下我构造的这个例子:

SQL_testdb>drop table t1;

 

Table dropped.

 

SQL_testdb>create table t1(id number,name varchar2(10));

 

Table created.

 

SQL_testdb>insert into t1 values(1,'cuihua1');

 

1 row created.

 

SQL_testdb>insert into t1 values(2,'cuihua2');

 

1 row created.

 

SQL_testdb>commit;

 

Commit complete.

 

SQL_testdb>select * from t1;

 

        ID NAME

---------- ----------

         1 cuihua1

         2 cuihua2

 

这么改:

1、  递增上述两条记录所在的itlcommit SCN;

2、  修改上述两条记录所在的itlundo blockRDBA

 

改完后ora-600[25012]如期而至:

SQL_testdb>select * from t1;

select * from t1

              *

ERROR at line 1:

ORA-00600: internal error code, arguments: [25012], [11], [971], [], [], [],

[], []

 

此时的解决方法很简单----就是递增全库的SCN不让oracle产生一致读就可以了。

 

递增完全库的SCN后可以看到ora-600[25012]已经不复存在:

SQL_testdb>select * from t1;

 

        ID NAME

---------- ----------

         1 cuihua1

         2 cuihua2

 

我在"Oracle数据库恢复之如何解决ORA-600[25012]错误"这篇文章提到----ora-600[25012]错误的本质原因是因为oracle在构造一致读的过程中发现undo blockrdba不对了,说到底还是因为块的损坏,解决方法就是往前递增全库的SCN,使oracle不产生一致读就可以了。

 

我在写完上述这篇文章后得到了朋友的反馈说即便递增了全库的SCN,依然报错ora-600[25012]

这是有可能的,因为如果oracle是因为相应的transactioncommit而被迫产生的一致读,那么这种情况下无论你怎样递增SCN都是没有效果的。此时我们的解决方法就是手工把这个transaction改成commit就好了。

 

我们来看一个实例:

SQL_testdb>drop table t1;

 

Table dropped.

 

SQL_testdb>create table t1(id number,name varchar2(10));

 

Table created.

 

SQL_testdb>insert into t1 values(1,'cuihua1');

 

1 row created.

 

SQL_testdb>insert into t1 values(2,'cuihua2');

 

1 row created.

 

SQL_testdb>commit;

 

Commit complete.

 

SQL_testdb>select * from t1;

 

        ID NAME

---------- ----------

         1 cuihua1

         2 cuihua2

 

这么改:

1、  修改上述两条记录所对应的itlflag,改为未commit

2、  清掉上述两条记录所对应的itl中的commit SCN

3、  修改上述两条记录所对应的ktuxe中的commit flag,由0x09改为0x10注意这个commit flag是一定要改的,因为要避免oracle的延迟块清除

4、  修改上述两条记录所在的itlundo blockRDBA

改完后相应blockktbbh如下所示:

BBED> p ktbbh

struct ktbbh, 72 bytes                      @20     

   ub1 ktbbhtyp                             @20       0x01 (KDDBTDATA)

   union ktbbhsid, 4 bytes                  @24     

      ub4 ktbbhsg1                          @24       0x0000775d

      ub4 ktbbhod1                          @24       0x0000775d

   struct ktbbhcsc, 8 bytes                 @28     

      ub4 kscnbas                           @28       0x80000904

      ub2 kscnwrp                           @32       0x0001

   b2 ktbbhict                              @36       2

   ub1 ktbbhflg                             @38       0x03 (KTBFONFL)

   ub1 ktbbhfsl                             @39       0x00

   ub4 ktbbhfnx                             @40       0x00000000

   struct ktbbhitl[0], 24 bytes             @44     

      struct ktbitxid, 8 bytes              @44     

         ub2 kxidusn                        @44       0x0011

         ub2 kxidslt                        @46       0x001f

         ub4 kxidsqn                        @48       0x00000167

      struct ktbituba, 8 bytes              @52     

         ub4 kubadba                        @52       0xf2c00484

         ub2 kubaseq                        @56       0x003e

         ub1 kubarec                        @58       0x23

      ub2 ktbitflg                          @60       0x0002 (NONE)

      union _ktbitun, 2 bytes               @62     

         b2 _ktbitfsc                       @62       0

         ub2 _ktbitwrp                      @62       0x0000

      ub4 ktbitbas                          @64       0x00000000

   struct ktbbhitl[1], 24 bytes             @68     

      struct ktbitxid, 8 bytes              @68     

         ub2 kxidusn                        @68       0x0000

         ub2 kxidslt                        @70       0x0000

         ub4 kxidsqn                        @72       0x00000000

      struct ktbituba, 8 bytes              @76     

         ub4 kubadba                        @76       0x00000000

         ub2 kubaseq                        @80       0x0000

         ub1 kubarec                        @82       0x00

      ub2 ktbitflg                          @84       0x0000 (NONE)

      union _ktbitun, 2 bytes               @86     

         b2 _ktbitfsc                       @86       0

         ub2 _ktbitwrp                      @86       0x0000

      ub4 ktbitbas                          @88       0x00000000

 

执行完上述修改后ora-600[25012]如期而至:

SQL_testdb>select * from t1;

select * from t1

              *

ERROR at line 1:

ORA-00600: internal error code, arguments: [25012], [11], [971], [], [], [],

[], []

 

这个时候你会发现递增完全库的SCN后库已经起不来了,报错:

Mon Feb 28 14:32:14 2011

Errors in file /cadrasu01/app/oracle/admin/testdb/udump/testdb_ora_5955644.trc:

ORA-00600: internal error code, arguments: [4062], [17], [31], [16], [], [], [], []

Mon Feb 28 14:32:15 2011

Errors in file /cadrasu01/app/oracle/admin/testdb/udump/testdb_ora_5955644.trc:

ORA-00600: internal error code, arguments: [4062], [17], [31], [16], [], [], [], []

Mon Feb 28 14:32:15 2011

 

当我们解决完上述错误后会发现ora-600[25012]依然阴魂不散,即此时递增全库的SCN是没有效果的:

SQL_testdb>select * from t1;

select * from t1

              *

ERROR at line 1:

ORA-00600: internal error code, arguments: [25012], [11], [971], [], [], [],

[], []

 

这时候这么改:

1、  修改上述两条记录所对应的itlflag,改为commit

2、  伪造一个commit SCN,这个commit SCN只需要比相应的CSC大一点点就好;

3、  修改上述两条记录所对应的ktuxe中的commit flag,由0x10改为0x09

 

改完后ora-600[25012]已经不复存在,上述两条记录又回来了:

SQL_testdb>select * from t1;

 

        ID NAME

---------- ----------

         1 cuihua1

         2 cuihua2


Metalink 上的一些解释:


ORA-600 [25012] "Relative to Absolute File Number Conversion Error"

Note: For additional ORA-600 related information please read Note:146580.1

PURPOSE:
  This article discusses the internal error "ORA-600 [25012]", what
  it means and possible actions. The information here is only applicable
  to the versions listed and is provided only for guidance.

ERROR:
  ORA-600 [25012] [a] [b] [c]

VERSIONS:
  versions 8.0 and above

DESCRIPTION:

  We are trying to generate the absolute file number given a tablespace
  number and relative file number and cannot find a matching file number
  or the file number is zero.

ARGUMENTS:
  Arg [a] Tablespace Number
  Arg [b] Relative file number
  Arg [c] Absolute file number (This arg is present is more recent releases)

FUNCTIONALITY:
  KERNEL FILE MANAGEMENT TABLESPACE COMPONENT

IMPACT:
  POSSIBLE PHYSICAL CORRUPTION

SUGGESTIONS:        

  The possibility of physical corruption exists.

  Obtain the trace files and alert.log for this error and log a Service Request
  with Oracle Support Services for diagnosis.

  If the Arg [b] Relative file number returns 0 (zero), look for fake indexes
  that can cause this error.

  The following query list fake indexes :

  select a.*,b.flags from dba_objects a, sys.ind$ b
  where a.object_id = b.obj#
  and bitand(b.flags,4096)=4096;



对于SYS.ALL_SYNONYMS查询的性能问题

Oracle 10g之后,对于ALL_SYNONYMS的查询可能带来问题,以下是摘录。

In this Document
Symptoms
Changes
Cause
Solution
References


Applies to:

Oracle Server - Enterprise Edition - Version: 10.2.0.1 to 10.2.0.4 - Release: 10.2 to 10.2
Information in this document applies to any platform.

Symptoms

In some cases queries against the ALL_SYNONYMS view are slower after upgrading to 10.2.0.x
For example:

SELECT /*+ RULE */ COUNT(*)
FROM
ALL_SYNONYMS WHERE OWNER='PUBLIC' AND SYNONYM_NAME='&1'

Oracle 10g Release 10.2:

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse       81      0.02       0.00          0          0          0           0
Execute     81      0.05       0.09          0          0          0           0
Fetch       81    355.93     371.05          0   45269282          0          81
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total      243    356.00     371.15          0   45269282          0          81

Oracle 9i Release 9.2:

call count cpu elapsed disk query current rows ------- ------ -------- ---------- ---------- ---------- ---------- ---------- Parse 81 0.02 0.02 0 0 0 0 Execute 81 0.04 0.01 0 0 0 0 Fetch 81 0.03 0.01 0 810 0 81 ------- ------ -------- ---------- ---------- ---------- ---------- ---------- total 243 0.09 0.05 0 810 0 81

Changes

Changed to a version higher than 9.2 from 9.2 or below.

Cause

10g release 10.1.0.5, 10.2.0.1 and above contain a new view definition for ALL_SYNONYMS which is the result of a fix to an outstanding defect. This defect meant that certain synonyms would not be displayed when selecting from ALL_SYNONYMS. To fix the defect a new, more complex, ALL_SYNONYMS was required and as a side affect queries that select against the new ALL_SYNONYMS definition have much more complicated execution plans and may be more expensive when compared to execution plans in earlier versions (such as 9.2).
For example:

Compare the execution plan for ALL_SYNONYMS queries in 10046 trace file in 10.2 and in 9.2, to confirm execution plan is more resource consuming in 10.2 :

In 9.2 execution plan is :

Rows     Row Source Operation
-------  ---------------------------------------------------
1  SORT AGGREGATE
1   FILTER
1    NESTED LOOPS
1     NESTED LOOPS
1      TABLE ACCESS BY INDEX ROWID USER$
1       INDEX UNIQUE SCAN I_USER1 (object id 41)
1      TABLE ACCESS BY INDEX ROWID OBJ$
1       INDEX RANGE SCAN I_OBJ2 (object id 34)
1     TABLE ACCESS BY INDEX ROWID SYN$
1      INDEX UNIQUE SCAN I_SYN1 (object id 98)
0    FILTER
0     NESTED LOOPS
0      NESTED LOOPS
0       TABLE ACCESS BY INDEX ROWID USER$
0        INDEX UNIQUE SCAN I_USER1 (object id 41)
0       TABLE ACCESS BY INDEX ROWID OBJ$
0        INDEX RANGE SCAN I_OBJ2 (object id 34)
0      INDEX RANGE SCAN I_OBJAUTH1 (object id 100)
0     FIXED TABLE FULL X$KZSRO
0    FIXED TABLE FULL X$KZSPR

In 10.2 execution plan is :

Rows     Row Source Operation
-------  ---------------------------------------------------
1  SORT AGGREGATE (cr=558882 pr=0 pw=0 time=4326033 us)
1   VIEW  ALL_SYNONYMS (cr=558882 pr=0 pw=0 time=4325993 us)
1    SORT UNIQUE (cr=558882 pr=0 pw=0 time=4325988 us)
1     UNION-ALL  (cr=558882 pr=0 pw=0 time=4325909 us)
1      FILTER  (cr=10 pr=0 pw=0 time=185 us)
1       NESTED LOOPS  (cr=10 pr=0 pw=0 time=173 us)
1        NESTED LOOPS  (cr=7 pr=0 pw=0 time=136 us)
1         TABLE ACCESS BY INDEX ROWID USER$ (cr=3 pr=0 pw=0 time=56 us)
1          INDEX UNIQUE SCAN I_USER1 (cr=2 pr=0 pw=0 time=39 us)(object id 41)
1         TABLE ACCESS BY INDEX ROWID OBJ$ (cr=4 pr=0 pw=0 time=77 us)
1          INDEX RANGE SCAN I_OBJ2 (cr=3 pr=0 pw=0 time=48 us)(object id 34)
1        TABLE ACCESS BY INDEX ROWID SYN$ (cr=3 pr=0 pw=0 time=31 us)
1         INDEX UNIQUE SCAN I_SYN1 (cr=2 pr=0 pw=0 time=17 us)(object id 98)
0       FILTER  (cr=0 pr=0 pw=0 time=0 us)
0        FILTER  (cr=0 pr=0 pw=0 time=0 us)
0         NESTED LOOPS  (cr=0 pr=0 pw=0 time=0 us)
0          NESTED LOOPS  (cr=0 pr=0 pw=0 time=0 us)
0           TABLE ACCESS BY INDEX ROWID USER$ (cr=0 pr=0 pw=0 time=0 us)
0            INDEX UNIQUE SCAN I_USER1 (cr=0 pr=0 pw=0 time=0 us)(object id 41)
0           TABLE ACCESS BY INDEX ROWID OBJ$ (cr=0 pr=0 pw=0 time=0 us)
0            INDEX RANGE SCAN I_OBJ2 (cr=0 pr=0 pw=0 time=0 us)(object id 34)
0          INDEX RANGE SCAN I_OBJAUTH1 (cr=0 pr=0 pw=0 time=0 us)(object id 100)
0        FIXED TABLE FULL X$KZSRO (cr=0 pr=0 pw=0 time=0 us)
0       FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us)
0      NESTED LOOPS  (cr=558872 pr=0 pw=0 time=4325697 us)
0       NESTED LOOPS  (cr=558872 pr=0 pw=0 time=4325692 us)
7        NESTED LOOPS  (cr=558849 pr=0 pw=0 time=4325568 us)
1         TABLE ACCESS BY INDEX ROWID USER$ (cr=3 pr=0 pw=0 time=25 us)
1          INDEX UNIQUE SCAN I_USER1 (cr=2 pr=0 pw=0 time=15 us)(object id 41)
7         VIEW  _ALL_SYNONYMS_TREE (cr=558846 pr=0 pw=0 time=4325543 us)
7          CONNECT BY WITHOUT FILTERING (cr=558846 pr=0 pw=0 time=4325527 us)
7           FILTER  (cr=279521 pr=0 pw=0 time=1848969 us)
18            COUNT  (cr=279323 pr=0 pw=0 time=1505655 us)
18             NESTED LOOPS  (cr=279323 pr=0 pw=0 time=1143804 us)
25717              NESTED LOOPS  (cr=201352 pr=0 pw=0 time=1113824 us)
27395               NESTED LOOPS  (cr=148330 pr=0 pw=0 time=925979 us)
69679                NESTED LOOPS  (cr=51254 pr=0 pw=0 time=487918 us)
958                 TABLE ACCESS FULL USER$ (cr=233 pr=0 pw=0 time=2996 us)
69679                 TABLE ACCESS BY INDEX ROWID OBJ$ (cr=51021 pr=0 pw=0 time=431685 us)
69679                  INDEX RANGE SCAN I_OBJ2 (cr=3216 pr=0 pw=0 time=80937 us)(object id 34)
27395                TABLE ACCESS BY INDEX ROWID SYN$ (cr=97076 pr=0 pw=0 time=697424 us)
27395                 INDEX UNIQUE SCAN I_SYN1 (cr=69681 pr=0 pw=0 time=425927 us)(object id 98)
25717               TABLE ACCESS BY INDEX ROWID USER$ (cr=53022 pr=0 pw=0 time=309207 us)
25717                INDEX UNIQUE SCAN I_USER1 (cr=27305 pr=0 pw=0 time=150664 us)(object id 41)
18              TABLE ACCESS BY INDEX ROWID OBJ$ (cr=77971 pr=0 pw=0 time=598777 us)
26615               INDEX RANGE SCAN I_OBJ2 (cr=51865 pr=0 pw=0 time=371282 us)(object id 34)
7            FILTER  (cr=198 pr=0 pw=0 time=1794 us)
7             NESTED LOOPS  (cr=198 pr=0 pw=0 time=1489 us)
50              NESTED LOOPS  (cr=91 pr=0 pw=0 time=853 us)
7               NESTED LOOPS  (cr=52 pr=0 pw=0 time=414 us)
7                TABLE ACCESS BY INDEX ROWID SYN$ (cr=31 pr=0 pw=0 time=264 us)
7                 INDEX UNIQUE SCAN I_SYN1 (cr=24 pr=0 pw=0 time=179 us)(object id 98)
7                TABLE ACCESS BY INDEX ROWID USER$ (cr=21 pr=0 pw=0 time=126 us)
7                 INDEX UNIQUE SCAN I_USER1 (cr=14 pr=0 pw=0 time=74 us)(object id 41)
50               TABLE ACCESS BY INDEX ROWID OBJ$ (cr=39 pr=0 pw=0 time=320 us)
50                INDEX RANGE SCAN I_OBJ2 (cr=22 pr=0 pw=0 time=215 us)(object id 34)
7              INDEX RANGE SCAN I_OBJAUTH1 (cr=107 pr=0 pw=0 time=596 us)(object id 100)
2             FIXED TABLE FULL X$KZSRO (cr=0 pr=0 pw=0 time=174 us)
18           COUNT  (cr=279325 pr=0 pw=0 time=1440703 us)
18            NESTED LOOPS  (cr=279325 pr=0 pw=0 time=1440701 us)
25717             NESTED LOOPS  (cr=201354 pr=0 pw=0 time=1112712 us)
27395              NESTED LOOPS  (cr=148332 pr=0 pw=0 time=926537 us)
69679               NESTED LOOPS  (cr=51255 pr=0 pw=0 time=487858 us)
958                TABLE ACCESS FULL USER$ (cr=233 pr=0 pw=0 time=2945 us)
69679                TABLE ACCESS BY INDEX ROWID OBJ$ (cr=51022 pr=0 pw=0 time=431397 us)
69679                 INDEX RANGE SCAN I_OBJ2 (cr=3216 pr=0 pw=0 time=80879 us)(object id 34)
27395               TABLE ACCESS BY INDEX ROWID SYN$ (cr=97077 pr=0 pw=0 time=687683 us)
27395                INDEX UNIQUE SCAN I_SYN1 (cr=69681 pr=0 pw=0 time=415512 us)(object id 98)
25717              TABLE ACCESS BY INDEX ROWID USER$ (cr=53022 pr=0 pw=0 time=308614 us)
25717               INDEX UNIQUE SCAN I_USER1 (cr=27305 pr=0 pw=0 time=150815 us)(object id 41)
18             TABLE ACCESS BY INDEX ROWID OBJ$ (cr=77971 pr=0 pw=0 time=591777 us)
26615              INDEX RANGE SCAN I_OBJ2 (cr=51865 pr=0 pw=0 time=363738 us)(object id 34)
7           FILTER  (cr=198 pr=0 pw=0 time=1794 us)
7             NESTED LOOPS  (cr=198 pr=0 pw=0 time=1489 us)
50              NESTED LOOPS  (cr=91 pr=0 pw=0 time=853 us)
7               NESTED LOOPS  (cr=52 pr=0 pw=0 time=414 us)
7                TABLE ACCESS BY INDEX ROWID SYN$ (cr=31 pr=0 pw=0 time=264 us)
7                 INDEX UNIQUE SCAN I_SYN1 (cr=24 pr=0 pw=0 time=179 us)(object id 98)
7                TABLE ACCESS BY INDEX ROWID USER$ (cr=21 pr=0 pw=0 time=126 us)
7                 INDEX UNIQUE SCAN I_USER1 (cr=14 pr=0 pw=0 time=74 us)(object id 41)
50               TABLE ACCESS BY INDEX ROWID OBJ$ (cr=39 pr=0 pw=0 time=320 us)
50                INDEX RANGE SCAN I_OBJ2 (cr=22 pr=0 pw=0 time=215 us)(object id 34)
7              INDEX RANGE SCAN I_OBJAUTH1 (cr=107 pr=0 pw=0 time=596 us)(object id 100)
2            FIXED TABLE FULL X$KZSRO (cr=0 pr=0 pw=0 time=174 us)
0        TABLE ACCESS BY INDEX ROWID OBJ$ (cr=0 pr=0 pw=0 time=0 us)
0         INDEX UNIQUE SCAN I_OBJ1 (cr=0 pr=0 pw=0 time=0 us)(object id 33)
0       TABLE ACCESS BY INDEX ROWID SYN$ (cr=0 pr=0 pw=0 time=0 us)
0        INDEX UNIQUE SCAN I_SYN1 (cr=0 pr=0 pw=0 time=0 us)(object id 98)

Solution

There is no resolution to this issue.
In future versions it is possible that this may be addressed but any fix would not be back-portable to previous versions as architechtural changes are required to enable it.

The current ALL_SYNONYMS view's changes and additional explain plan steps are necessary to resolve the original issue with the ALL_SYNONYMS view.

To have similar performance from the ALL_SYNONYMS view on 10g to version 9.2 do the following steps :

  1. Create a new view "SYS.ALL_SYNONYMS_920X" with all_synonyms definition from database 920X. The view definition for ALL_SYNONYMS is stored in the $ORACLE_HOME/rdbms/admin/catalog.sql script. To create the new view, login as the SYS user and execute the following:
    connect / as sysdba
    create or replace view SYS.ALL_SYNONYMS_920X
    (OWNER, SYNONYM_NAME, TABLE_OWNER, TABLE_NAME, DB_LINK)
    as
    select u.name, o.name, s.owner, s.name, s.node
    from sys.user$ u, sys.syn$ s, sys.obj$ o
    where o.obj# = s.obj#
    and o.type# = 5
    and o.owner# = u.user#
    and (
    o.owner# in (USERENV('SCHEMAID'), 1 /* PUBLIC */) /* user's private, any public */
    or /* user has any privs on base object */
    exists
    (select null from sys.objauth$ ba, sys.obj$ bo, sys.user$ bu
    where bu.name = s.owner
    and bo.name = s.name
    and bu.user# = bo.owner#
    and ba.obj# = bo.obj#
    and ( ba.grantee# in (select kzsrorol from x$kzsro)
    or ba.grantor# = USERENV('SCHEMAID')
    )
    )
    or /* user has system privileges */
    exists (select null from v$enabledprivs
    where priv_number in (-45 /* LOCK ANY TABLE */,
    -47 /* SELECT ANY TABLE */,
    -48 /* INSERT ANY TABLE */,
    -49 /* UPDATE ANY TABLE */,
    -50 /* DELETE ANY TABLE */)
    )
    )
    /
  2. To force users to select from this new view without code modification, a private synonym can be created:
    CREATE SYNONYM username.ALL_SYNONYMS FOR SYS.ALL_SYNONYMS_920X

    This is private synonym must be created for any user executing which wants to use the new definition.
    Note that the users could also select from the new definition directly but this would require code references to be changed in the application.

Note that this workaround simply reverts to the previous view definition.It simply provides a workaround to achieve the old performance in the short term.

Having reverted to the previous view definition users may hit Bug:3369744 per which ALL_SYNONYMS does not show all accessible synonyms.

References

BUG:5454590 - SELECT FROM ALL_SYNONYMS AND ALL_OBJECTS IS MUCH SLOWER IN 10.2.0.2
NOTE:364822.1 - Poor Performance On Certain Dictionary Queries After Upgrade To 10g
SR:16161618.6

其他阅读: http://www.eygle.com/archives/2011/06/all_objects_xkgldp_xkzspr.html

普希金的缪斯情节

(原文链接:http://www.8dou.net/html/article_show_56246.shtml
亚历山大.普希金是俄罗斯伟大的民族诗人,俄国积极浪漫主义文学的主要代表和俄国批判现实主义文学的奠基人。高尔基赞誉普希金是"俄国文学之始祖",是 "伟大的俄国人民诗人"。①"俄国诗歌的太阳"。冈察洛夫说"普希金是俄罗斯艺术之父,是开山鼻祖",这些称赞是切合普希金的。他在其并不是太长的创作生 涯中,为我们留下了包括诗歌、小说、喜剧、文学等大量文学遗产,而在这一切之中,最被人喜欢的,所传颂的则是他的抒情诗。
   他的抒情诗里大部 分时对奶娘、爱过的女人、相识不久的女友、以及最后成为他的伴侣的冈察洛娃的眷恋与思念,但是他的抒情性,却有很强的感染力,他抒情,但不娇柔,他善于表 达思念,但不遮遮掩掩。"无怪当时有人说,读了普希金的诗,俄罗斯人的压抑的感情仿佛才得到了解放。"(卢永在高莽等译《普希金诗选》中的前言)这是他的 风格,他不拗句,几乎顺手拈来,感情的流露犹如流水般,让人清晰可辨。他的艺术的语言,开创了"俄罗斯的文学语言"丰富了俄罗斯语言的魅力,有如莎士比亚 的语言对英语产生的影响一般,他的抒情语言隽永流畅,又富有情思。
   他对古希腊神话中的缪斯女神情有独钟,他说"当你陶醉于热烈的爱情,∕切 不可将爱情的缪斯遗忘"(《致巴丘什科夫》)他把缪斯歌唱,把他当做爱情的象征,这是对缪斯的一种钟情,更是对爱情的衷情。在他的作品里面,缪斯似的形象 让他更产生对爱情的向往与渴望,1816年更是进一步阐述了他的爱情追求"爱情对我的折磨我很珍重,∕纵然死也让我爱着死去!"(《心愿》)他的爱情的渴 望总是那么的强烈。
   他的爱情诗总是那么的缠绵细腻。一见倾心的爱慕,长相思的痛苦,嫉妒的折磨,欲言又止的羞怯,绝望中的倾吐,回忆中的甜 蜜,都是那样的有感情,都恰如其分的化作他优美的诗句。在《致凯恩》:"我记得那美妙的瞬间:你就在我的眼前降临,如同昙花一现的梦幻,如同纯真之美的化 身。""我忘却了你那温柔的声音,也忘却了你天仙般的容颜。"如此的缠绵悱恻,这爱情如梦幻般"在我的梦中盘旋"也如"幻想吹散",他痛苦,他受折磨, "没有泪水,没有生命,没有爱情。"这是他与凯恩长时间来往后离去的痛苦,泪水也流不下来,爱就这样失去了,但是还记得那曾有的美妙的瞬间,是那样的甜 蜜。"你的温柔的声音总响在耳边",彼此之间的羞怯,让相会也缺少了言语,但却"无声胜有声"。
   在爱里,他尽情的摄取人间的美;在爱里,他真诚的寻找自己坎坷的生涯的慰藉:在爱里,他不断的汲取创作的动力、生活的勇气。
    他的奶娘----阿琳娜·罗季翁诺夫娜,是他最早的生活中的缪斯。她给他带来温暖,给他带来诗的语言,也给他带来诗的灵感。对她的感情是深沉的,也是尊敬 的。她犹如缪斯掌管世间的抒情诗掌管着普希金的诗,普希金的诗歌最早的材料是她从小就给他讲的民间故事,这就是普希金的最早的缪斯。是她影响了普希金的的 创作生涯,是她给他诗的最初模式,是她让他知道这世间还有给他栖身和温暖的人。普希金的奶娘给他更多的爱与关怀。在《给奶娘》的诗里这样写道:"我的严酷 岁月里的伴侣,∕我的老态龙钟的亲人!∕你独自在偏僻的松林深处∕久久、久久地等着我的来临。∕你在自己堂屋的窗下,∕像守卫的岗哨,暗自伤心,∕在那满 是皱褶的手里,∕你不时地停下你的织针。∕你朝那被遗忘的门口,∕望着黑暗而遥远的旅程:∕预感、惦念、无限的忧愁∕时刻压迫者你的心胸。∕你仿佛觉 得......"诗人并没有用什么华丽的辞藻,或者多么奇特的艺术形式,他只是用了最简单的、最质朴的形式来倾诉自己的最高尚的真挚情感。这是他在1826年写于 莫斯科的,这年沙皇突然将普希金召到莫斯科来,他的奶娘----阿琳娜·罗季翁诺夫娜对他的处境十分的担忧。普希金被流放,已经给她带来沉痛的心伤,而沙皇的 突然召回更让她对他的命运前途曾加更多的阴影。命运给他开了太大的玩笑,但他仍旧继续前往,正如他毫不畏惧的前往莫斯科一样。他对他的奶娘的深情厚谊超越 了亲身父母,一个慈母的期盼,一个慈母的关怀,是对儿子的担心,是母亲的所给与的儿子的母爱。普希金在诗中流露了对奶娘的眷念,表露出的无奈,是对母亲的 遗憾。因为命运现在不在他的掌控之中,他身不由己,也没办法去探望"老态龙钟的亲人"这是他"无限的忧愁"。诗人离开亲人太久了,没有能够回到亲人的怀里 述说他的苦痛。这首诗里他寻找自己坎坷的生涯的慰藉,但是却让他觉得很遥远,也似乎有点不太现实。他对奶娘的感情不是一般的深,也不是一般的沉,而是在深 和沉之外的亲爱。胡风在他的《文学与生活》里说"有真性的文艺作品,一定流贯着作者底感情、欲求、理想。"普希金的这首诗,流露出的感情,是真诚的,是有 真性的。
   他以缪斯自比。在那首"从前是这样"的诗句里,这样写到"我从前这样,我现在还是这样:∕无忧无虑,缪斯多情,你们知道,朋友 们,∕凝视着美色,我怎能不动感情,∕有怎能没有怯懦的温柔、内心的激动。∕爱情在我一生中对我的戏弄还不够?∕在吉普里达撒下的虚妄的情网中,∕我久久 的挣扎着,像一只幼小的鹰,∕曾一百次受辱都还不知悔改,∕现在我又把自己的哀怨献给新宠......"缪斯是多情的,在诗人失去爱情之后,还有一个缪斯还在他的 身边,朋友们不知道,但是诗人还是勇敢的站起来,继续把爱情追求,"献给新宠"。在虚妄的情网中,他像只小鹰般苦苦的挣扎。这首诗是他内心的独白,也是他 爱情之一的独白。
   诗人是多情的,但却又是真诚的。在1827年5月,普希金去彼得堡前夕写《给叶尼乌沙科娃》的诗中,说"虽然距离您很远很 远,我还是不能和您分离"这是他的真情的独白,虽然有可能是他"痛苦的回忆",在"孤寂中怎样悲伤,我也不希求别人的宽慰----如果我有一天被吊在刑场,您 呢,会不会为我叹一口气?"他的言语很平常,但却组织得那样的有感情,有条理,不用过多的修饰,感情也随之滚滚流露,情思也绵绵。他的诗丰满,完整,含 蓄,匀称,这表现了他的诗的特性之一。
   普希金的抒情诗随着他的年龄的增长,表达也更加富有哲理化,对自己生活处境的担忧,有时也表露出忧郁 的情调。但是普希金的忧郁不是温柔脆弱的心灵的甜蜜的哀愁。它永远是一颗坚强有力的心灵的忧郁;他对读者具有一种魅力,在读者的心底深刻而有力地回荡着, 和谐地振荡着他的心弦。普希金从不沉溺于"忧郁的情感"(别林斯基《论普希金的抒情诗》),的确,这种情感时常在他心里振鸣着,但并没有抹杀心灵别种声音 的合奏,以至成为单音。有时候,他在一阵沉郁以后,会象狮子耸动鬃毛似地突然摆摆头想把悒郁的阴云逐开。这种强烈的乐观情绪尽管没有完全把悒郁抹去,却给 了它一种特别的爽气,使心神振作。在《哀歌》里这样的忧郁也显得坚强而有力,在第一节里他说"想起过去荒唐岁月的那种作乐,∕我就心情沉重,像酒醉般受折 磨。"可以说这是他前期生活的写照,生活受折磨,心情也沉重。但是在第二节里一转他悲伤的情调,对生活也更加乐观,他说"我相信,生活不仅是操劳、灾难和 烦忧,∕总会有赏心悦目的事和我相伴:∕有时我会再次在和谐声中陶醉,∕有时会因为捏造、中伤而泪洒胸前,∕也许,在我悲苦一生的晚年,∕爱情会对我一展 离别的欢颜。"虽然有忧愁,但是却是振作的,有些忧郁,却是乐观与豁达。这是他对生活的深切的思考,对爱情哲理般的剖析。
   普希金每首诗的基 本情感,就其自身说,都是优美的、雅致的、娴熟的;它不仅是人的情感,而且是作为艺术家的人的情感。在普希金的任何情感中永远有一些特别高贵的、温和的、 柔情的、馥郁的、优雅的东西。他的诗没有奇幻的、空想的、虚伪的、怪诞的理想的东西;它整个浸透着现实。它没有给生活的面貌涂上脂粉,它只是把生活自然的 真实的美表现出来。
   他的作品的思想并不呈现为抽象的思想,并不是死的形式,而是活的创造,其形式的富于生命的美说明了那作品是有着庄严的思 想的。在这里面没有织补或者安装的迹象,没有思想和形式的分野,而是由两者溶合而成的整个的有机体。思想是从理智产生的;但能产生和创造活的东西的,是爱 情而非理智。因此,抽象的思想和诗的思想之间的区别是很明显的;前者是理性的果实,后者是作为热情的爱情的果实。普希金的诗中,特别是他的爱情诗中,诗的 思想表露得最直接,而抽象的思想在他后期的爱情诗作品中有着理性的思考。他后期的作品使得抽象的思想和诗的思想融合得非常的密切,有热情也有理性,形式也 更加严谨,诗的整体性得到有机的统一。冈察洛夫在《迟做总比不做的好》中说"普希金身上隐藏着一切种子和胚胎,这些种子和胚胎后来在我们这些艺术家身上发 育成为艺术的一切种类和形式。"②可以说普希金所创造的"普希金诗体"影响着以后的众多诗人,它是一种开创的形式,一种新的种类,给诗歌注入了新鲜的血 液。
   "能够真实的反映生活的作品,能够真实地反映出生活底脉搏的作品,才是好的,伟大的。......文艺并不是生活的复写,文艺作品所表现的东西 须得是作家从生活里提炼出来,和作家底主观活动起了化学作用以后的结果。文艺不是生活的奴隶,不是向眼前的生活屈服,它必须站在比生活更高的地方,能够有 把生活向前推进的力量。"③
   他的诗的内容是他一生的真实写照,是他生活的反应。艺术来源于生活,他的那些抒情诗都与他本人经历有关系,都来 源于他的亲身体验。在他短促的一生中,尽管他经历了多次的爱情、失恋,并最终为他所心爱的人走上了角斗场,成为统治阶级的牺牲品,但是他那善良的天性,高 尚的情感,明晰的理智使他认识到,诗人既是"天才的复仇者,真理的朋友",又是"苍天倾注的生命和永恒的光明。"他在诗中除了批判丑恶,还有宣扬情感的高 尚,歌颂美好的事物。
   普希金诗歌的艺术特色首先是真诚。别林斯基指出,普希金的诗的特征之一,那使他和以前的诗派严格区分的东西,是他的真 诚。另一个显著特点就是自然、朴素而优雅。普希金真正地把它们统一在一起,这就是普希金的高超之处。普希金的秘诀在于,他的情感"不仅是人的感情,而且是 作为艺术家的人的情感",这样,诗的品味在很大的程度上就取决于艺术家情感和思想的品味了,或者说取决于诗人的思想和艺术的素质了。别林斯基认为:"在这 一方面,可以把普希金的诗比作因感情和思想而变得炯炯有神的眼睛的美,如果您夺去这双眼睛变得炯炯有神的感情和思想,它们只是美丽的眼睛,却不再是神气和 秀美的眼睛了。"
   普希金的诗歌在语言上的最大的特点就是简洁和独特的音韵美。普希金的诗从一开始就表现出异乎寻常的简练。这也许是他的自然 朴素之风相联系的。果戈里谈到普希金的诗时指出:"这里没有华丽的词藻,这里只有诗;没有任何虚有其表的炫耀。一切都简朴,一切都雍容大方,一切都充满含 而不露的决不会突然宣泄而出的光彩;一切都符合纯正的诗所永远具有的言简意赅。"他的"用语言把人们的心灵燃亮"的崇高使命感和伟大抱负深深感动着一代又 一代的人。
   注释
   ①高尔基著、缪灵珠译:《俄国文学史》,上海文艺出版社,1959年,第177页。
   ②冈察洛夫、屠格涅夫、陀思妥耶夫斯基、克罗连科著,冯春选编:《文学论文选》,1997年版,58页
   ③胡风著:《文学与生活密云期生活小记》,人民文学出版社,2001年。
   参考文献:
   郑克鲁主编,《外国文学史》上册,高等教育出版社,2008年。
   (俄)冈察洛夫、屠格涅夫、陀思妥耶夫斯基、克罗连科著,冯春选编:《文学论文选》,1997年版。
   (俄)普希金著,高莽等译:《普希金诗选》,人民文学出版社,2005年


(原文出处:http://database.51cto.com/art/200612/36973.htm

引言

中国加入WTO之后,电信市场将逐步向外资开放,2006年开始外资将全面进入中国电信业,国际先进的服务模式和服务水平势必会对国内电信运营商提 出更高的挑战。同时国内电信业的竞争格局也发生了深刻的变化:第三、四张移动牌照即将发放,竞争形势更为残酷;用户增量市场逐渐萎缩,作为我们运营商更需 要的是如何提高自身服务质量,在存量市场中保持原有客户以及从竞争对手中获得客户。这些都意味着市场的竞争已逐步由技术驱动转向市场驱动和客户需求驱动, 电信运营商必须从传统的经营模式向"以客户为中心,以市场为导向"的经营模式转变,也将从单纯的网络竞争、价格竞争转向网络、价格与服务、渠道、品牌相结 合的全方位的竞争模式。

电信业正进入新一轮的高速发展时期,市场需求成为驱动力??市场部门不断推出的各种各样促销计划和市场推广活动,以及用于刺激用户使用运营商的服务 以扩大用户群的全新变化,使得计费账务系统必须实现非常复杂的资费、折扣的管理能力和资费批价的能力。随着电信业务的迅猛发展,电信运营商的计费账务系统 的压力也越来越大,如何保证计费账务系统的实时性成为各运营商关心的重点。

BSS系统是每个电信运行商的核心业务支撑系统。近年来,随着支持用户量和话单量的成倍增长和实时业务的不断扩展,数据处理量大量增加,业务处理模 式日趋复杂,必然导致主机CPU和I/O占用不断成线性增加。在此情况下,即使增加硬件支持,现有架构下系统的处理速度也很难得到质的提高。由此对业务产 生了极其不利的影响:账务功能不灵活,系统对业务需求的支撑灵活度不够;难以在短时间内响应市场需求,效率与灵活度难以兼得;计费实时性得不到确切的保 障,无法给用户提供实时准确的查询服务;账务批处理情况下可能造成与营业应用的性能相互影响。为此,现有的BSS系统进行框架结构上的全面改造已经是大势 所趋。

内存数据库介绍

1.什么是内存数据库

众所周知,相对于磁盘,内存的数据读写速度要高出几个数量级,将数据保存在内存中相对于从磁盘上访问数据能够极大地提高应用的性能。一方面由于从磁 盘上读写数据时需要进行磁头的机械移动,直接从内存中读写数据则是电信号的移动,两者速度完全不在一个数量级上;另外一个容易被忽略的时间就是系统调用时 间,因为每次对磁盘进行访问都需要进行一次操作系统的系统调用,而系统调用相对于普通的库函数调用要花费更多的时间。之所以要进行系统调用是因为处于用户 态的应用程序不能直接对外部设备进行操作,而需要进入内核态,由操作系统调用相应设备的驱动程序完成对设备的操作。系统调用一般是通过中断来完成 得,CPU只有在完成当前时钟周期的操作后在下一个时钟周期处理中断请求,并且在进行中断处理时需要进行上下文信息的保存与切换。所以一个应用如果频繁地 进行系统调用也会极大地降低系统地性能。正是由于这两方面的原因,使得从磁盘上读写数据比从内存中读写数据的时间开销要大得多。

传统的数据库管理系统的所有数据都是放在磁盘上进行管理,需要频繁地访问磁盘来进行数据的操作。如上所述,由于磁盘数据访问本身的性能瓶颈,数据库 管理系统的性能提升受到了很大的限制。然而,近年来,随着计算机技术的飞速发展,要解决这一问题已经有了现实可能:内存容量的不断提高,而价格不断下跌; 计算机进入了64位时代,操作系统可以支持更大的地址空间。

正是基于技术的发展,以及市场上对更加快速和实时的数据库管理系统的需求,出现了内存数据库系统。内存数据库系统抛弃了磁盘数据管理的传统方式,基 于全部数据都在内存中管理进行了新的体系结构的设计,并且在数据缓存、快速算法、并行操作方面也进行了相应的改进,所以数据处理速度一般比传统数据库的数 据处理速度要快很多,一般都在10倍以上。

2.内存数据库和磁盘数据库的性能测试对比

以下比较基于内存数据库和磁盘数据库中完全相同的数据库表结构和应用,测试对比的数据库为Oracle 9i和ALTIBASE 3.5.7,在相同的测试环境下进行。

表1 

INSERT:对oracle和ALTIBASE进行相同表的插入操作,查看插入的效率。


INSERT:对oracle和ALTIBASE进行相同表的插入操作,查看插入的效率。


3.内存数据库和利用程序吊用内存的对比

由于内存的高速特点,早在2000年以前就有通过进程吊用内存的方式来进行程序处理,内存数据库提供的是一个模块化结构,保持一个核心引擎相对不变,外围可变,提供标准扩展接口和灵活的二次开发能力和良好的流程优化能力:

在BSS系统中采用内存数据库的理由

拿江苏联通过去的BSS系统为例,账务处理模块的性能瓶颈是在计费处理和销账处理。

由于数据量大、用户资料量大、计费处理模型相对复杂、以Flist支持字段变化和格式可配置等原因,使得现在的计费处理速度相对较慢。而由于清单数 据量非常大,将其全部放入内存数据库中是不太可能的。为了利用内存数据库的高速度,则只能采取折中的方法,全部清单数据放在磁盘数据库中,根据实际情况只 将一段时间内的清单数据保存在内存数据库中,费用累计和优惠可以针对这一段时间内的清单数据进行一个事务性处理。其他数据,例如累计费用数据,用户资料, 费率和优惠信息等相对与清单数据来说数据量较小,可以直接放在内存数据库中。将数据加载到内存数据库中的基本原则是,数据经常用到且数据量不会很大,数据 查询操作比数据写和更新操作要频繁。除计费处理外,当其他业务应用需要用到这些数据时也都直接从内存数据库中取。

对于销账处理而言,由于在销账处理的过程中涉及到多张表,在用户请求缴费时,在数据库中会将查询出来的资料信息和费用信息放在两张临时表中,一个为 资料信息临时表,一个为费用临时表。由于所有缴费人员都同时用到这两张临时表,在传统数据库中往往出现大量争用,大大延长这两张物理表查询所需数据的时 间。将这两临时表放在内存数据库中后,由于内存处理速度远远快于磁盘IO,争用出现的可能大为降低,极大减少了单独事务的相应处理时间,得以满足大量并发 访问的要求。

图1 江苏联通BSS原账务处理流程

当然,如果不采用内存数据库来管理以上的数据,我们可以采取将这些数据组织成相应的数据结构,并用一些共享内存算法来进行查询和更新处理。但是从前 面提到的两者对比来看,这样做,开发量大,开发周期长,对程序员要求高;建立的系统也会难以维护、查询和二次开发,并且逻辑结构复杂,接口也难以扩展;而 最关键的是,数据完整性和一致性难以保障。相对于利用程序开发调用内存处理来说,内存数据库自有其优势。首先,内存数据库是产品化的数据库管理软件,已经 是完整的产品,极大缩短了开发周期;其次,内存数据库有着开放的平台和接口,程序开发和移植更加灵活便捷,也便于维护和二次开发;可以通过使用统一的 SQL语言方便的查询内存中的数据;在数据库中保障数据的安全性和完整性。这些优势,对于快速部署和简化维护都是有利的。

内存数据库在江苏联通BSS账务处理系统中应用的特点和效果

江苏联通在账务处理系统中采用了韩国的产品ALTIBASE内存数据库。为完成公司提出的计费实时性指标要求,我们认为只有从底层彻底改变整个账务 处理的体系架构,才能对性能有质的提高。ALTIBASE内存数据库管理系统是一个在事务优先的环境中提供高性能和高可用性的软件解决方案。在江苏联通运 用之前,在电信领域ALTIBASE内存数据库只有韩国SK有大型的全面解决方案。江苏联通在综合分析了SK的案例以及组织了多次大规模周详的测试后才决 定运用此产品。

江苏联通是国内第一家将内存数据库运用于大型支撑系统的运营商。因为账务处理模块是效率瓶颈最大、也是对系统压力最大的一个模块,对用户打电话后查 询话单的实时性感知度以及小额欠费都有较大影响,江苏联通重点针对账务处理系统引入了ALTIBASE技术,以便于提高客户满意度和减少费用流失。

自ALTIBASE内存数据库在江苏联通BSS账务处理系统中上线一年来,运行一直非常稳定。在应用中,只把最需要的中间数据放到内存库中,节省了 内存的开销又提高了效率,把好钢用在了刀刃上。因为原先的账务处理瓶颈就在于读取营账的用户数据以及写入账务中间数据的频次非常高,频繁的物理读写造成了 I/O的瓶颈,而且会影响前台系统的性能。通过采用复制技术将Oracle磁盘数据库中账务处理需要用到的营账数据实时复制增量数据到ALTIBASE内 存数据库中去,将处理好的中间账务结果也写入ALTIBASE,这样做到了只把造成瓶颈的数据放到内存中处理,也就是用最快速的存储资源解决了开销最大的 处理操作。另外,ALTIBASE内存数据库管理系统为需要容错服务的系统提供实时数据库复制的功能,采用联机日志的网络复制实现了双机之间数据的同步。 采用双机热备的方式,既实现了高可用性又实现了负荷分摊。在我们的设计架构中实现了双机热备,同时我们将前台的实时话费的查询接口都链接到备库上,这样就 实现了双机分摊账务和营业两种应用的功效。

图2 江苏联通BSS现账务处理流程

1.内存数据库在江苏联通BSS账务处理系统中应用的特点

(1)只把最需要的中间数据放到内存库中,节省了内存的开销又提高了效率,把好钢用在了刀刃上

因为原先的账务处理瓶颈就在于读取营账的用户数据以及写入账务中间数据的频次非常高,频繁的物理读写造成了I/O的瓶颈,而且会影响前台系统的性 能。我们采用了复制技术将Oracle磁盘数据库中账务处理需要用到的营账数据实时复制增量数据到Altibase内存中去,将处理好的中间账务结果也写 入Altibase,这样做到了只把造成瓶颈的数据放到内存中处理,也就是用最快速的存储资源解决了开销最大的处理操作。

2.采用双机热备的方式,既实现了高可用性又实现了负荷分摊

ALTIBASE内存数据库管理系统为需要容错服务的系统提供实时数据库复制的功能,采用联机日志的网络复制实现了双机之间数据的同步。在我们的设 计架构中,备机既实现了双机热备、同时我们将前台的实时话费的查询接口都链接到备库上,这样就实现了双机分摊账务和营业两种应用的功效。

3.投资保护

使用内存数据库可节省硬件投资和系统维护成本。通过对比,如果要达到目前的计费实时性指标要求,按照开发商的建议,要将CPU扩展到32个,内存 64G,同时系统开发商还要作大量的程序修改工作;而目前在10个CPU、95G内存上系统正常运行,CPU的平均占用率大约在55%--75%(原先为 95%)。按照常识,1G内存的价格约为1颗CPU的1/10。即节省了约19个CPU的投资。而在收益方面:根据指标数据,采用内存数据库后,平均小额 欠费率下降到老系统的55%左右,按此推算,每月给公司节约成本千万以上。

结束语

在当今电信领域,传统的一些支撑系统的架构已经逐渐不能满足日益增长的业务需求和客户需求,引入一些新的技术来解决我们生产中遇到的问题是必然的,这些新的技术架构很可能在今后会成为一种发展趋势,就像SAN替代DAS、关系型数据库替代传统数据库那样。

ALTIBASE在江苏联通BSS系统中的运用就是一个采用新技术架构实现系统目标的典型案例。主要有以下几点经验可以借鉴于同类的新产品的应用上:

(1)不轻易对现有架构做大范围的改动,保证框架稳定;

(2)控制成本、有效使用,将好钢用在刀刃上;

(3)针对系统中最主要的问题,投入最合适的产品或解决方案,实现既定的目标。

江苏联通在账务处理系统中率先采用ALTIBASE内存数据库体系架构,提高了系统处理速度2.5倍,使得系统的实时性大大提高,降低了小额欠费率、减轻对生产系统的压力。

内存数据库只是多种新技术中有代表性的一种而已,只要解放思想、选用得当,完全可以在投入不大的情况下以这类实用的产品解决系统中本来难以改变的瓶 颈。在未来的BSS发展方向中内存数据库会逐渐成长为一股中坚力量,在客户细分、用户行为分析、产品管理、欠费控制系统等需要复杂高速运算的系统中发挥作用。



Oracle将15亿美元收购云服务商RightNow

似乎没有人能阻止Oracle向云计算领域迈进的步伐,凭借强大的现金优势和数据库技术领先,Oracle不断通过收购来强化自己的新的探索。

消息链接: http://tech.it168.com/a2011/1025/1263/000001263778.shtml
甲骨文网站链接:http://www.oracle.com/us/corporate/acquisitions/rightnow/index.html

2011年10月25日,路透社消息,美国软件生产商甲骨文Oracle敲定一项协议,将以大约15亿美元收购在线客户服务公司 RightNow Technologies。此举引发市场揣测,认为其他所谓的云技术公司也将面临多宗并购.云技术公司通过互联网提供软件,数据和计算服务.

  甲骨文的出价合每股43美元,较RightNow周五收盘溢价20%.RightNow股价周一收盘暴涨19.41%至42.94美元.甲骨文收高2.33%报32.87美元.

  甲骨文正全力进军云技术市场,涉足的领域包括销售能力自动化,人力资源和数据库等系统.

  "RightNow从甲骨文得到的报价非常优惠,我认为不会有其他公司来抢亲.不会再有这样的估值了."Pacific Crest分析师Brendan Barnicle说.

   自1997年RightNow创始人Greg Ginaforte在自家一间空闲卧室中起家,到2010年该公司已经是营收超过1.85亿美元的大公司,并可与更大的同业 SalesForce.com(CRM.N: 行情)和在线营销软件生产商Constant Contact(CTCT.O: 行情)展开竞争.

  "相信甲骨文收购RightNow将给SalesForce.com的云服务业务带来更直接的竞争和更加难以应付的威胁,"Oppenheimer分析师Brad Reback说.

  多年来,市场一直传言甲骨文有意收购SalesForce.com来充实自己的云技术实力.另一个可能的收购目标是NetSuite(N.N: 行情),甲骨文执行长埃利森已经部分拥有该公司.

  但Rick Sherlund认为SalesForce.com并非不二之选,因为甲骨文正尝试拓宽"软件即服务(software-as-a-service)"这一整体业务模式,从而确保能够参与市场的全面竞争.

  RightNow如果接受其他方提出的更高报价,可能需要向甲骨文支付约6,000万美元的分手费.如果协议在某些条件下告吹,分手费或只需1,800万美元左右.RightNow发言人拒绝对交易进一步置评.

  甲骨文预期该宗交易将在今年底或明年初完成.

  会有更多并购交易涌现?

  分析师表示,甲骨文在过去一年里不断买入资产以弥补云技术服务方面的空白,收购了包括ATG,Inquira和FatWire在内的公司.

  "这次收购表明,甲骨文对于涉足云技术领域是认真的,"Susquehanna分析师Derrick Wood说,"不过我们认为,它不可能通过自体成长实现这一目标,如果想成为强大的竞争者,就需要借助收购来进入这一市场."

  分析师估算,甲骨文收购RightNow的价格约占其现金和投资总额的4%.

  但分析师认为,对小型云计算公司感兴趣的并非只有甲骨文一家,戴尔(DELL.O: 行情),惠普(HPQ.N: 行情)和微软(MSFT.O: 行情)等大型科技企业可能也有兴趣.

  Pacific Crest的Barnicle表示,收购RightNow的交易对整个行业有利,因为这预示着一波收购热潮将会来临.

  "我认为客户关系管理领域将继续有并购活动涌现,"Nucleus Research分析师Rebecca Wettemann说.

  消息披露後,RightNow的同业之一Egain Communications(EGAN.O: 行情)股价一度涨至7.98美元,最终收高10.45%报7.82美元。


内存数据库,顾名思义就是将数据放在内存中直接操作的数据库。相对于磁盘,内存的数据读写速度要高出几个数量级,将数据保存在内存中相比从磁盘上访问能够极大地提高应用的性能。同时,内存数据库抛弃了磁盘数据管理的传统方式,基于全部数据都在内存中重新设计了体系结构,并且在数据缓存、快速算法、并行操作方面也进行了相应的改进,所以数据处理速度比传统数据库的数据处理速度要快很多,一般都在10倍以上。内存数据库的最大特点是其"主拷贝"或"工作版本" 常驻内存,即活动事务只与实时内存数据库的内存拷贝打交道。显然,它要求较大的内存量,但并非任何时刻整个数据库都存放在内存,即内存数据库系统还是要处理I/O。

内存数据库是以牺牲内存资源为代价换取数据处理实时性的,内存数据库和磁盘数据库都是当今信息社会里每个企业所必须的关系型数据库产品,磁盘数据库解决的是大容量存储和数据分析问题,而内存数据库解决的是实时处理和高并发问题。两者的存在是相辅相成的,内存数据库的事务实时处理性能要远强于磁盘数据库。但是相对的,他的数据安全方面还没有达到磁盘数据库比肩的地步。
内存数据库将物理内存作为数据的第一存储介质,而将磁盘作为备份。随着电信业务的发展,系统对实时性的要求和对业务灵活修改的要求非常高,在此种情况下对于内存数据库的需求也越来越高。磁盘数据库的做法是将数据存入内存中进行处理,这种方式的可管理性及数据安全可靠性都没有保障。而内存数据库正是针对这一弱点进行了改进。

实际上,内存数据库并不是一项时髦技术,其出现于上世纪60年代末,但由于市场的需求原因在90年代后期才开始发展。作为新一代数据库,Altibase产品已经走向混合型数据库,其版本Altibase 4.0已经有一套自带的磁盘数据库,用户一旦购买了Altibase的内存数据库,就无须再购买磁盘数据库。它把热数据(经常被使用的、访问比较高的、经常要运算的数据)放在内存数据库里,而把历史性数据放在磁盘数据库里,可为用户进一步减少投资。
对于内存数据库而言,可以将同样数据库的部分内容存放于磁盘上,而另一部分存放于内存中。用户可以选择将数据存储在内存表中以提供即时的数据访问。若访问时间不紧急或数据存于内存中所占空间过大时,用户可将这些数据存入磁盘表中。

比如,在手机用户开始拔打电话时,如果应用基于内存数据库技术的混合数据管理引擎,就通过内存表检索其服务选项并立即验证用户身份,而将通话清单和计费清单归档到磁盘表中。从而,达到了速度与资源使用的平衡。

内存数据库的技术,一个很重要的特点,是可以对内存中的数据实现全事务处理,这是仅仅把数据以数组等形式放在内存中完全不同的。并且,内存数据库是与应用无关的,显然这种体系结构具有其合理性。内存引擎可以实现查询与存档功能使用的是完全相同的数据库,同时内存表与磁盘表也使用的是完全相同的存取方法。存储的选择,对于应用开发者而言是完全透明的。

对于内存数据库而言,实现了数据在内存中的管理,而不仅仅是作为数据库的缓存。不像其它将磁盘数据块缓存到主存中的数据库,内存数据库的内存引擎使用了为随机访问内存而特别设计的数据结构和算法,这种设计使其避免了因使用排序命令而经常破坏缓存数据库性能的问题。通过内存数据库,减少了磁盘I/O,能够达到了以磁盘I/O 为主的传统数据库无法与其相比拟的处理速度。

因此,内存数据库技术的应用,可以大大提高数据库的速度,这对于需要高速反应的数据库应用,如电信、金融等提供了有力支撑。
(以上引自 http://hi.baidu.com/bluesky0205/blog/item/2dde5d08df57fe9f0b7b8258.html

由于把大多数数据都放在内存中进行操作,使得内存数据库有着比磁盘数据库高得多的性能表现,这一特点非常契合电信企业运营支撑系统对实时性的要求。

电信业的竞争正在全方位地展开,这种竞争必然带来新的价值链模式以及新的计费方式,这些变化对目前的电信运营支撑系统是一个挑战。比如,多种业务的计费环节将不再是单一的按照时长或通信距离收取费用,而可能是根据时长、内容、使用量等多种参数的组合计费。为了应对这些挑战,电信企业先后引入了内存数据库,以提高后台数据管理的实时性、精确性和灵活性。

尽管内存数据库已不是传统磁盘数据库的概念,但是内存数据库本质上还是数据库,它也具有一般数据库的基本功能:

■ 永久数据的管理,包括数据库的定义、存储、维护等;

■ 完成各种数据操作,如查询处理、存取、完整性检查;

■ 事务管理,包括调度与并发控制等;

■ 对存取的控制和安全性检验;

■ 具有数据库的可靠性恢复机制。

相对于利用程序开发手段调用内存处理来说,内存数据库自有其优势。首先,内存数据库是产品化的数据库管理软件,极大缩短了开发周期; 其次,内存数据库有着开放的平台和接口,程序开发和移植更加灵活便捷,也便于维护和二次开发; 第三,可以通过使用统一的SQL语言方便地查询内存中的数据; 最后,能在数据库中保障数据的安全性和完整性。这些优势,对于快速部署和简化维护都是有利的。

内存数据库也有其不可避免的缺点,比如: 不容易恢复,内存数据库中的数据不总是永久的,为了保证实时,也不一定是一致和绝对正确的,有的是短暂的,有的是暂时不一致或非绝对正确的

电信企业一直是内存数据库的主要用户,近几年来,随着计算机硬件技术的飞速发展、内存容量的提高、价格下跌以及计算机进入64位时代操作系统后可以支持更大的地址,为内存数据库的实现提供了可能。目前内存数据库在电信行业的应用也日趋成熟,已有超过90G的电信系统案例,能自动扩展内存空间,不需要重启数据库,提供ESOL自定义存储过程,支持多线程,开发效率高,程序移植容易等等。

下面以两个例子来介绍内存数据库的应用
  1. 电信计费数据的加载
电信的二次批价和实时累账是计费系统中的两个必备功能。
所谓二次批价是相对于一次批价来说的。
一次批价是按照国家标准资费来进行价格计算,比如: 全球通每分钟本地通话为0.4元,在一次批价完成后,会根据这个用户的套餐进行再一次的计算。以北京全球通用户接听4分钟的电话为例,一次批价完成后,这条话单的价格是1.6元,如果这个用户参加了10元包月接听套餐,那么在二次批价后,这次通话的费用就为0元。
一次批价是用于各大运营商之间结算的,而二次批价是针对用户个人的。

实时累账是将用户从每月1号到目前为止的所有费用累加起来,也就是用户目前可以通过10086查到截止到前一天的实时话费。累账值可以帮助用户控制高额话费或是供用户即时查询消费信息。

二次批价和实时累账过程涉及用户资料、用户套餐等与用户相关的信息,电信支撑系统在开始批价时必须加载这些数据。稍大一点的省级运营商的这些数据就会超过1000万条,计费处理模型也由于套餐的组合、产品的组合以及不同的优惠规则变得相当复杂,加载这部分数据对系统而言是一笔不小的开销,这就使得现在的计费处理速度比较慢,而且很难做到对数据的实时更新。内存数据库的引入在一定程度上解决了这个问题。

在计费二次批价过程中数据量最大的是详单数据,这部分数据不用放在内存数据库中,每处理完一个话单文件或达到设定的提交记录数时直接操作磁盘数据库,不会影响系统性能。最急切的是将用户资料、套餐、营业套餐和计费套餐对应关系数据、计费套餐模型数据及用户累计数据放到内存数据库中,这部分数据查询操作远比数据新增和更新操作要频繁。除了这些数据外,当然还有应用需要的其他数据也都可以加载到内存数据库。

在采用内存数据库后,用户通过营业部或客户查询实时话费的时候完全可以做到实时,比目前只能提供查询到前一天的实时话费在业务上有了质的飞跃。因为系统在处理这部分数据时查询流程和以前的完全一样,但系统省去了以往内存中的数据和磁盘数据库数据同步的环节,所以就能做到了实时查询。对于信控来说也同样,以往系统在累完账后要按照一定周期刷新信控数据,这就存在一个时间差,不能够完全做到实时。

而采用内存数据库后,信控可以直接取得内存数据库中的实时话费累计表中的数据,完全实现实时预警、停机。二次批价和累账中采用内存数据库后,对防欺诈、收入保障系统也有相当大的好处,这样能够充分保证运营商的切身利益。

另外,在采用内存数据库后,整体提高了系统批价、累账的处理速度,大大缓解访问磁盘数据库的压力,提高数据查询、修改、删除的效率,也为后付费和预付费的融合提供了可能。

电信计费数据的同步
电信营业数据和计费系统中的数据总是在不断的变化中,这就涉及内存数据库中的数据和磁盘数据库数据的同步问题(为了描述清楚,这里的磁盘数据库以Oracle DB为例来说明)。数据同步包括两部分: 从内存数据库到Oracle DB数据同步和从Oracle DB到内存数据库的同步。

1. Oracle DB到内存数据库同步

这部分数据同步采用增量表的方式,营业系统或CRM新增或更新的数据将生成到Oracle的增量表中,计费后台程序先到这些增量表中查询数据。如果能在这些增量表中查到数据就把这些数据更新到内存数据库对应表中,如果查不到,就直接从内存数据库中直接查询,从而保证了数据的完整性和实时性。由于增量表的数据量一般会很小,所以这部分操作不会影响系统的性能。

2. 内存数据库到Oracle DB同步

由于Oracle的计费后台批价、累账数据几乎都加载到了内存数据库中,所以Oracle数据库对应的数据表将主要用于对内存数据库的数据备份。

用户最新的实时话费等信息都保存在内存数据库中,实时话费查询将直接连接到内存数据库中查询,保证用户得到最新的费用信息。信控也直接从内存数据库查询数据,因此对Oracle中的这部分数据已经没有实时性的要求。这时内存数据库到Oracle的同步可以由应用程序生成文件,定时地往Oracle数据库中同步备份,或者采用Oracle 存储过程在系统相对空闲时间段进行数据导入就可以了。

总体而言,由于市场与技术的快速发展,电信业务在不断扩充,其运营和管理不断优化,传统的一些支撑系统的架构已经逐渐不能满足日益增长的业务要求和客户需求,引入一些新的技术来解决我们生产中遇到的问题是必然的。比如采用内存数据库来代替以前的共享内存技术,使得原来在内存中不标准的东西,包括接口、格式和管理都标准化了。

内存数据库只是多种新技术中有代表性的一种而已,只要解放思想、选用得当,完全可以在投入不大的情况下克服系统中的瓶颈,以最小的代价获得最大回报。

(以上内容引子: http://www2.ccw.com.cn/07/0712/b/0712b06_3.html ) 

 

通用数据库大家见的多了,Oracle、Db2、Sqlserver、Sybase、Informix 还有最近比较火的Mysql、和Pqllite,当然还不能忘记开源的PostgreSQL。通常情况下这些数据库可以承担重要业务,但是在要求高性能方面还是略有不足。在计费系统中如果用户信息常常改变的话延迟方面就会产生比较大的影响,甚至能影响到计费系统的正常运行。


我接触到唯一的内存数据库就是亚信在中移动计费中心稽核系统中使用的由于稽核系统需要实施同步用户状态信息和订购信息,然后对产生的话单进行稽核,如果响应速度 较慢的话就会产生错误的结果。最初没有稽核系统的时候,计费的标准基本是sp发过来的,然而用户方面却经常发现自己没有实际使用或者已经取消这项业务的时 候,自己的帐单中仍然收取了费用,因此中移动决心要对sp的话单进行稽核,以自己的数据为标准,彻底剪断sp乱收费的手段


如果要取到用户状态信息和订购信息的话就要从多个系统中同步过来,同时对话单进行稽核,中间的处理时间要求比较严格(用户可能会在短时间内检查自己的话费信息),对系统响应时间就要尽量短。


通用数据库在这方面处于劣势。亚信就以三台rx8420作为数据库主机,将31个省用户的信息按照数量的多少分担到三台主机,每个省至少有一个入库进程,对于用户比较多的就采用多个进程进行入库。数据的采集来源主要是通过BOSS和计费的一级系统。


由于数据是存储在内存中,所以存储的数据结构和通用数据库有所差异,同时为了保证数据的安全,在磁盘上有一个内存数据的镜像,每隔一定时间将内存中的数据同步到磁盘上,当主机故障时可以通过磁盘恢复数据。当主机故障时,会有备用主机通过HA接管。但是对于数据操作的日志和回滚就没有Oracle做的好了,只提供了简单的恢复机制。


在计费系统中首先要对sp发来的话单进行稽核,主要标准是用户状态和订购信息。例如用户最近7天一直处于关机状态,如果sp的话单中出现新的订购信息就将此条话单作为错单处理。移动通过这种方式在和sp的博弈中取得主动。稽核系统上线后用户对于sp的投诉问题明显减少。

(以上内容引子: http://flying-madman.blogspot.com/2007/10/blog-post.html

链接一:内存数据库与传统数据库的异同

传统的数据库系统是关系型数据库,开发这种数据库的目的,是处理永久、稳定的数据。关系数据库强调维护数据的完整性、一致性,但很难顾及有关数据及其处理的定时限制,不能满足工业生产管理实时应用的需要,因为实时事务要求系统能较准确地预报事务的运行时间。

对磁盘数据库而言,由于磁盘存取、内外存的数据传递、缓冲区管理、排队等待及锁的延迟等使得事务实际平均执行时间 与估算的最坏情况执行时间相差很大,如果将整个数据库或其主要的"工作"部分放入内存,使每个事务在执行过程中没有I/O,则为系统较准确估算和安排事务 的运行时间,使之具有较好的动态可预报性提供了有力的支持,同时也为实现事务的定时限制打下了基础。这就是内存数据库出现的主要原因。

内存数据库所处理的数据通常是"短暂"的,即有一定的有效时间,过时则有新的数据产生,而当前的决策推导变成无 效。所以,实际应用中采用内存数据库来处理实时性强的业务逻辑处理数据。而传统数据库旨在处理永久、稳定的数据,其性能目标是高的系统吞吐量和低的代价, 处理数据的实时性就要考虑的相对少一些。实际应用中利用传统数据库这一特性存放相对实时性要求不高的数据。

在实际应用中这两种数据库常常结合使用,而不是以内存数据库替代传统数据库。


链接二:几款内存数据库产品

■ Oracle TimesTen

Oracle TimesTen是Oracle从TimesTen公司收购的一个内存优化的关系数据库,它为应用程序提供了实时企业和行业(例如电信、资本市场和国防) 所需的即时响应性和非常高的吞吐量。Oracle TimesTen可作为高速缓存或嵌入式数据库被部署在应用程序层中,它利用标准的 SQL 接口对完全位于物理内存中的数据存储区进行操作。

■ Altibase

Altibase是一个在事务优先的环境中提供高性能和高可用性的软件解决方案。它提供高性能、容错能力和事务管 理能力,特别适合通信、网上银行、证券交易、实时应用和嵌入式系统领域。Altibase能够最大限度地发挥数据库服务系统的潜力,增强数据服务器的处理 能力。Altibase支持客户端/服务器架构或嵌入式架构。其中客户端/服务器架构非常适合一般的应用。而嵌入式架构将应用程序嵌入到数据库服务器,适 合于有高时效要求的实时系统。

■ eXtremeDB

eXtremeDB实时数据库是McObject公司的一款特别为实时与嵌入式系统数据管理而设计的数据库,只有 50K到130K的开销,速度达到微秒级。eXtremeDB完全驻留在主内存中,不使用文件系统(包括内存盘)。eXtremeDB采用了新的磁盘融合 技术,将内存拓展到磁盘,将磁盘当做虚拟内存来用,实时性能保持微秒级的同时,数据管理量在32BIT下能达到20G。


Pages

Powered by Movable Type 6.3.2

About this Archive

This page is an archive of entries from November 2011 listed from newest to oldest.

October 2011 is the previous archive.

December 2011 is the next archive.

回到 首页 查看最近文章或者查看所有归档文章.