Author: mac

作者为:  SHOUG成员 – ORACLE ACS高级顾问罗敏   Oracle公司自10g版本开始就推出了集群管理软件CRS，以后又升级改造成Clusterware，到11g版本之后更是大动干戈，内部架构进行了大幅度改造，并与ASM技术整合在一起，称之为GI（Grid Infrastructure）。Clusterware替代了硬件厂商和第三方厂商的集群软件功能，也使得Oracle RAC与Clusterware集成为一体，在产品的整体性、服务支持一体化等方面具有显著优势。 作为新产品、新技术，稳定性、成熟性略差，情有可原。但到了11g仍然如此，则让人难以理解了。 本人最近在Windows 2012平台实施了2节点11.2.0.4 RAC，并通过增加节点方式扩展到了4节点RAC，在国内实属罕见案例。期间一些波折，表明 Clusterware产品仍然不成熟。 话说那天我在实施节点扩展操作之前，先花费了半天时间进行了新节点的环境准备之后，并通过如下命令进行了环境检查： cluvfy stage -pre nodeadd -n hsedb3 –verbose   … … 节点 “hsedb3” 上的共享存储检查成功   硬件和操作系统设置 的后期检查成功。 哟，一切都“成功”，开练了！于是，我按照Oracle文档标准流程在节点1开始运行AddNode.bat脚本了，一切“正常”！我继续在节点3运行了gridconfig.bat等脚本。 待所有脚本顺利运行完之后检查环境时，却发现节点3根本没有加入到集群环境中，节点3上的Clusterware服务也根本没有启动。—– 这就是产品的严重不成熟，明明出问题了，所有脚本却不显示任何一条返回错误，显示一切正常！更可气的是，AddNode.bat脚本的日志文件（addNodeActions2014-09-07_04-52-22PM.log）也居然显示一切正常，最后还来一句： *** 安装 结束 页*** C:\app\11.2.0\grid 的 添加集群节点 已成功。 我知道Oracle支持在Windows平台进行RAC加节点操作，但现在没有成功，一定是我犯什么错误了，也肯定知道有什么错误信息藏在什么鸟日志文件里了。无奈天色已晚，忙乎一天了，于是先打道回府了。 隔日，待我回到现场仔细分析各类Clusterware日志文件信息时，首先在alerthsedb3.log文件中大海捞针般地发现了出错信息： [cssd(4484)]CRS-1649:表决文件出现 I/O 错误: \\.\ORCLDISKORADG0; 详细信息见 (:CSSNM00059:) (位于 C:\app\11.2.0\grid\log\hsedb3\cssd\ocssd.log)。 于是，按图索骥继续去查询ocssd.log文件中的信息。又像侦探一样，在ocssd.log文件8千多行的日志信息中发现了如下错误信息： 2014-09-07 17:00:06.192:…

