ITPub博客

公司要分离业务，需要对数据进行一个快照的备份，准备走物理备份，可以由于数据文件创建太多 太乱琐碎就不利用cp，就考虑走逻辑备份，800g的数据准备用expdp开启并行倒是很轻松的可以在简短的时间完成的，不过由于晚上应用又再次重启导致备份了12个小时才备份了1/3而已。简要记载一下这次expdp的过程，有些东西看起来简单单实际过程中并不是这么顺利。Nfs挂载的磁盘root用户开始无法写入，然后做了一系列的改动后发现还是存在问题，root用户虽然能写入了，但是oracle用户无法写入，没办法准备添加root用户到dba组完成expdp，不过发现了虽然

从oracle推出symbol table）的指针，相同的数据其实真正存储在符号表内。表段压缩技术可以有效减少compress表段的访问也需要消耗SQL> create table t_comp01 as select rownum id ,a.* from dba_objects a;Table createdSQL> insert into t_comp01 select * from t_comp01; t_comp01，下面分别采取nocompress的创建表 SQL> analyze table t_comp01 compute statistics;Table analyzed blocks ---------- ---------- ------------ ------------------------------ 313908 1701 91 T_COMP02compress创建

在alter日志中发现如下错误：ORA-01578: ORACLE data block corrupted (file # 41, block # 1830)ORA-01110: data file 41: '/db/oracle10g/oradata/hnst/hnst38.dbf'同样用dbv也检索到file 41的一个坏块，不过由于之前已经检索过，坏块的具体信息没有全部标示出来，而这个dba 171968294具体的组成成分是哪些也是个人比较疑惑的地方，按理是文件号和块号，不过这里详细的划分方法自己还是很迷惑的。期待大牛解答。[oracle@hns_hy_hn_xwb_tomora ~]$ dbv file='/db/oracle10g/oradata/hnst/hnst38.dbf' blocksize=8192 logfile='/home/orac

早上连接生产库发现出现错误，数据库意外关闭了。Alert和sqlplus中提示如下错误：Errors in file /db/oracle10g/admin/benguo/bdump/benguo_dbw0_2029.trc:ORA-01242: data file suffered media failure: database in NOARCHIVELOG modeORA-01114: IO error writing block to file 2 (block # 36874)ORA-01110: data file 2: '/db/oracle10g/oradata/benguo/undotbs01.dbf'ORA-27072: File I/O errorLinux-x86_64 Error: 5: Input/output error其实根据最后的Linux-x86_64 Error: 5: Input/output error是os上的IO出现错误，根据前面的ora

转一篇很实用的linux的简单操作文档http://mushme.iteye.com/blog/1001478日 志 文 件 说 明 /var/log/message 系统启动后的信息和错误日志，是Red Hat Linux中最常用的日志之一 /var/log/secure 与安全相关的日志信息 /var/log/maillog 与邮件相关的日志信息 /var/log/cron 与定时任务相关的日志信息 /var/log/spooler 与UUCP和news设备相关的日志信息 /var/log/boot.log 守护进程启动和停止相关的日志消息 系统： # uname -a # 查看内核/操作系统/CPU信息 # cat /etc/issue # cat /etc/redhat-release # 查看操作系统版本 # cat /p

今天发现系统上线的有个sql语句用到了sample，也就是对表段的数据进行抽量采样。SQL> create table t_samp01 as select * from dba_objects;表已创建。SQL> set autotrace traceonlySQL> select * from t_samp01;已选择72073行。执行计划----------------------------------------------------------Plan hash value: 997462556------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time-------------------------------------------

Lob字段包含三个部分：Lob列、lob数据段、lob索引段。Lob列由lob定位符也就是指向lob字段实际存放位置的指针和lob值组成。Lob数据段可以分为多个chunk，每个chunk用来存放lob数据。Lob索引段存放lob索引，由多个entry组成，每个entry结构大致为lob index locator、chunk id和chunk location，一个entry指向一个lob块。也就是记录在lob索引段里面的entry等于lob数据段内的chunk数目。结构大体如下：Lob列 LOB定位符 lob值Lob数据段 chunk1 chunk2 chunk3 chunk4…Log 索引段 entry entry entry entry…SQL> c

全文检索：Oracle支持全文检索功能，对关键字进行所谓的模糊检索。初次接触全文索引，简单摘要下。解锁ctxsys用户和授权给userSQL> alter user ctxsys account unlock; User altered SQL> grant execute on ctx_ddl to jhajjql;授权完成后就可以利用ctx_ddl包来创建lexer，全文检索是通过oracle专利的词法分析器lexer将column中的所有表意单元（oracle称为term）找出来，记录在一组以dr$开头的表中，同时记录term出现的位置，此时，hash值等，检索时就是利用dr$表找出相应的term然后查找相应的数据信息。Lexer的分类Basic_lexer：主

早上打开服务器发现119的数据库又意外关闭了，启动数据库，但是居然无法连接到oracle，报的一个audit fle failed，写入审计文件报错。磁盘没有空间了，不过审计默认是没有开启的。那么应该不会写入audit日志到数据文件中啊。但是sys连接数据库，启动关闭数据库是会被记录到日志文件中的，缺省的在$ORACLE_BASE/admin/benguo/adump下。SQL> show parameter audit_trail;NAME TYPE VALUE------------------------------------ ----------- ------------------------------audit_trail

前几天算是第一次接触mysql数据库的调优，系统负载很高，应用连接进来后会时不时自动断开，top中发现mysql进程占用了大量的cpu，由于接触mysql数据库并不久，怀疑是大表fts导致，show processlist后发现了大量的session在对大表进行fts，建立索引后问题得到解决，下面转载一下mysql的show processlist命令介绍。由于刚接触mysql，感觉还是颇有意思，不过和oracle确实是两种不同的产品，看来也需要静心下来学习。processlist 命令的输出结果显示了有哪些线程在运行，可以帮助识别出有问题的查询语句，两种方式使用这个命令。 1. 进入

Mysqldump工具用于将mysql server中的数据以query形式导出成文本文件，虽然和oracle的export import工具一样可以作为一种逻辑备份的工具，不过mysqldump更应该作为一种query生成工具更合适，mysqldump工具生成的文件包含全部的所需要的sql命令。并且转化为ddl语法和insert语句。[root@Analyser ~]# mysqldump -p cobra userinfo>test03.txtEnter password:还可以和exp和expdp中的query一样截取部分数据[root@Analyser ~]#mysqldump –p –where=”id=689” cobra userinfo>test04.txtEnter password:这里截取部分导出的文件看看DROP

不知不觉，自己和周围的童鞋 朋友已经临近或者已经临近二十三四，其实以前看过一篇文章那一年 我们二十三、四。这个年龄阶段自身其实还残留着高中 大学的稚嫩，但是也渐渐的有着对家人和自己的责任感，比较喜欢一句话：在合适的年龄做合适的事情。想想以前高中要学习，要考到好大学，可以说不得不学期，步入大学终于释放了高中压抑已久的日子，那么好好的享受大学时光，游戏 谈恋爱 翘课 挂科相信大家都享受过这个过程和快乐，其实还是很是还念大学的那段无忧无虑的日子。踏入社会已经快两年了，自己也渐渐成熟太多，相信周围的同龄人也一

今天系统反应较慢，出现了大量的read by other session事件，查看该sql语句并没有优化方案。可以采取的就是改写sql语句了（其中后续采取的也就是修改sql语句的功能）。不过个人比较关心的是这个read by other session为什么会大量出现在file 2上。db file sequential read46.31"25","118758","1"0.01file#block#blocksread by other session42.56"2","22197","52"0.02file#block#class#相比以前做awr报告，其实如果系统某段时间反应较慢，做ash报告也是一个很不错的选择，as

公司服务器意外断电，数据库崩溃，由于没有做备份和归档，尝试利用在线的redo试着recover下，发现运气差了点，需要采取特殊手段了，其中有很多的ora-00600错误，终于利用一系列办法搞定了，由于用了特出手段数据库已经不一致，需要expdp重建数据库导入，不过一会儿问题出现了，虽然是个小问题但是这里写下给朋友们一点提醒，出现600错误不可怕，根据trace和储备知识一步一步来，这个过程你的经验会有一部分提高，再是试着自己去根据oracle给你的提示来解决问题下面的就是数据库恢复后出现的一个小插曲，sys用户连接后会自动的断开，新增的

数据库中日志基本不切换，db基本没有负载，查看警告日志中发现在出现了ora-00600后，redo的切换就不正常了，这里也提醒下数据库没有问题不代表真的没问题，对于系统有些异常情况需要及时去查看后台日志来诊断具体的信息。系统主机也没有什么负载。Thu May 3 12:29:28 2012ORA-00060: Deadlock detected. More info in file /db/oracle10g/admin/benguo/udump/benguo_ora_21458.trc.Thu May 3 12:41:22 2012ORA-00060: Deadlock detected. More info in file /db/oracle10g/admin/benguo/udump/benguo_ora_21430.trc.Thu May 3 12:56:11

如果运行的代码中包含某种可能的错误，且在调用中触发了的话，服务器端本地的服务进程有义务对远程客户端告知该信息，这个告知的过程中服务进程就处于SQL*Net break/reset to client等待中，直到客户端收到问题信息为止。大的查询，表的不合理连接也会照成。SQL> select * from v$mystat where rownum=1; SID STATISTIC# VALUE---------- ---------- ---------- 135 0 1SQL> insert into test05 values(1);1 row insertedSQL> commit;Commit completeSQL> alter session set events '1004

Oracle 10g下cbo的自动统计分析功能很大程序的解决了因为9i下统计信息失效或者陈旧导致的sql语句选择了不合适的执行计划，该统计分析功能是通过dba_scheduler_jobs视图下的gather_stats_job来对系统的对象进行统计分析，gather_stats_job在星期一到星期五在晚上10点执行，双休从早上6点到星期一早上6点，该统计分析由于需要对数据库的所有对象进行分析，所以可能该job并没有完成，查看dba_scheduler_job_run_details可以对job执行是否完毕，可以看出在大型的生产库中很多情况该job都没有执行完毕就中止了。SQL> select log_date,job_na

Data file init write等待事件主要是用于数据文件内部扩展，增加数据文件出现的等待事件，该等待事件的三个参数分别是count，intr，timeout，oracle 10g推出的SQL> alter session set events '10046 trace name context forever,level 8'; Session altered SQL> alter database datafile 5 resize 100M; Database alteredSQL> alter session set events '10046 trace name context off'; Session altered---------WAIT #2: nam='Data file init write' ela= 15163 count=1 intr=256 timeout=-1 obj#=1 tim=28805256609WAIT #2: n

Flashback和smon_scn_timeFlashback机制是oracle 9I 后推出的，依据是回滚段中的信息来构造数据块的前镜像，oracle 9I推出了aum也就是自动回滚段管理，设置了相应的undo_retention参数用来保证回滚段的保留时间，不过该参数并不是一个担保值，也就是如果事务提交过于频繁，新的回滚段信息可能会覆盖undo_retention范围内的回滚段信息，而我们可以设置alter tablespace undotbs1 guarantee来强制保证回滚段的信息在undo_retention范围内。 闪回查询可以在undo信息存在的情况下查询表、视图和物化视图，制定scn和

关于block的ITL和dump的扩展关于block的ITL，数据块在创建时默认会在每个block中分配两个ITL，也就是initrans，会有list，最大允许有255 Interested Transaction List，也就是block上的maxtrans。而initrans为2是初始分配给block的，虽然经过dbms_metadata.get_dll查看初始分配了initrans 1，其实大家可以在创建后dump块看看，初始分配了两个，而即使手动定义的maxtrans 2在10g下已经失去了意义，oracle一样会初始分配2个ITL，最大允许255个ITL。注：oracle 9i推出了自动段空间管理，使block中的fctused参数