ITPub博客

vi -- +ASM2_lck0_3276882.trctail -- +ASM2_lck0_3276882.trc[@more@]vi -- +ASM2_lck0_3276882.trctail -- +ASM2_lck0_3276882.trc

在AIX,LINUX系统中访问含特殊符号的文件, 只需在文件名前面输入 -- 即可.-- 能够被SHELL识别, 其后的参数作为文件而不是参数处理.tail -- +ASM2_lck0_3276882.trc vi -- +ASM2_lck0_3276882.trc [@more@]

Host key verification failed1. .ssh/known_hosts 裡面记录的目标主机 key 值不正确。这是最普遍的情况，只要删除对应的主机记录就能恢复正常。2. .ssh 目录或者 .ssh/known_hosts 对当前用户的chmod.html' target='_blank'>权限设置不正确。这种情况比较少，一般正确设置读写权限以后也能恢复正常。3. /dev/tty 对 other 用户没有放开读写权限。这种情况极为罕见。出现的现象是，只有 root 用户能够使用 ssh client，而所有其他的普通用户都会出现错误。我今天遇到的就是第三种情况，修改 /dev/tty 的权限后，一切正常。为了避免以后

如果只是授权执行：grant EXECUTE ANY PROCEDURE to hdisread ; 那么只能看到包的说明，看不到包体，所以必须加上下面的授权：grant CREATE ANY PROCEDURE to hdisread ; [@more@]

dbms_scheduler package body INVALID 。这个问题从去年开始出现，现在也不知道当初出现的原因了。这个问题导致视图dba_scheduler_jobs 查询失败。 以前重新执行过内置的脚本也没有修复好，今天实在忍不住了。就按最基本的思路去修复：1，首先找到包含 create package body dbms_scheduler 字符串的脚本，然后手工核对，找到并确认程序包体的重建代码，保存到单独的文件中，然后以SYS用户登录执行。现在问题已经解决了。其实解决过程很简单，真不知道以前是怎么想的，这么难的问题，用最基本的解决思路就可以解决了。相关操作命令片断如下

今天上午，公司的一台数据库HDIC的其中一个磁盘空间满了，导致归档失败，外部程序无法连入。经过详细检查，发现是由于设置了强制的恢复点（v$restore_point）造成的，于是删除掉不用的恢复点。但是现在还是出现了磁盘空间大量占用的情况，经检查，是DATABASE FLASHBACK LOG占用的，用了1.4TB，挺吓人的。查询v$flashback_database_logfile确定文件名后，进入ASMCMD手工删了一些。但是v$flashback_database_logfile中还有记录，挺不爽的，做事就要做得干净彻底嘛。经过思考和实践，发现了删除v$flashback_database_logfile记录的方法，其实

今天在用impdp导入数据时遇到下面的错误，前台impdp直接说fatal error,也不给出任何解释就退出了。只好从后台日志找原因。---以下内容选自alert_hlsales.logSMCO started with pid=36, OS id=22347800Wed Mar 21 13:24:43 2012Exception [type: SIGSEGV, Invalid permissions for mapped object] [ADDR:0x0] [PC:0x10801D914, kupfuDecompress()+1268] [flags: 0x0, count: 1]Errors in file /opt/oracle/diag/rdbms/hluat/hlsales/trace/hlsales_dw00_13959466.trc (incident=64284):ORA-07445: exception encountered: core dump [kupf

当用户建立一个物化视图后，会伴随着同时产生一个JOB，定时刷新物化视图其实是通过定时执行JOB实现的。因此，如果手工直接册除了JOB，而仍保留物化视图，那么这个MVIEW是无法自动刷新了。在册除用户时，如果用户有所属的物化视图，而其对应的JOB却被手工册除，这时有可能会出现死锁。这时通过查询v$session_wait会发现有dblink 相关的等待事件。解除这种死锁的办法： 1，手工删除用户所属的物化视图。2，删除用户。[@more@]