小议lob字段结构和存储
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:主
磁盘满了sys无法连接写入audit文件
早上打开服务器发现119的数据库又意外关闭了,启动数据库,但是居然无法连接到oracle,报的一个audit fle failed,写入审计文件报错。磁盘没有空间了,不过审计默认是没有开启的。那么应该不会写入audit日志到数据文件中啊。但是sys连接数据库,启动关闭数据库是会被记录到日志文件中的,缺省的在$ORACLE_BASE/admin/benguo/adump下。SQL> show parameter audit_trail;NAME TYPE VALUE------------------------------------ ----------- ------------------------------audit_trail
read by other session在undo所想
今天系统反应较慢,出现了大量的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
processes过小引起的tns-12547 tns lost contact
公司服务器意外断电,数据库崩溃,由于没有做备份和归档,尝试利用在线的redo试着recover下,发现运气差了点,需要采取特殊手段了,其中有很多的ora-00600错误,终于利用一系列办法搞定了,由于用了特出手段数据库已经不一致,需要expdp重建数据库导入,不过一会儿问题出现了,虽然是个小问题但是这里写下给朋友们一点提醒,出现600错误不可怕,根据trace和储备知识一步一步来,这个过程你的经验会有一部分提高,再是试着自己去根据oracle给你的提示来解决问题下面的就是数据库恢复后出现的一个小插曲,sys用户连接后会自动的断开,新增的
600 【12333】不影响db运行的bug吗
数据库中日志基本不切换,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*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的自动统计分析
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 int write和db file sequential read个人想法
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_time
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和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参数
用户被锁-中间件配置引起的
虽然不是很深刻的错误,但是还是需要我们去注意的,一个是用户登录不停的被锁住,刚开始用alter user username account unlock,然后解锁后用户登录又被锁住了,由于是oracle10g下,缺省的profile的failed_login_attempts为10,怀疑是中间件连接导致SQL> select profile,resource_name,limit from dba_profiles where profile='DEFAULT' and resource_name='FAILED_LOGIN_ATTEMPTS'; PROFILE RESOURCE_NAME LIMIT------------------------------ -------------------------------- --------
跟锁相关的几个视图
转载以下三思的blog http://junsansi.itpub.net/post/29894/477753v$lock视图的各个列及其说明:ADDR RAW(4) 在内存中锁定的对象的地址KADDR RAW(4) 在内存中锁的地址SID NUMBER 保持或申请锁的会话的标识号TYPE VARCHAR2(2) 锁的类型。TX=行锁或事务锁;TM=表锁或DML锁;UL=PL/SQL用户锁ID1 NUMBER 锁的第1标识号。如果锁的类型是TM,该值表示将要被锁定的对象的标识号;如果锁的类型是TX,该值表示撤销段号码的十进制值ID2 NUMBER 锁的第2标识号。如果锁的类型是TM,该值为0;如果锁的类型是TX,该值表示交换次数LMODE NUMBER 会话保持
又是信号量和共享内存没有释放的db待机
连接以前公司工作的一个生产库,出现了下列错误。SQL> conn / as sysdbaConnected to an idle instance.SQL> select * from dual;select * from dual*ERROR at line 1:ORA-01012: not logged onSQL> conn / as sysdbaConnected to an idle instance.以为是数据库内部hang住了,用hanganalyze工具查看下是否有直接在os可以kill的进程SQL> oradebug setmypidStatement processed.SQL> oradebug hanganalyze 3Hang Analysis in /usr/oracle/admin/jhql/udump/jhql_ora_24770.trcSQL>SQL> quitDisconnected警告日志并没有
control file parallel write等待事件
Control file parallel write事件,控制文件的写入等待,控制文件中记录了db的scn,数据文件的scn,当前redo log号,归档日志信息,备份集信息等等,很多信息都需要定期更新,很有可能会引起control file parallel write事件。1) 日志文件过小,或者dml操作过多,导致日志切换太快,每次日志切换都需要进行检查点,记录相应的日志切换的信息。2) 增量检查点发生,也会记录scn信息和检查点到控制文件中,10g的自动增量检查点会记录也会更新一次控制文件中记录的RBA信息。3) nologging下频繁更新数据文件,对数据文件在nologging选项下
oracle 10g的db_file_multiblock_read_count参数
Oracle 10G下的参数db_file_multiblock_read_count参数,是代表oracle的多块读取一次的IO的block数量,数据库创建初期oracle会默认设置相应额db_file_multiblock_read_count参数。SQL> select * from v$version;BANNER----------------------------------------------------------------Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64biPL/SQL Release 10.2.0.1.0 - ProductionCORE 10.2.0.1.0 ProductionTNS for Linux: Version 10.2.0.1.0 - ProductionNLSRTL Version 10.2.0.1.0 - ProductionSQL> sho
awr的top sql分析
连续看了两天的awr报表,发现此db中存在大量的等待事件。Log file sync、全表扫描,全索引扫描、latch等待,热点块(很可能是由于全表全索引扫描导致的热点快竞争)、检查点未完成,队列锁的竞争等的。 这个db的awr报表出现了很大的问题,其实在生产库中也没有几次看awr报表的经验,虽然对buffer hit、buffer nowait等系统评估有一定了解,但是要说去具体如何查处性能瓶颈乃至解决性能瓶颈自身还存在很多不足。 公司内网服务器192.168.0.119有32g的内存和16个cpu,硬件性能上面应该不存在太多问题,要说问题就是做的rai
vnc图形界面登陆和信号无法分配而db无法nomount
工作第一天,更多的是熟悉环境,一直以为远程控制linux服务器图形化界面多么不可触摸,其实用个远程连接软件就可以达到,realvnc客户端的图形客户端就可以实现了!不过配置上面需要我们设置下。Linux下开启nvcserver服务,切换到root用户执行[root@linux ~]# nvcserverNew 'linux.xiaoyu:2 (root)' desktop is linux.xiaoyu:1Starting applications specified in /root/.vnc/xstartupLog file is /root/.vnc/linux.xiaoyu:1.log这里开启一个vncserver连接的服务是linux.xiaoyu:1,如果再次打开nvcserver就会依次增长为linux.xiaoyu:2,
nocatalog模式下rman备份下controlfile记录备份信息的一点探究
源于pub中的一篇帖子http://www.itpub.net/thread-1584375-1-1.htmldelete obsolete; --能删除7天前的备份delete expired backup; --不能删除7天前的备份, 为什么?Rman有两种备份策略,一种是基于时间的,默认的是认为7天的备份有效,还有一种是基于冗余的,会认为最后一次的备份有效。Delete obsolete会删除过期的备份,而如果在物理上删除的备份,还是会存储在rman备份信息中并置为有效,nocatalog下controlfile保留备份集信息,删除的备份集信息依然记载在controlfile中,只是用flag来标记状态,这
sysauth$基表的用户权限的一点分析
源于itpub的一篇帖子http://www.itpub.net/thread-1581904-1-1.html说到sysauth$表被频繁访问。select privilege#,level from sysauth$ connect by grantee#=prior privilege# and privilege#>0 start with grantee#=:1 and privilege#>0如上的sql语句频繁执行,其实对于递归sql对于自己初始oracle才一年的菜鸟一般是略去不看的,eygle前辈们有时别太相信oracle内部的sql,他们很可能会成为系统性能的瓶颈,记得eygle的一个案例说到某个版本的oracle上开启oem很可能导致后台一个递归sql反复执行而影响系统运行,也建议自己和大家多去