刚才帮一个朋友看了一个案例
创建一张很普通的表，居然报ORA022914,NESTED TABLES NOT SUPPORTED。这也太离谱了吧。怎么办呢？马上做个10046TRACE，看看到底哪里报错吧：=====================PARSING IN CURSOR #12 len=70 dep=2 uid=0 oct=3 lid=0 tim=1227340204003259 hv=3849548163 ad='30ad511c'select intcol#,nvl(pos#,0),col#,nvl(spare1,0) from ccol$ where con#=:1END OF STMTEXEC #12:c=0,e=26,p=0,cr=0,cu=0,mis=0,r=0,dep=2,og=4,tim=1227340204003255FETCH #12:c=0,e=25,p=0,cr=3,cu=0,mis=0,r=1,dep=2,og=4,tim=1227340204003353FETCH #12:c=0,e=9,p=0,cr=1,cu=0,mis=0,r=0,dep=2,og=4,tim=1227340204003392STAT #12 id=1 cnt=3 pid=0 pos=1 obj=32 op='TABLE ACCESS BY INDEX ROWID CCOL$ (cr=10 pr=0 pw=0 time=78 us)'STAT #12 id=2 cnt=3 pid=1 pos=1 obj=54 op='INDEX RANGE SCAN I_CCOL1 (cr=7 pr=0 pw=0 time=54 us)'FETCH #3:c=0,e=10,p=0,cr=1,cu=0,mis=0,r=0,dep=2,og=4,tim=1227340204003490STAT #3 id=1 cnt=2 pid=0 pos=1 obj=31 op='TABLE ACCESS BY INDEX ROWID CDEF$ (cr=8 pr=0 pw=0 time=62 us)'STAT #3 id=2 cnt=2 pid=1 pos=1 obj=51 op='INDEX RANGE SCAN I_CDEF2 (cr=6 pr=0 pw=0 time=45 us)'EXEC #5:c=361945,e=377347,p=5,cr=2084,cu=0,mis=0,r=0,dep=1,og=4,tim=1227340204003645ERROR #5:err=22914 tim=1295043034XCTEND rlbk=1, rd_only=1STAT #8 id=1 cnt=3 pid=0 pos=1 obj=0 op='SORT ORDER BY (cr=206 pr=0 pw=0 time=16251 us)'STAT #8 id=2 cnt=8498 pid=1 pos=1 obj=702 op='TABLE ACCESS FULL RECYCLEBIN$ (cr=206 pr=0 pw=0 time=17690 us)'EXEC #4:c=574912,e=601099,p=6,cr=4376,cu=30,mis=0,r=0,dep=0,og=1,tim=1227340204003956ERROR #4:err=604 tim=1295043034*** 2009-10-29 14:06:47.644一看10046 TRACE就发现问题了，'TABLE ACCESS FULL RECYCLEBIN$ ，检查一下RECYCLEBIN吧，一检

点击此处查看原文

说实在的流复制环境虽然也帮客户实施过几个，但是大多数还是单向单目标的项目。虽然也做过一对多的单向复制，但是都是在局域网环境或者网络带宽超过100M的广域网环境。这回听说客户是做一个三个节点的双向复制，不免对带宽有些担忧。客户申请的DDN是10M的带宽，据说通过测算，实际生产环境的数据量顶多4、5M的带宽就能支持了。在局域网中做测试的时候双向复制都很正常，所以系统就按计划上线了。由于复制节点在外省，因此我们在主生产系统上exp导出数据，然后通过ems将硬盘快递到容灾中心，然后倒入数据。倒入数据后，启动主生产系统上的capture，开始捕获数据并在两个目的服务器上同步数据。我们的计划是当两台服务器和主生产系统同步后，再启动这两台服务器上的CAPTURE，真正实现三节点的双向复制。开始的时候复制进度很正常，生产数据和复制数据之间的差异大约为230000秒，将近3天的数据延时。我们通过监控脚本发现大约一小时可以减少一个多小时的延时，也就是说大约2

点击此处查看原文

数据库HANG住，最后被迫重启。是一个RAC环境，10.2.0.4详细情况参考附件 TRACE太大了，直接上传： http://www.oraclefans.cn/rpt1_ora_4974.rar 该贴被白鳝编辑于2009-8-25 7:00:08

点击此处查看原文

