标签:orcale开发
1:登陆对应的数据库服务器,使用su - oralce 切换到oracle用户(如果当前登录用户就是oracle用户,省略这一步) 2:找到oracle磁盘空间(/u01/app/oracle/product/12.2.0/dbhome_1/rdbms/admin) 3: cd /u01/
1.问题现象 20年12月31日,数据库应用人员反映2020-12-31 12:40:10存在告警,过了几分钟之后业务恢复正常。 表现的状态:Connect to database time out, please check db status! 因为业务反馈的内容很有限,所以我们取了1
前言 你好,我是A哥(YourBatman)。 好看的代码,千篇一律!难看的代码,卧槽卧槽~其实没有什么代码是“史上最烂”的,要有也只有“史上更烂”。 日期是商业逻辑计算的一个关键部分,任何企业的程序都需要正确的处理日期时间问题,否则很可能带来事故和损失。为此本系列仅着眼于这一个点就写了
适逢过年,技术文章也没多少人愿意耐着性子看,那就聊聊我那些年的骚操作。给大家讲讲故事的同时,如果能给列位有所启发,那这篇文章也算是没有白费我的脑汁子。 今天要讲的是有关那些年我赚钱的一些骚操作,当然都是一些小钱,但是操作性是可以借鉴或复制的。 故事得从我上大学时候开始,叙事不分时间先后。
1 取随机数 Oralce把所有有关随机数的操作都封装在了PL/SQL包DBMS_RANDOM里,极大地方便了我们的使用。它具有以下函数:   其中,initialize,random,terminate函数在Oracle11g中已不推荐使用,主要用于向后兼容。下面对各个函数进行举例说明。
[20210220]全索引扫描快速索引扫描的逻辑读.txt--//昨天测试了表扫描逻辑读问题,今天测试看看全索引扫描快速索引扫描的逻辑读.1.环境:SYS@book> @ver1PORT_STRING                    VERSION        BANNER-
[20210219]全表扫描逻辑读问题.txt--//一般探究逻辑读设置_trace_pin_time,或者设置10200事件.--//设置_trace_pin_time有一个明显的缺点就是在系统级设置,而且要重启,这样每个进程产生大量跟踪信息.--//还有的一个因素就是对于唯一索引的执行
1、表空间容量指标查询 SELECT TABLESPACE_NAME "表空间", To_char(Round(BYTES / 1024, 2), '99990.00') || '' "实有", To_char(Round(F
[20210224]控制文件序列号满的分析.txt--//上午看了链接:https://blog.csdn.net/enmotech/article/details/113855641,出现控制文件序列号满的情况,我从来没有遇到.--//下午没事,看看是否能在测试环境演示出来重复故障.--
[20210225]控制文件序列号满的恢复.txt--//继续昨天的测试,今天主要是测试恢复.--//我想给自己增加一点点难度,就是使用noresetlogs打开,因为这样重建的控制文件要读取redo,数据文件重新--//回填一些信息,实际上resetlogs也类似,但是noresetlo
[20210224]fetch r=0算逻辑读吗.txt--//我一直以为fetch r=0时依旧算1次逻辑读.测试发现我理解错了.通过测试说明问题.1.环境:SCOTT@book> @ ver1PORT_STRING         VERSION        BANNER---
关于 oracle 的版本 图源:https://k21academy.com/dba-to-cloud-dba/oracle-database-21c-now-available-on-oracle-cloud-oci/ 用上面一张图可能看的比较清晰,11gR2 应该是对应 11.2
[20210316]MSSM表空间块ITL的LCK 3.txt--//以前的测试,链接:http://blog.itpub.net/267265/viewspace-2564734/=>[20190125]MSSM表空间块ITL的LCK.txt--//昨天遇到的问题ORA-04000 the
没有系统了解过Oracle,这次在Oracle中给新项目建表,把一点经验记录下来 1.新建数据库实例?? 一般不需要 mysql连接edu数据库:jdbc:mysql://localhost:3306/edu Oracle连接orcl实例:jdbc:oracle:thin:@localhost:1
二月初三辛丑年 牛辛卯月 壬戌日 好多天没更博了,为啥呢,因为我的需求上线了,然后又被bibibi了,其中各种心酸背锅以及瑟瑟发抖。。。天呐 回来继续说,今天一个sql的修改: 需求是这样的:在一个日期范围内(2020-03-01至2021-03-12)查询人员类型为(“1003%”、“1004%