Author: mac

当前控制文件的内容可以通过CONTROLF dump以文本形式转储到实例参数指定的目录下。 各级别CONTROLF转储的区别: 转储级别 转储内容 1 仅包含文件头信息 2 包括文件头，数据库信息记录，检查点进程记录 3 所有记录类型，针对循环重用的记录类型仅保留最早及最近的记录 4 如上，包含4条最新的可重用类型的记录 5+ 如上，包含的可重用类型记录为2*level条 SQL> oradebug setmypid; Statement processed. SQL> oradebug dump controlf 3; Statement processed. SQL> oradebug tracefile_name; /s01/rac10g/admin/PROD/udump/prod_ora_3710.trc 以下例而言，使用oradebug命令启动转储，将会把当前控制文件信息以文本形式转储到该服务进程对应的用户转储文件中，文本中记录了level 3所对应的内容。 SQL> oradebug setmypid; Statement processed. SQL> oradebug dump controlf 3; Statement processed. SQL> oradebug tracefile_name; /s01/rac10g/admin/PROD/udump/prod_ora_3710.trc oradebug必须以SYSDBA形式登陆后方能使用，你也可以以非SYSDBA的身份通过alter session形式启动转储: SQL> alter session set…

可能很多朋友都遇到过这样的情况，在UNIX/Linux上定期清理Oracle日志文件夹时可能删除到仍被后台进程open着的trace文件，即某些后台进程一直持有着这些”被已经误删了的“打开文件的描述符(fd)，这种情况下文件系统上该文件实际占用的空间是不会被释放的，这就造成使用df命令查看文件系统剩余空间和用du命令查看文件夹空间使用量时数值不一致的问题。此外因为是后台进程持有这些打开文件描述符，所以我们无法像kill服务进程一样来解决该问题(部分后台进程是可以kill的，不建议这样做)。oradebug是sqlplus中威力强大的debug命令,我们可以通过该命令发起多种trace/dump，其中也包括了close_trace事件；close_trace事件可以让指定进程关闭其正持有的trace文件。 下面我们就来演示下相关操作: [maclean@rh2 ~]$ ps -ef|grep ora_|grep -v grep maclean   7281     1  0 16:35 ?        00:00:00 ora_pmon_PROD maclean   7283     1  0 16:35 ?        00:00:00 ora_psp0_PROD maclean   7285     1  0 16:35 ?        00:00:00 ora_mman_PROD maclean   7287     1  0 16:35 ?        00:00:00 ora_dbw0_PROD maclean   7289     1  0 16:35 ?        00:00:00 ora_lgwr_PROD maclean   7291     1  0 16:35 ?       …