作者为:  SHOUG成员 – ORACLE ACS高级顾问罗敏     问题和需求 “你们Oracle公司有这样的自动扫描SQL语句工具吗？通过这个工具，把我们的应用软件输进去，就能扫出SQL语句的大部分问题。这样就可以减少我们测试和性能优化工作量，更能避免投产之后才暴露性能问题。” — 来自某移动客户的需求。 “老罗，XX移动公司希望我们Oracle公司提供自动扫描SQL工具，我们有吗？听说第三方公司有这样的产品，已经在客户那儿试用了。” — 来自Oracle服务销售同事的担忧。 是啊，客户的需求再合理不过。但据我所知，Oracle公司好像没有这样包治百病的神奇工具。第三方公司居然有这样的工具，太吸引客户眼球了，一方面让人感到质疑，另一方面也令人感到一种竞争压力。   初识庐山真面目 于是，我和销售同事趁去该客户现场拜访、调研的机会，对该客户的上述需求和第三方公司的自动化工具一探究竟了。客户的需求不必多言了，我们关键是对所谓自动化工具充满好奇。因商务因素，客户并没有给我们直接展示该工具的使用过程和界面，但告诉我们大致原理：原来该工具首先通过定义一组评分规则，例如：SQL语句是否使用绑定变量；条件字段前是否有函数；多表连接是否超过4个表… …，然后将输入的SQL语句进行评判，若违反这些规则，扣分！最后给该SQL语句和整个应用模块打分。 原来如此！这些规则在大部分情况下不无道理，例如，条件字段加函数，特别是在日期字段前加to_char函数： to_char(DJ_SZ.JDRQ, ‘YYYY.MM.DD’) BETWEEN ‘2014.04.01’ AND ‘2014.04.17’ 就是一种非常初级、业余、错误的编程方式。正确方式应该是： DJ_SZ.JDRQ BETWEEN to_date(‘2014.04.01’,’YYYY.MM.DD’) AND to_date(‘2014.04.17’,’YYYY.MM.DD’) 但是，更多的规则值得商榷。例如，在Oracle公司推荐的编程规范中，并不是所有SQL语句都应该使用绑定变量的，而只是针对并发量大的小事务SQL语句才应该使用绑定变量，而针对并发量小的大事务SQL语句，特别是非常复杂SQL语句，Oracle公司建议是不要使用绑定变量。第三方的自动工具能分析出SQL语句是高并发量还是低并发量访问，以及大事务和小事务吗？值得怀疑。 更为典型的例子是，其实Oracle公司从来没有官方正式建议：一个SQL语句不能超过4个表的连接。的确，多表连接可能导致性能不佳，但问题不在于连接表的多和少，而在于编程人员是否理解了Oracle的Nested Loop、Hash Join等多种表连接技术原理和适应场景，以及在表连接中索引的设计原理。以下就是一个国内著名财务软件的典型SQL语句： select * from (select rownum num, temp.* from (select a.fid, … … a.playdeptname as playdeptNameCode from t_claim_remittancerecord a left…

作者为:  SHOUG成员 – ORACLE ACS高级顾问罗敏       多年前的一段往事 记得多年以前在一个10g平台的数据仓库项目上遇到一个非常难优化的SQL语句，当时即便我采集了统计信息、甚至在语句中增加了HINT，Oracle产生的执行计划都不如人意。最后，不得不通过SR寻求老外高手的指点，他建议我采用10g刚出炉的一个新技术，即让我为该语句生成SQL Profile信息，然后再执行该语句。一切OK了，太神了！ 也记得当时我问老外，以后是不是遇到非常复杂的、优化难度很大的SQL语句，就扔给Oracle，特别是产生一遍SQL Profile来辅助优化器时？鬼子不无得意地回答：“That’s right!”   再次感叹SQL Profile的牛！ 若干年之后的2014年，在面对一条将近200行的SQL语句进行优化时，发现该语句执行计划已经基本找不出明显问题，例如既没有全表扫描，也没有全索引扫描，甚至语句的Cost也非常低（当然Cost并不十分准确）。但是语句执行效率并不高，达到30秒，资源消耗也非常高，例如Buffer Gets达到1,246,155次。客户当然不满意，如何进一步优化？ 山穷水尽之际，想起了上述多年前的往事，更想起了神奇的SQL Profile技术。于是，在搜索到最新的11g文档《Automatic SQL Tuning and SQL Profiles (Doc ID 271196.1)》之后，照猫画虎般地开练了。效果如何？以下就是优化前后的对比： 这是优化之前的各项指标： Stat Name Statement Total Per Execution % Snap Total Elapsed Time (ms) 30,273 30,272.96 17.76 CPU Time (ms) 29,968 29,968.19 17.79 Executions 1 Buffer Gets…

作者为:  SHOUG成员 – ORACLE ACS高级顾问罗敏     “分表 + 分区” 多年来，某移动行业开发商在针对海量数据库进行设计时，一直在采用“分表 + 分区”策略。在正在进行的新一代移动业务支撑系统设计开发中，也仍然沿用这种策略。以下就是相关细节及本人的评估： 按用户id头两位建表分区 cs_scoreuse_rd积分消费记录表 cs_userdetail_info用户详细信息表 cs_userdetaildead_info用户详细信息拨备表 CS_UserAdd_info_$X 用户附加信息表 CS_UserAdddead_info用户附加信息拨备表 CS_UserState_info_$X用户状态变更轨迹表 详细含义是：由于用户id字段的前两位代表地市，实际上这类表是按地市进行范围分区。这样分区的目的是什么呢？通过与设计人员沟通，其实就是为了将这些大表划分成更小的物理表。但是，每个地市的数据量是不均匀的，因此每个分区的数据也是不均匀的，每个分区访问性能良莠不齐，并不能保证数据访问整体性能的最佳。 按用户id最后一位分十张分表 CS_UserAdd_info_$X用户附加信息表 CS_UserState_info_$X用户状态变更轨迹表 实际上这两张表分别代表10张表，例如CS_UserAdd_info_$X表是代表CS_UserAdd_info_0、CS_UserAdd_info_1… …CS_UserAdd_info_9。然后再按用户id头两位对这10张表进行上述范围分区。这就是典型的“分表 + 分区”策略。为什么要这么设计呢？设计人员的回答是如果不分表，由于CS_UserAdd_info记录非常多，直接按用户id头两位按地市分区，分区表记录仍然很多。大家看出问题了吗？下面我再详细分析，先留个伏笔。 所有历史表均为年月分表 在该系统设计中，上述表均有历史表，设计人员将这类历史表均按年月分表。例如：用户详细信息表（cs_userdetail_info）的历史表包括：cs_userdetail_info_201401、cs_userdetail_info_201402、cs_userdetail_info_201403、cs_userdetail_info_201404、… …。 大家首先可以想像一下，随着运行时间的增长，该系统将有多少表？   “分表”的弊端 在Oracle公司推出分区技术之前，针对大表的访问，我们只能采取分表的策略，这种策略弊端重重，而Oracle早在1996年的Oracle 8版就推出了分区技术，并且将近20年了，Oracle仍然在不懈努力地发展这一技术领域。可惜啊，该开发商仍然在沿用分表策略这一落后理念。分表到底有什么弊端呢？我们结合该系统具体情况，剖析如下： 首先，设计的表和索引太多，导致运行维护工作量浩大，数据库字典内容也太多，影响整个运行效率。举个简单例子，假设业务需要增加一个字段，我们将在所有分表上面都增加这个字段，多么愚昧呀！ 其次，导致应用开发逻辑不灵活、复杂化。不仅每个语句都要采取拼接方式，根据客户输入的年月等信息拼出需要访问的相关表，而且如果需要查询统计业务跨月份，都需要编写大量SQL语句，并进行UNION操作以及设计大量VIEW等。应用开发人员就不嫌麻烦？ 分表设计导致表名动态变化，使得Oracle 11g之后自动优化工具（Automatic Tuning）和SQL Profile功能难以实施，极大地影响了SQL语句优化效果。 在应用级人为进行多表设计，无法保证数据的完整性。例如我们发现在现有CRM系统中，DCUSTPAYOWEDET200703表就包含了非200703的数据。   深层次原因分析 本人早在2006年就曾为该移动客户提供过服务，当时针对这种“分表 + 分区”策略非常不理解。一直到2014年该开发商开发新一代核心系统了，我们终于有了与设计人员面对面的机会，才了解了更深层次的原因。 首先，我们感觉设计人员并不一味拒绝Oracle分区技术。否则，他们将全面抛弃Oracle分区技术，而全部采用分表策略。 其次，也是最根本的，通过交流我们发现，原来是设计人员不太了解Oracle分区技术。更具体的，原来他们只知道Oracle有范围分区，对HASH分区，尤其是Oracle组合分区等是一脸茫然。 现在解释前面的伏笔：设计人员为什么要将用户附加信息表（CS_UserAdd_info）既分表又分区？重复前面叙述：设计人员认为CS_UserAdd_info记录非常多，直接按用户id头两位按地市分区，分区表记录仍然很多，因此先按用户id最后一位先分成10张表，再分区。哎哟唉，你可以直接根据用户id字段进行HASH分区呀，例如4份、8份、16份、32份… …，这样不仅每个分区数据均匀，而且可以灵活地分成你想需要的份数，与地市无关！HASH分区的缺陷呢？不能按分区进行大批量数据管理。但这是用户附加信息表，我们不会存在大批量删除用户数据等管理操作的，因此这种担心是多余的。 至于历史表为什么要分表呢？同样地，设计人员不知道我们可以先按时间字段进行一维分区，再按用户id进行HASH分区。更准确地讲，设计人员可能根本不知道Oracle还有Range -List、Range…

如何确认Windows下cmd是否以管理员身份运行？     这是一个常见的初学者问题，在应当需要使用管理员身份的时候没有启用管理员身份来运行 脚本或代码，而初学者 很难搞清楚 所谓以“管理员”身份运行到底是指什么？Windows上的这种描述实在太容易让初学者混淆了。 可以通过如下的命令来确认 是否当前cmd有用管理员身份运行：         whoami /groups | find “S-1-16-12288” && Echo I am running elevated, so I must be an admin anyway 😉 如果有输出则代表具有 Mandatory Label\High Mandatory Level 最高权限，确实是以 管理员身份运行的。 如果没有输出则代表当前cmd没有最高权限。    

学完本课后，应能完成以下工作： 定义星形方案 展示没有转换的星形查询计划 定义星形转换要求 展示转换后的星形查询计划   星形方案模型 星形方案是最简单的数据仓库方案。之所以将其称作星形方案，是因为此方案的实体关系图类似于星形：多个点呈放射状围绕在中心表周围。星形的中心由一个或多个事实表组成，星形的点是维表。星形方案的特点如下：具有一个或多个非常大的事实表，这些表包含数据仓库中的主要信息，同时还具有许多较小的维表（或查找表），每个维表都包含有关事实表中某个特定属性的多项信息。星形查询是事实表和众多维表之间的联接。每个维表都使用主键联接到事实表的外键，但维表彼此之间没有联接。基于成本的优化程序 (CBO) 可识别星形查询，并为其生成高效的执行计划。事实表通常包含关键字和度量。例如，在销售历史方案中，sales 事实表包含 quantity_sold、amount 和 cost 度量以及 cust_id、time_id、prod_id、channel_id 和 promo_id 关键字。维表是 customers、times、products、channels 和 promotions。例如，products 维表包含事实表中的每个产品编号的信息。 注：可以很容易地将此模型扩展成包括多个事实表。   雪花方案模型   雪花方案是一种比星形方案更复杂的数据仓库模型，是星形方案的一种类型。之所以将其称作雪花方案，是因为此方案的关系图类似于雪花。雪花方案对维进行了规范化，以消除冗余。也就是将维数据划分到多个表中，而不是放在一个大表中。例如，在雪花方案中，星形方案中的产品维表在规范化后，可能变成一个 products 表、一个 product_category 表，以及一个 product_manufacturer 表，或如幻灯片所示，可以使用 countries 表来规范化 customers 表。虽然这样可节省空间，但增加了维表的数量，因此需要更多的外键联接。导致的结果是查询的复杂度增加，并且查询性能有所降低。 注：建议您优先选择星形方案，除非有明确的理由，否则不要选择雪花方案。   星形查询：示例   星形查询：示例 请考虑幻灯片中的星形查询。为了运行星形转换，假定销售历史方案的 sales 表在 time_id、channel_id 和 cust_id 列上有位图索引。 SELECT ch.channel_class, c.cust_city, t.calendar_quarter_desc, SUM(s.amount_sold)…

该Enqueue enq:WL WL Enqueue 队列等待的资源是用来锁定指定的online redo log在线日志文件，其在下列操作时被使用： 当增加一个新的成员到一个日志组 当从日志组中移出一个日志文件 当在清理日志文件内容时 当重命名一个日志文件 当在归档一个日志文件 其ID1 和 ID2的可能的含义： Log number (id1) ，零(id2) Redo thread (id1)，log sequence number (id2) Redo thread (id1)，log sequence number (id2) but id1’s high order bit is set (The “1<<16” th bit) when we are performing a logical standby related operation

准备工作：   安装前需要考虑需要使用的image版本，image可以在e-delivery（https://edelivery.oracle.com/）上下载到，是分开cell和db两套Image的。 准备两个3GB大小的U盘，以及一个Linux操作系统，解压下载到的两个image到Linux中，运行其中的USB引导image脚本（是一个bash脚本），脚本提示的很清楚，按照提示进行即可。以此获得两套引导USB介质。   根据image版本去ARU上下载对应版本的onecommand（http://aru.us.oracle.com）。   下载到onecommand以后，解压，根据里面的readme文件，去support.oracle.com上下载对应版本的DB、GI、两者的BundlePatch、对应版本的Opatch安装介质（Opatch的安装介质版本不会写在onecommand中，可能需要运行onecommand时，根据报错再去下载，要做好准备！）。在安装完image以后需要放置到/opt/oracle.SupportTools文件夹下的onecommand目录中去（不要修改文件名！   如果是升级安装（例如本次升级到11.2.0.3的db版本），建议使用对应的onecommand版本和相应的DB、GI版本，不建议先安装到底版本的DB、GI然后再进行升级操作到需要的高版本。（本次升级PSC使用11.2.0.2的db版本和conmmand进行deploy，安装后才将db升级到11.2.0.3，这种方式不建议）   onecommand中有dbconfigurator.xls文件，根据System同事的主机网络布线和配置情况(前期可能需要和system同事一起确定网络部署),填写该网络配置文件。填写好后，依次点击其中的两个按钮生成onecommand运行时需要的配置文件，并上传至装好相应Exadata的onecommand目录下。   如果是升级安装需要收集并保留原先的网络配置以备后续安装时使用。需要的信息：/opt/oracle.SupportTools/onecommand中原安装通过dbconfigurator.xls生成的配置文件（通常文件名为dbMachine_xxxx ，xxxx为主机名前缀）；ifconfig 信息；/etc/hosts文件     安装DB：   插入DB USB Image，重启DB机器，在引导画面中进入引导选项菜单（或进入BIOS界面设置亦可），选择使用USB引导系统.   引导进去后，提示相对清晰，根据提示进行即可.   如果image版本较高，可能需要刷服务器固件，会占用大量时间！可以选择image版本。建议先了解当前机器的Image版本，选择与之相同或高一两个小版本的image。如果是升级安装则可能必须使用高版本,image操作首先开始刷固件微码(如果image比当前机器版本稍高则可能没有该步骤).   系统自动重起进行系统安装，安装成功后机器会自动关闭电源，此时拔去USB，加电后注意在BIOS中选择从硬盘引导,然后启动。   再次加电后，自动进入DB服务器节点IP等信息的配置阶段，根据和system同事确定的网络布线情况和ip规划填入相应的IP和网卡信息。（特别要注意IB网卡需要绑定、应用访问IP的以太网卡需要绑定，默认网卡请选择管理网端的网卡，具体使用那些网卡进行绑定需要视具体的网络连线而定）.如果是升级安装则根据原先机器的网络配置进相应的配置操作。   配置成功后，再次自动重启。   成功进入系统后，上传解压后的onecommand工具至/opt/oracle.SupportTools目录下。   上传DB等安装介质和补丁至此目录。   等全部节点（DB、cell）的image安装完毕后，在onecommand目录下运行./checkip.sh进行网络配置检查，如果有问题根据显示的信息进行修正。检查没有问题之后运行onecommand目录下：deploy112.sh –s <step>（可以用-l 列出每个步骤代表的含义等，详见其帮助）.注意DB版本11.2.0.3对应onecommand：deploy11203.sh   运行成功后，Exadata安装完毕。     安装Cell：   安装步骤大致同DB的1~5。       DB和Cell的安装可以并行进行，没有特定的顺序要求（先DB、先Cell都可以）。建议多刻几个USB启动盘，同时进行re-imaging这样可以节省很多时间。  

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复! 诗檀软件专业数据库修复团队 服务热线 ： 13764045638 QQ号:47079569 邮箱：[email protected] exp TC/TC direct=true imp TC/TC show=y full=y ^ Import fails as the export file is corrupt: IMP-9: abnormal end of export file 00009, 00000, “abnormal end of export file” // *Cause: The export file is probably from an aborted Export session. // *Action: If so, retry the export…

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复! 诗檀软件专业数据库修复团队  服务热线 ： 13764045638   QQ号:47079569    邮箱：[email protected]     某用户数据库一表空间tablespace在OFFLINE之后出现无法ONLINE的问题，一旦操作alter tablespace ABC  online即报错：   alter tablespace abc online; error at line 1: ORA-00600: internal error code, arguments : [6856],[0],[163] 根据600的argument 1 可知该报错应当与发现该表空间上的数据与undo数据之间存在不一致所致。 Ora-600 Base Functionality Description 6000 ram/data ram/analyze ram/index data, analyze command and index related activity   这里的undo数据指的是 Deferred Undo Segment； 些DEFERRED ROLLBACK也叫做SAVE Undo segments，具有以下的特性：…