我个人活泼开朗,积极向上,思维活跃;热爱数据库行业,对oracle数据库运维工作有浓厚的兴趣,能承受较大的工作压力;具有很强的团队精神,有良好的组织、协调和沟通能力,有强烈的集体荣誉感;自学能力强,喜欢钻研新技术,敢于面对和克服困难;有比较强的动手能力,勇于面对困难和挑战。
ORACLE 12C创建用户之ORA-65096 2016年2月25日,一北京北方人瑞教育咨询公司的同事遇到以.sql文件导入数据时遇到ORA-65096报错,如下图所示: 出现上图导入报错,原因初步定为创建数据库用户AJAO的方法不正确,经过查询发现DBA_USERS视图中已有C###AJAO用户,AJAO用户并不存在,所以在.sql导入时报ORA65096;错误原因是用户想在PDBORCL中创建AJAO用户,却未设置会话container到PDB,而在CDB中创建公有用户因无法通过名称或角色验证出错。
场景描述:2016年1月6日,客户存储RAID5出现问题,更换AIX服务器管理模块,由于设备微码不匹配,导致RAID5中的仲裁盘LUN处于异常状态,进而导致oracle 10.2.0.5的双节点RAC异常宕机。
今天遇见一个很神奇的问题,ERP合同系统需要记录登录oracle数据库的用户名、IP地址、登录时间、登录客户端类型记录信息,需要创建个触发器, 在触发器中需要查询v$session视图,如下所示: create or replace trigger EPMFRAMEWORK.
12月份,上地机房进行电源割接,不少光线交换机重启,业务系统、数据库主机也进行了重启,但是由于设备重启顺序不同导致一内容拨测系统数据库出现了异常。 出问题的数据库所在主机是IBM的AIX 6100,数据库版本是11.2.0.4,采用的是HA双机软件管理的热备双机,数据库安排的有exp定时计划任务。
平台环境是:solaris操作系统 数据库是:oracle 10.2.0.4 故障现象:2015年10月份以来,一综合网管数据库频频报出ORA-31693、ORA-02354、ORA-02149错误,具体报错信息如下所示: .
2015年9月19日,ERP资金系统应急演练,切换AIX ORACLE双机数据库到备机,结果没有成功切换,导致数据库监听无法正常启动,下面是故障的排查及处理过程。
9月2日上午,总部CRM求助,问题是ORACLE 10.2.0.4 RAC 裸设备数据库在表空间扩容时操作失误,将数据文件错误添加成文件系统文件并且还在节点1的本地目录,导致节点2无法完成写操作,报错信息如下: Wed Sep 2 08:23:23 ...
8月25日-8月27日,三天就安装一套oracle 10.2.0.5 for AIX 6100 HA双机,安装过程中真是问题很多。 首先,是启动OUI图形界面,安装是在机房直连网卡进行的,使用的是Xbrowser,直接使用的root用户登录,root能启动图形界面,然后su - oracle,而su到oracle后,oracle启动不了图形界面。
一般情况下,ORACLE DBA看到如下情况的第一反应是,数据库实例没有启动或者是数据库环境变量没有设置正确,今天遇到的情况均不是以上两种情况,有点特别,且来看看为哪般。
Oracle相关组件安全防范做的可谓真够全面,当然监听程序也有相关的安全设置;默认状态下,用户不需要使用任何密码即通过lsnrctl 工具对Oracle Listener进行操作或关闭,可造成新的会话无法建立连接;Oracle监听器允许利用lsnrctl从远程发起对监听器的管理,也容易导致数据库受到损坏。
CENTOS6中文版安装ORACLE10g问题可谓不少,主要体现在ORACLE的OUI界面无法启动、OUI界面乱码。 环境: [oracle@centos6 database]$ uname -a Linux centos6 2.
——记一次ORACLE数据库使用opatch升级PSU的过程 目的:使用oracle自带工具opatch对oracle数据库软件应用高危漏洞补丁集PSU,修复oracle数据库高危漏洞,规避由于普通用户具有业务用户数据表的查询权限, 绕过数据库安全机制对业务用户数据表进行增、删、改操作的隐患。
2015年4月27日,晚上6点左右,电渠3g2库ORACLE RAC系统节点1出现大量的direct path write等待事件,导致大量的会话堆积,节点1几乎无法使用,应用受到影响,相关处理流程如下: 环境: 操作系统:hp-unix 数据库版本:10.
2015年4月24日,上地的增值业务综合网管系统ORACLE的EXPDP又出错了,系统负责人反映从4月20开始到现在该系统的expdp没有备份文件,相关的处理过程如下。
今天上午,电渠生产库维护人员通知,ORACLE生产库中有比较多的latch: cache buffers chains引起的会话,造成堵塞,相关处理过程如下 环境:hp-unix 数据库版本:10.
在为国投做SQL调优时,他们开发说不要动现在的SQL,调整一下执行计划即可,即查询某个表时执行特定的执行计划。乍一听,我是吓了一跳! 由于他们开发不让动SQL结构(该SQL经过PLSQL优化后有500多行,其是2层嵌套递归查询,外边一个SQL如图1-2,外层SQL的每一个列是一个子查询如下图1-1,递归子查询有32个),所以只能从SQL涉及的表、索引下手,查找问题的具体原因及解决办法。
目前,oracle数据库版本已经到达12C了,数据库SQL的执行基本都是基于CBO开销模式的。但是,对于应用维护人员不尽理解数据库的工作原理,他们为了最求数据库的高性能,创建完数据库,却禁用了数据库统计信息自动更新的JOB。
数据库归档模式与RMAN备份策略是保障数据库数据安全的基本手段,对于ORACLE数据库DBA来说,很清楚ORACLE的RMAN备份是基于数据库的归档模式,但对于主机维护人员及开发人员,他们可能很不清楚。
虽然,Linux、Unix主机的定时任务crontab对于应用或数据库服务器的日常维护起到了很大的作用,但是,一旦设置不合理,就会给应用或数据库服务器的正常运行带来潜在的安全隐患。
近期,联通的增值网管系统,在执行EXPDP导出时,频频报ORA-39125、ORA-01555、ORA-06512,导致数据库的EXPDP备份被强制终止。 ORA-39125、ORA-01555、ORA-06512的具体信息如下: Export: Release 10.
作为普通的Oracle数据库用户或使用者,使用sqlplus 执行正常的sql查询遇到下面报错时, SQL> / select spec_id "分公司编号" from test3 where org_id='测试01' * ERROR at line 1: ORA-00972: identifier is too long 第一反应是上网查阅报错原因及处理方法,然而从网上看到最多的是sql语句查询的标识符过长,建议你修改标识符长度。
亲爱的itpuber:欢迎您在ITPUB博客安家,您的博客地址是:http://blog.itpub.net/29357786/ 我们是一个IT技术的技术家园,每一个IT技术人员都能在这里找到与您志同道合的知音。