直到今天仍是经典，无可替代，绝不落伍。想了解Oracle internal 必读的一本书，每次翻开影印本都会有所收获，感谢作者的无私贡献！ [gview file=”http://askmaclean.com/wp-content/uploads/resource/oracle8i.internal.services.for.waits.latches.locks.pdf”]

类似于《Oracle dba日记》，由国外一群Oracle专家合著，够fashion! Expert_Oracle_Practices

fackbook的技术专家之一Carlos Bueno在这周一发表了这篇关于有趣的网络制图(Internet Cartography)的文章，如果你恰好”无法正常浏览“facebook的页面，那么也可以读读我所引用的： Every generation likes to think it reinvents the world from scratch. But some things are shaped by history and geography as much as anything. Mountains, rivers, archipelagos, and long terrestrial crossings play a big role in deciding where, how, and how well different parts of the Earth get connected. This is a…

共享池是Oracle著名的SGA的一个重要组成部分，当我们尝试从共享池中分配较大的连续区域时(默认来说是4400bytes)，我们可能会用到共享池中的保留区域(也叫保留池);注意Oracle总是会先尝试扫描普通共享池的空闲列表，之后才尝试扫描保留池的空闲列表，无论所需分配的内存块是否超过隐式参数_shared_pool_reserved_min_alloc所指定的值。 什么？你看到过的4031描述文档是用以下伪代码描述分配流程的： large, scan reserved list if (chunk found) check chunk size and perhaps truncate if (chunk is not found) scan regular free list if (chunk found) check chunk size and perhaps truncate all done if (chunk is not found) do LRU operations and repeat small, scan regular free list if (chunk found) check chunk…

想要在您的站点上实时体验海量活跃用户的负载？我们来介绍一种最新的方式，这种新的实时网络框架被命名为Tornado(中文为龙卷风)；Facebook从去年秋天开始研发该软件，最近以开源协议发布了该软件的1.0版本。 Tornado是基于Python开发的实时网页服务器，理论上可以支持上万的连续连接,使用长轮询方式进行实时数据传递。它是构成FriendFeed的核心技术，FriendFeed最初由2名前Google员工及多名网络社区领导人协作开发，在2009年FriendFeed被facebook所收购。Facebook公司现在的CTO:Bret Taylor进一步扩展了该软件。 Bret Taylor在过去几年中曾是Google Reader的主要开发者之一，之后他加入了real-time网络社区，并同Taylor一起启动了FriendFeed项目。之后FriendFeed被facebook收购，Darnell重返thing实验室，并领导将Tornado开发到现在的V1.0版本。 可以从这里进入Tornado的官网并下载下载到源代码tar包。

常用twitter的用户可能感觉到了，该网站在过去几个月中出过一些过载导致无法访问的故障。世界杯期间每天300000新建用户的增长是造成过载的一个重要因素。这也推动了twitter建设自己的数据仓库存储中心。他们正在建设的一个数据中心，位于盐湖城。 虽然毫无疑问该中心将不及苹果在北卡罗来纳州耗资10亿美元建设的数据中心庞大。 Twitter发言人称他们正加紧建设一个为自身定制的数据中心，并将在今年启动。 “拥有独立的数据中心，将给予网站更大的容量，以适应用户的增长”Twitter的jean-Paul Cozzatti在其技术博客中写到。 “在该数据中心，Twitter将有能力完全控制其网络及系统配置，将占用大块商用面积，并使用特殊设计的电源和冷却设备。该数据中心将采用多个供应商提供的服务器，并且运行开源操作系统和应用程序”。 直到最近，Twitter仍使用由日本电信电话株式会社NTT美国公司在海湾地区建设的数据中心。”我们仍将和NTT美国合作管理现有的中心，这尚是我们首次定制数据中心”,一位Twitter发言人这样告诉我们。 这是自facebook在1月份公开其独立数据中心以来大型社交网站的又一重大举措。facebook的数据中心位于俄勒冈州，那里聚集了众多其他公司的Datacenter,包括亚马逊和谷歌。巨型网络公司扎堆于是有原因的，这里可以提供廉价的电能和适宜的气候(够凉爽),以及公司税收优惠。 近期Twitter出现了因大量无法正常访问的用户投诉(最主要的恐怕是有时无法注册新用户)而引发的公关危机。Twitter公司的博客大致叙述了他们的问题，Cozzatti-Twitter公司的主要技术负责人之一的博客也详细地描述了该问题。最主要的问题在于每周一，Twitter的主用户数据库会因为一个查询而卡住，此时整个系统都被锁定了。他们不得不重启该数据库，这个过程历时超过12小时！现在你或许理解他们需要对系统拥有更多控制权的苦衷了:) ”我们时常对比在各种在收缩，维护，调整Twitter这一飞翔中的火箭的工作”Cozzatti写到。

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复! 诗檀软件专业数据库修复团队 服务热线 ： 13764045638   QQ号:47079569    邮箱：[email protected]     ORA-08103问题的诊断最好是能生成8103错误的ERROR STACK TRACE， 在TRACE中会记录具体引发8103的对象的OBJ和OBJD，这便于我们定位可能存在corruption的对象。 问题在于往往前台进程遇到ORA-08103错误不会在后台生成TRACE文件，这需要我们手动设置8103 触发ERRORSTACK的EVENTS:   ALTER SYSTEM SET  EVENTS  ‘ 8103 TRACE NAME ERRORSTACK LEVEL 3’; 解决思路包括： 1. 通过OBJD和DBA定位到具体的表名和块号 2. 有条件的情况下对该表做一个analyze .. validate structure 3. 有条件的情况下对该表所在tablespace做一个 dbms_space_admin.ASSM_TABLESPACE_VERIFY 4. 有条件的情况下move这张表或者相关的分区，尝试绕过该问题 5. 有条件的情况下降该表或分区移动到MSSM表空间上，绕过该问题 execute dbms_space_admin.tablespace_verify(‘&tablespace_name’) oradebug setmypid oradebug tracefile_name   execute dbms_space_admin.assm_tablespace_verify(‘&tablespace_name’,dbms_space_admin.TS_VERIFY_BITMAPS) oradebug setmypid oradebug…

检查告警日志发现出现ora-600:[17281],[1001]记录，该数据库版本为10.2.0.4: ORA-00600: internal error code, arguments: [17281], [1001], [0x70000042F5E54F8], [], [], [], [], [] ORA-01001: invalid cursor 分析该600错误产生的trace文件，发现当时运行的语句是一段匿名块: Current SQL statement for this session: declare t_owner varchar2(30); t_name  varchar2(30); procedure check_mview is dummy integer; begin if :object_type = ‘TABLE’ then select 1 into dummy from sys.all_objects where owner = :object_owner and object_name = :object_name and…