ITPub博客

我希望bb能健康的成长,愉快的成长,无忧的成长!虽然现在BB还不会说话,但总是想跟你说点什么似的,还经常笑,不知道我小的时候是不是这样的![@more@]

create or replace function csound(c in varchar2, op in integer default 1 )return varchar2/*作者：chensq@itpub.net日期：2005-05-18 22:30说明：此函数用于将汉字转换为其发音的首字母，对于ascii码值在1～128间的字符不作任何处理，其它字符返回错误信息。用法：默认情况下，只对第一个字符进行转换，如果加上不等于1的参数，则对全字符串进行处理，支持中英文合编。如：SQL> select csound('中国人用自己的sound()函数',2) from dual ;CSOUND('中国人用自己

ORA-00600: internal error code, arguments: [keltnfy-ldmInit], [46], [1], [], []我在虚拟机上面装了一个solaris system，然后装了一个oracle 10 R2数据库，前几天使用都很正常。 今天启动数据库的时候得到一个错误ORA-00600: internal error code, arguments: [keltnfy-ldmInit], [46], [1], [], []。 感到很迷惑，上网搜寻了一下，看到有人说：Check your /etc/hosts file.Oracle must be able to resolve your hostname.keltnfy-ldmInit is Oracles way to say it can't突然想到今天起来系统的时候使用hostname命令把机器名给改了，

数据库中表，出现了坏块。对于这个问题，在网上早就有了各种各样的讨论和解决办法，现在总结如下，以希望在关键时刻能用得上： 一、 数据表出现坏块，设置10231事件来进行EXP，然后在IMP的方法 对于这种情况来说，如果没有热备份，或者时间匆忙，来不及从备份中恢复，那么我们只能丢失一部分数据，先尽可能的修复在说了。 一般情况下，出现数据坏块，并不影响数据库的启动（非system 数据库文件损坏），但是一旦我们使用到了相关数据，就会报出类似如下信息的错误：ORA-01578: ORACLE 数据块损坏（文件号4，块号35

metalink上解决此问题的几个方法： 1 重置init.ora参数文件，调小以下四个参数的值： short_area_size hash_area_size bitmap_merge_area_size create_bitmap_area_seze open_cursor2 调小SGA的大小3 减小oracle Job队列数量(job_queue_processes)和并发队列数(parallel_max_servers)4 重置并减小会话/线程使用的堆栈大小5 将oracle改为mts模式6 更换操作系统为windows NT 企业版7 使用intel的ESMA硬件支持，即使用大内存..1) 在intel系统上使用 /3G 开关..2) 使用PSE36内存....修改堆栈大小的办法：....停止oracle服务和

修改参数 (仅适用于8i及8i以下版本) SQL>alter tablespace temp increase 1; SQL>alter tablespace temp increase 0; 合并碎片（对于ASM也不管用了） SQL>alter tablespace temp coalesce; 诊断事件（据说也没有太大的用处） SQL>alter session set events 'immediate trace name DROP_SEGMENTS level 4' 说明：temp表空间的TS#为3,So TS#+1=4 重建temp SQL>alter database temp tempfile '......' drop; SQL>alter tablespace temp add tempfile '......'; SQL> ORADEBUG WAKEUP 6 SMON cleans up only 8 e

1、数据库crush，同时报ora600错误，第一个参数kteuPropTime-2，metalink上显示出现回滚段corrupt现象2、在init.ora中添加 _smu_debug_mode=1 （用来收集诊断信息 event="10015 trace name context forever, level 10" 10015事件就是 让oracle在启动时避免启动corrupt的回滚段3. 在跟踪文件中确定是那个回滚段corrupt4. 加入参数_corrupted_rollback_segments=(_SYSSMU1$)5. restart 数据库，ok、ref: http://carson.yculblog.com/post.1140421.html[@more@]

背景： 用户修改一些配置，shutdown immediate，但是系统很久也没有关闭。等不及的用户 shutdown abort 数据库，然后startup。重新启动之后的数据库，在alert.log中不段出现类似的错误信息： SMON: about to recover undo segment 8 SMON: mark undo segment 8 as needs recovery 或者出现： smon: undo segment 46 is avaliable smon: need to recover undo segment 46 这些错误信息，由SMON 进程唤醒，所以一般是5分钟出现一次。 检查 dba_rollback_segs 发现这些回滚段的状

这两个等待事件，一般都是成对出现。在以前我对这两个事件的理解始终存在着误解，现在重新整理归纳如下： 这两个事件描述的是 blocks在内存中存储的情况，而不是从disk中读取的情况。也就是说，如果读取的blocks在内容中是连续存放的，那么就触发的是db file sequential read事件；如果在内容中存放的是离散的，那么就是db file scattered read 这两个事件是由unix中两个函数来对应：read() 和readv()； 其中，read()读取的是contiguous blocks 并且存放的也是contiguous area，这对应的就是db file sequential file； readv()读取的是con

library cache lock等待事件的概述：library cache lock 是在争抢library cache中的资源而造成的资源等待，它有3个参数：p1 对象的地址；p2 锁的地址； p3 namespace等，确定是表、包、索引等。 对这个lock的等待，pmon是1秒，其它进程都是3秒 出现这个等待时，经常表现的症状是：我们无法进行一些查询，甚至不能desc table_name来查看某个內容。由于等待信息不出现在v$lock中，所以，我们根据v$lock不能够确定其中的原因 解决library cache lock的方法：analyze system state dump： 我们可以通过systemstate事件，来查看所有oracle 进

log file switch(archiving needed) 日志切换的时候由于日志组循环使用了一圈但日志归档还没有完成，通常是io有严重问题， 可增大日志文件和增加日志组，调整log_archive_max_processes，如果发生(checkpoint incomplete) 错误信息，则说明当日志切换的时候由于日志组循环使用了一圈但将被使用的日志组中的checkpoint还没有完成造成， 通常是io有严重问题，可增大日志文件和增加日志组 log file sync(这个到可能是log_buffer太大的反作用) 当用户commit的时候通知lgwr写日志但lwgr正忙，造成的可能原因是commit太频繁或者lgwr一次写日志时

buffer busy wait 与 free buffer wait 的区别在于：前者指的是多个session对于同一个block的读取竞争；后者指的是，在buffer cache中，LRU列表中已经没有了空闲buffer space来接纳新的block信息。一般而言，发生buffer busy wait是由于： 1. The block is being read into the buffer by another session, so the waiting session must wait for the block read to complete. 等待另外一个session读取动作的完成 2. Another session has the buffer block locked in a mode that is incompatible with the waiting s

在data buffer中，所有的块都在一个hash table 的 link list 中。每一个 hash chain 都由一个single child latch 保护着。一个latch必须要得到该latch 才能够扫描该 hash chain 以保证该hash chain 上的blocks 不被修改 引发 cache buffer chain latch 的竞争的原因大概由如下原因：1. buffer chain 太长了： 太长的意义是指：lots of blocks all hashing to the same list (eg: having hundreds of consistent read versions of the same block and having hundreds of blocks on a list can add up) 增加 DB_BLOCK_LRU_LATCHES 参数2.

http://carson.yculblog.com/archive.109027.html[@more@]

在一个高可用系统中，如果需要改变一个表的定义是一件比较棘手的问题，尤其是对于7×24系统。Oracle提供的基本语法基本可以满足一般性修改，但是对于把普通堆表改为分区表，把索引组织表修改为堆表等操作就无法完成了。而且，对于被大量DML语句访问的表，幸运的是，Oracle从9i版本开始提供了在线重定义表功能，通过调用DBMS_REDEFINITION包，可以在修改表结构的同时允许DML操作。 在线重定义表具有以下功能： 修改表的存储参数； 可以将表转移到其他表空间； 增加并行查询选项； 增加或删除分区； 重建表以减少碎片； 将堆表改为索引组织表

不过我上次提到的在10g的db link泄露密码的事情，大家可以参考。在Oracle 10g前，我们可以通过查看user_db_links视图，来查看到本用户下建立的db link的username和password.原因比较简单，可以认为是Oracle的一个安全漏洞。我们看看user_db_links的创建过程就明白了：create or replace view user_db_links(db_link, username, password, host, created)asselect l.name, l.userid, l.password, l.host, l.ctimefrom sys.link$ lwhere l.owner# = userenv('SCHEMAID')select * from link$user_db_links视图来源于sys.link$字典表，而在10g

Thomas Zhang的3节点RAC题目 SERVICE12(DESCRIPTION =(ADDRESS = (PROTOCOL = TCP)(HOST = vip1)(PORT = 1521))(ADDRESS = (PROTOCOL = TCP)(HOST = vip2)(PORT = 1521))(LOAD_BALANCE = yes)(CONNECT_DATA =(SERVER = DEDICATED)(SERVICE_NAME = dbname)(FAILOVER_MODE =(TYPE = SELECT)(METHOD = BASIC))))SERVICE3(DESCRIPTION =(ADDRESS = (PROTOCOL = TCP)(HOST = vip3)(PORT = 1521))(CONNECT_DATA =(SERVER = DEDICATED)(SERVICE_NAME = dbname)))SERVICEA =(DESCRIPTION =(ADDRESS = (PROTOCOL = TCP)(HOST = vip1)(PORT = 1521))

http://linux-ha.org/download/index.html[@more@]

Oracle并没有提供什么参数来指定要导入哪个表空间，数据默认将导入到原本导出时数据所在的表空间中，但是我们可以通过以下的方法来实现导入到不同的表空间。 1．在IMP时候使用INDEXFILE参数当给此参数指定了某一文件名，IMP的时候所有的index将不会直接导入到表空间中，而是在指定的文件中生成创建index的脚本。imp scott/tiger file=scott0419.dmp indexfile=scott.sql fromuser=scott touser=tiger然后用文本编辑器打开此文件，直接编辑脚本中的storage参数，修改为想要导入的表空间名称。然后重新执行IMP，使用INDEXS=n参数将除Index之

http://www.linuxgo.org/linux/database/mysql/070228/684.htmlhttp://wangbinblog.bokee.com/2185576.htmlhttp://www.me94me.com/blog/post/47.html (升级授权表的问题)http://xn--yetq15clg1a.com/bnsj/24252.html[@more@]