昨天有一个朋友安装CRS的时候无法找到节点：$ ./cluvfy/runcluvfy.sh stage -post hwos -n node1,node2 -verbosenotice: JAVA_HOME not set in the environment.Performing post-checks for hardware and operating system setup Checking node reachability...Check: Node reachability from node "node1"  Destination Node                      Reachable?                ------------------------------------  ------------------------  node1                                 no                        node2                                 no                      Result: Node reachability check failed from node "node1".碰到这个问题，首先我问他hostname是否就是Node1，node2，而且这两个地址是否正确的在/etc/hosts里定义了。他回答是这些都没错，然后我问他网卡的顺序是否正确，在HP-UX下有时候私网和公网的网卡在两台服务器上的设备名不对应，也可能会出一些莫名其妙的错误。经过确认都没问题。检查hosts文件和services文件的属性，也都没问题，world有r的权限。看样子问题不是出在这些地方。那么下面该怎么处理呢？我建议他用tusc跟踪一下，看看能有什么发现。很快在tusc里面我们发现了疑点：stat("/usr/sbin/ping", 0x742ff5e4) .................................................................... = 0access("/usr/sbin/pi

点击此处查看原文

为了更好的抓取TOP SQL，今天上午的时候，我就对STATSPACK进行了一些特性化的配置，缺省情况下，STATSPACK做SNAP的时候，对TOP SQL的抓取是根据一些阀值的，这些阀值参数定义在STATS$STATSPACK_PARAMETER这个表中，这张表的结构如下DBID                                      NOT NULL NUMBER

点击此处查看原文

1.1.1. 8月17日 继续优化昨天的系统级调整的效果很好，因此昨天晚上我走之前客户希望今天再帮他们优化一下应用。由于开发厂商那边的开发人员都是在公司开发，现场的人员都是负责上线的，他们对应用也不是十分熟悉，因此直接找开发人员了解情况就不可能了。为了对目前的应用进行细致的分析，今天一早我就和秦工一起设计了一个应用分析的方案。由于开发厂商编写了一个简单的测试工具，可以部分模拟系统中的主要功能，因此我们把STATSPACK的SNAP LEVEL提高到了7级，每30分钟自动做一个SNAP采样。然后让测试人员激活测试工具，进行一上午的测试，然后下午我们从STATSPACK采集的数据中查找存在问题的SQL。对于目前感觉存在性能为题比较严重的几个模块，我建议通过10046 trace来抓取TOP SQL。因为这几个模块都是用ORACLE DEVELOPER开发的报表程序。等应用连接数据库后，我通过oradebug对这个会话设置了8级的10046事件。然后让测试人员对存在问题较多的报表逐一测试。我准备使用trca进行10046 trace的

点击此处查看原文

在RAC环境下，提高DB CACHE的命中率不仅仅能够减少IO，而且能够减少INTERCONNECT带来的开销，从而大幅度减少global cache相关的等待事件。从这个系统来说，gcs虽然没有性能问题，不过还是有提高的余地的。因此我建议秦工把DB CACHE的大小由10G加大到14G。从共享池的命中率来看，96%的命中率在OLTP系统来说不算低了，不过在RAC环境下，library cache lock等待的成本远高于单机环境，从STATSPACK报告上可以看出，目前sql miss的比例达到31%，LIBRARY CACHE LOCK闩锁的丢失率也达到1.2%，加大共享池对提高LIBRARY CACHE的性能还是有帮助的，于是我建议秦工把共享池加大1G。这个系统是采用了自动负载均衡的模式，没有针对RAC进行应用分区的设计，我和秦工讨论过这个问题，秦工认为目前再去考虑这个问题有点晚了，所以我们只能在这个框架下进行优化。在监控过程中，我们看到了大量的PX等待事件，这是由于这个系统中存在大量的统计模块，这些模块做了大量的全表扫描，为了提高全表扫描的性能，在很多SQL中加了PARALLEL提示。我检查了一下并行查询，发现存在

点击此处查看原文

1.1.1. 8月16日 系统级的调整昨天帮助秦工处理了几个小的应用性能问题，秦工最终还是比较满意，下午3点多钟就给我签了8小时的服务单，放我走了。今天本来是没什么事情了，不过秦工他们今天要做一次比较大规模的仿真测试，所以他还是希望我过来帮他们做一下检查，看看数据库参数方面有什么需要调整的没有。秦工他们的仿真测试规模很大，他们安排了一个持续1个半小时的仿真测试，为了完成这个仿真测试，他们在几个培训教室和大会议室中安排了200多台终端，除了从各业务部门征调了大量操作员参与外，还专门从专业的测试公司雇佣了近百名操作员。仿真测试的安排是，第一轮测试30分钟，然后留下30分钟的分析与调整的时间，然后再进行第二轮的30分钟测试。这种安排是十分好的，第一轮测试后，我们还有时间对第一轮测试的数据进行分析，并且做出一些简单的调整。测试进行之前，我问秦工，这样的仿真测试和真实的情况的仿真度有多大。秦工说他们是找了专业的仿真测试公司啦设计的这个测试，模拟的业务和平时业务系统差不多，准备模拟的负载是目前生产系统平时业务量的2倍。我以前也参加过不少压力测试，有的规模比这个大的很多，甚至有上千人参与。不过那些测试的仿真度都不高，和实际生产环境差别比较大。我很想知道这种高仿真的测试时如何组织的，和秦工聊了半天，秦工回答这个问题的时候有些支支吾吾的，看样子是不太方便，只是告诉我为了这个测试，他们花了不少钱。隔行如隔山，看样子不论做什么，做出特色

点击此处查看原文

我在新系统上执行了一个不带FOR UPDATE的普通SELECT 语句，这个语句很快就结束了，大概返回了30万条记录（为了方便测试，执行SQL前首先在SQL*PLUS中设置了set autotrace traceonly），执行时间大概是5秒多钟。然后我加上了FOR UPDATE子句，一下子变得相当的慢，大概需要3分多钟。秦工说以前这个SQL在生产环境中只需要20秒钟左右就可以完成，而现在在没什么业务在跑的测试环境中居然要将近1分钟，这是无法接受的。这个SQL是一个定期JOB的一部分，每10分钟要调度一次，如果这么慢，将会影响很多业务。我考虑了一下，从原理上看，SELECT FOR UPDATE语句由于需要上锁，因此比SELECT操作慢是很正常的现象。但是如果在老系统上不到20秒钟可以完成的操作，在新的RAC环境下慢了2倍以上，那就很不正常了。我想在生产环境下执行以下这个SQL来测试一下，秦工不同意我这么做，因为这个SQL会锁住大量的数据，可能会影响到生产系统。于是在秦工的同意下，我用DBA_OBJECTS创建了一张测试表。想通过对这张测试表的分析找到问题的所在。测试表创建好后，我在两台服务器上分别做了一次测试，确实发现在RAC下要慢不少。不过第二次执行这个SQL的时候，RAC环境下的执行速度明显要快一些，基本上和生产库上速度差不多了。难道是第一次执行的时候物理读的速度不同？按理说目前RAC环境下的存储性能应该和生产库差不多，起码也不会低于生产库，因为目前测试环境中没有什么业务在跑。于是我又分别在两套环境中重新创建了一张相同的表，然后设置了10级的10046 trace(alter session set events='10046 tra

点击此处查看原文

1.1.1. 8月10日 及时雨昨天晚上回到酒店已经10点多了，所以也没有干活直接洗洗睡了。一觉睡到早上8点半，起床后打开电脑看看昨天开的tar有没有什么新的回复。我在firefox的scrapbook插件中选择了更新文档选项，发现有个叫Kunal的印度工程师对这个tar做了一个简单的回复：CAUSE DETERMINATION

点击此处查看原文

 今天是元旦小长假，原本是休息的日子，不过要想成为一个合格的DBA，为了自己的大好前途，我们就马上开始oracle之旅吧。如果你已经了解了SQL预言的基础知识，并且 知道一些关系型数据库的知识，那么从今天起老白带着大家一起开始从最基础的知识学起，成为一个DBA吧。今天我们要学习的内容是“表”，可能有很多朋友已经知道“表”是什么了。Oracle数据库是一种关系型数据库，关系型数据库里，一组关系的实体化就可以组成一张表。表里面有一个或者多个字段，这些字段按照某种规则（我们称为关系）组成一个集合，每个关系我们就称为一行数据，也就是我们常说的一条记录。实际上只要你已经有了关系型数据库的概念，那么就不需要我多说表、记录、关系之类的术语了。实际上表是oracle数据库中十分重要的对象，实际上DBA很大部分的工作就是和不同的表，不同的数据打交道。Oracle的表是

点击此处查看原文

V$RESOURCE_LIMIT会引起TNS-12516吗？这两个好像不相干的东西确实存在着一定的联系。今天一个客户突然说他们的系统报TNS-12516,他检查了PROCESSES设置为3500，而从v$process里看到的进程数量只有1500多，通过ps -ef统计，也是看到1500多个进程。为了业务系统正常运行，客户只好杀了几十个进程。算是暂时安定下来了。不过过了一阵子又出问题了，只好再杀进程。我让他检查了一下V$RESOURCE_LIMIT，一检查就发现问题了，在V$RESOURCE_LIMIT里CURRENT_UTILIZATION 居然高达2800多，而这个时候V$PROCESS里只有1300多条记录。高出了一倍还不止。这和BUG 3896119的情况十分类似，由于这个BUG，V$RESOURCE_LIMIT里的统计值是错误的。而PMON向LISTENER通报负载的时候是参考V$RESOURCE_LIMIT的值的，因此造成了LISTENER错误的拒绝连接。想了解更详细的情况，请看附件吧 

点击此处查看原文

今天公司的几个兄弟给客户做健康性检查。报告发到我这里3次，都被我退回去了。原因是我觉得哥几个没尽力。确实在这么短时间里做8、9个库的检查，工作量不小，因此质量下降也是难免的。最后我和哥几个说，这件事，如果你当成工作来做当然是能简单就简单。如果当成一门手艺，那你们要对得起这门手艺。以前的手艺人很在乎自己的手艺，因为这是混饭吃的家伙。手艺的好坏决定了这个人的生存，因此手艺人都很重视自己的手艺。哪怕不赚钱，不好的手艺是不能亮出来的。现代人的选择多了，很多人看不起手艺人。而实际上，我们做DBA的，不也是在卖手艺来谋生吗？有些事情，当成工作来做，可能缺少乐趣，不如把工作当成手艺，这样可能会有更多的乐趣。

点击此处查看原文

为了便于大家阅览，将把这两部小说的发布地址变更http://blog.oraclefans.cn/baishan2   IT的Ihttp://blog.oraclefans.cn/baishan1  DBA日记  

点击此处查看原文

RAC这个东西已经出现了超过10年了（以前叫OPS），如果说CLUSTER，那么第一套VMS CLUSTER出现到现在都20多年了。在国内也越来越多的系统使用RAC。但是对于RAC，还是有很多不同的声音。我今天所说的也只是我个人的一些观点，也算是一种声音吧。对于RAC，目前可以听到两种截然不同的声音。一种是RAC无所不能，一种是RAC很危险。甚至有些DBA喊出了珍惜职业前途，远离RAC的口号。我曾经听一个客户说，他们在购买前，Oracle的销售就忽悠说RAC好，好像不买RAC,这个系统肯定出问题。而实施的时候，应用开发厂商和Oracle的实施人员又拼命的劝说他不要用RAC.最后系统上线后变成RAC虽然装了，但是业务在一台机上跑，另外一台机只是作为备机使用。以我这几年应用开发和维护的经验，RAC从技术上来说是很成熟的，Oracle宣传中的大部分是可信的。但是RAC系统和单机系统有着太多的不同，对于RAC系统的维护有着太多的维护要求。如果你的DBA团队还不能提供这样的维护，那么一个RAC系统出故障的可能要远大于单机系统。但是对于一个维护的很好的RAC系统，也可以是十分稳定的。用不用RAC，要从几个方面来考虑：1、你是否真的需要使用RAC，单实例无法负载你的业务吗？实际上我见过的很多客户，其业务完全可以在一台单实例的服务器上完成，使用RAC只是领导从安全性的考虑。这种情况下，使用HA或者RAC系统单实例负担业务可能在维护上更为简便。2、如果你的业务成长性特别强，而前期不想投入过多的资金，那么使用CLUSTER技术来实现可扩展性是最佳的选择方案，当一个节点处理能力不足的时候，可以通过添加节点来进行扩展，这种扩展成本最低。国内的用户往往习惯于购买更大的更多CPU内存的机器来实现系统的扩展，因此在国内看到的RAC系统也大多数是双节点的。而在国外经常看到很多大公司的某个系统是由一个10多个LINUX节点组成的RAC系统。当然实现这种可扩展性要在最初的应用设计方面做很多工作，这也是我们目前比较欠缺的。3、你的DBA是否有足够的能力来应对RAC维护中的问题？搞公司的人都知道，有什么样的人，做什么样的业务。做维护也是一样，如果你目前的技术队伍还无法承担这样的维护任务，那么只有2两个选择，一是暂时不上RAC,一是找一个专业第三方服务团队来协助你。前几天有个客户问我，目前他们有个系统CPU/内存都比较紧张，正好有一台服务器空下来了，把它加到现有的一个双节点RAC中，做一个3节点RAC，有多大

点击此处查看原文

在这场灾难面前，我终于看到了一个异常团结的中华。改革开放这么多年来，中国人的物质生活水平极大的提高了，但是我们也失去了很多，包括欢乐、自尊和精神。也许现在很多年轻人已经对雷锋陌生了，很多年轻人会对雷锋精神嗤之以鼻。这是中国人的悲哀。我们失去了太多的精神上的东西，有了太多的物质也会感到十分空虚。而在这场灾难面前，我看到了一个坚强的中华，看到了一群真正的中国人，无论是受灾的群众，还是我们的解放军战士，包括奋斗在救灾前线的志愿者，为灾区慷慨解囊的民众和企业家。这几天大家看到的才应该是被儒家思想沐浴了5000年的中华民族应有的面貌。在灾难面前，积压在大家潜意识里的善良和慈爱都爆发了出来。我们的政府能否适当的进行引导，唤醒大家心灵深处的善良呢？我想这是我们的政府应该好好考虑的，这是一个十分好的契机。27年前的一场足球比赛的胜利，让北京的学子喊出了令一代人振奋的“团结起来，振兴中华”的口号。随着物质方面的提升，80后的一代人估计很少能够知道这句口号了，甚至已经缺少了应用的民族精神了。我们需要新的口号来激励我们的民族，而这次灾难面前，中华民族再一次被凝聚在一起，我们应该提出一个新的，能够振聋发聩的口号，来振兴我们的民族精神。 

点击此处查看原文

中国遭遇了30年来最严重的灾难。深刻的感受到人在自然面前的无助。作为一个IT从业人员，能为这个国殇做点什么呢？一点绵薄的捐赠，从心里为四川加油，为中华加油。看到很多在灾区奋力拼搏的志愿者，为他们感到骄傲。前几天在外面出差，和几个朋友聊到志愿者，说我们这些手无缚鸡之力的人，能不能为灾区重建做点事情呢。有个朋友就说，由于地震和停电，肯定有大量这样的IT系统出现了故障，甚至会损坏。我们组织一个团队，为灾区因地震灾害而受损的IT系统提供免费的修复工作，这样也算是我们为灾区做点力所能及的事情。我想这个主意确实还有点道理，为灾区重建，哪怕做一些小事，也是好的。我想，有这样想法的朋友应该不少，如果有人了解这方面的渠道，请别忘记通知我。

点击此处查看原文

前一阵子给客户处理一个故障，这个故障已经重复发生了多次，几乎半个月不到就会重现。在Metalink上开了个tar，由于很多日志缺失，Oracle方面也无法进行继续的分析。我接到资料后，第一反应是存在BUG，但是随着我分析了几十个类似的BUG后，发现虽然在表象上很类似，但是没有一个真正吻合。通过经验，我将疑点放到了OS上，并提出了优化方案。由于日志方面的缺失，很多东西只能靠猜测。做过调整后，我在报告里提出，这个问题还没有完全定位，如果调整后2个月故障未重现，说明这次调整是成功的，但也不能说是彻底解决了这个问题。因此系统监控还要继续，开的tar也要继续跟进，也许Oracle那边会提出一些好的建议。客户的系统是一个十分重要的系统，如果出现故障将会承受十分巨大的经济损失，还会导致大客户的流失。因此客户对我的这个结论并不放心。虽然已经过去了半个多月，故障没有重现，但是客户还是不放心，因此他们又找了一家公司协助诊断这个故障，那家公司很快给出了一个故障分析报告，在报告里，用十分肯定的口气确定了这个故障和2个BUG有关。建议客户按照BUG报告上的内容进行处理。客户告诉我，说问题的原因找到了，北京一家公司，用了不到一天就定位了这个问题。我问他最终的结论是什么，客户就说了那2个BUG，我说你把报告给我看看，肯定有问题，因为这两个BUG我都分析过，其中一个第一时间我也怀疑是问题的根源，后来随着分析的深入被第一时间排除了。另外一个BUG在我们这个平台上根本不肯能存在，因为在我们的平台上根本没有这个模块。后来我也看了这份报告的部分章节，真是一把辛酸泪，满纸荒唐言。整个报告从格式、语气上来说都十分严谨，分析也是丝丝入扣，让人不得不信服。对于缺乏足够专业知识的客户来说，这种报告的杀伤力是巨大的，一切都是用十分肯定的口气，让人觉得十分的可信。我把报告中的疑点一点一点的和客户解释后，他觉得有种上当受骗的感觉。无疑，那份报告在商业上是成功的，如果没有我的介入，可能这份报告会带来巨大的商业价值。而我写报告的习惯是问题的分析过程十分明晰，我会把我的观点一览无余的告诉客户，包括我无法确定的事实。对于客户来说，最希望的是听到好消息，对于坏消息，他们虽然愿意知道，但是坏消息总是会让他们的心里产生一定的阴影。但是无论如何，我的原则是让客户知道他们应该知道的，我不会隐瞒任何东西，我会把我没有把握的东西第一时间让客户知道，是或者不

点击此处查看原文

最近总有人问我，做DBA，深入理解Oracle的原理有没有用，比如很多人喜欢DUMP Oracle内部的对象，这对于DBA提高能力有没有帮助。我的观点是：1、在学习初期，建议不要过于深入了解理论，因为那个时候主要是铺面，Oracle技术十分庞杂，就是花上1、2年时间也只能了解其中的一些侧面。如果要十分全面的了解Oracle的功能，就没有时间去做十分深入的理论研究。另外初学阶段，Oracle的一些基本概念没有很完整的形成，这个时候，你可能把某个Oracle内部原理搞清楚，但是这对于你把Oracle的知识串起来帮助不大。因为你的理解能力还不能达到一定的水平。初学者总是很羡慕别人能够做十分复杂的研究和实验，总想自己亲自去尝试一下。我的建议是，在这个阶段，深入分析某个Oracle的内部原理，还不如认认真真的读几遍Oracle concepts2、当你已经达到一定层次后，理论学习和研究对你的DBA工作是十分有帮助的。特别是积累了一定的维护经验后，再来理解哪些原理性的东西，会有更大的收获。如果有DBA问我，为什么某个数据库的临时表空间启动后，没什么操作，也是100%，空间怎么不能释放呢？那我会给他一堆关于临时表空间和临时段的资料，让他先看明白再来问这个问题。对于一个处于初级阶段的DBA来说，问这个问题，是有情可原的，但是这句话如果出自于一个有经验的DBA之口的话，那么我会建议他尽快再去研究一下CONCEPTS，在这个阶段，理论知识对于维护实践的帮助十分的大。这个时期，应该多关注一些Oracle内部原理性的东西，这些理论有助于形成正确的思路。比如上面的例子，如果你了解了临时表空间的工作原理，SORT EXTENT POOL的机制，就不会问出这样的问题了。由于这个阶段，知识面已经比较宽了，实践经验也具备了，可以对某些基本的机制进行原理性的分析，比如共享池、DB CACE/DBWR、REDOLOG、UNDO、CHECKPOINT、CONTROL FILE、TEMP SEGMENT等等。但是这个阶段还不宜过于深入，因为要学习和研究的东西太多，过于深入需要太多的时间。3、当你已经突破了某个层次的时候，你会发现，你又遇到了一个瓶颈，经验在不断的丰富，但是总的技术水平提高却很缓慢。这个时候你就需要更深入的分析原理了。因为在上个阶段你只是初步的了解了一些原理性的东西，很多更为细致的内容你还没有了解。不把这些东西了解清楚，可能会影响你的水平的提升。这个时候，你就需要把一些关键的技术深入的分析，并把各个独立的部件关联起来。这个时候，原理性

点击此处查看原文

附件发表于Oracle技术通讯2007年春季版，针对应用系统生命周期的各个阶段，提出各种针对性的数据库服务。该贴被白鳝编辑于2008-4-6 9:40:56

点击此处查看原文