使用Python修改Oracle数据块(上)

近日,旧事告一段落,新事情还没有开始,有时间闲看一些资料,忘了因为什么原因,找到python 的bitarray 文档阅读,突然冒出用这个来修改一下Oracle 数据块的想法…… 这两天测试读取、解析是没问题了,修改、写入还没来得及开始——所以这是“上”篇。 这里只涉及数据文件的“header block”,一般来说说,“header block”有两个:block 0,block 1,今天这里只操作block 1,对其中的"kcvfh"结构进行读取操作。先给出"bbed”显示的block 1结构... struct kcvfh, 860 bytes @0 struct kcvfhbfh, 20 bytes @0 ub1 type_kcbh @0 0x0b ub1 frmt_kcbh @1 0xa2 ub1 spare1_kcbh @2 0x00 ub1 spare2_kcbh @3 0x00 ub4 rdba_kcbh @4 0x01c00001 ub4 bas_kcbh @8 0x00000000 ub2 wrp_kcbh @12 0x0000 ub1 seq_kcbh @14 0x01 ub1

Oracle 19c CRS重启案例记录

对文件系统进行较大写入操作(30g文件写入),导致RAC一个节点被驱逐重启。 MOS info:Bug 30472602 CRS: oracssdagent is rebooting this node because the file system did not respond This note gives a brief overview of bug 30472602. The content was last updated on: 15-JAN-2020 Click here for details of each of the sections below.Affects: Product (Component) Oracle Server (PCW)Range of versions believed to be affected Versions

Oracle CRS 启动问题诊断

  #工程师培训# #CRS# 从10g开始,Oracle使用自己的CRS管理RAC集群,到了11g、12c,voting disk,ocr,共享存储等等都由Oracle自己的集群软件管理(从11g开始,名称由CRS调整为GI——Grid Infrastructure)。 对外提供服务的数据库集群,依赖于底层GI。而GI要求共享存储、网络通讯、节点间进程通讯都准备就绪,才能正常运行。GI本就是由许多组件构成的集群(复杂)管理系统,雪上加霜的是,由于GI的日志输出中,有过多的Info级别的信息,且各个组件都有自己的日志,这些都造成了如果GI启动不成功,定位故障点比较困难。 本文结合MOS 《Troubleshoot Grid Infrastructure Startup Issues》一文对GI启动问题进行梳理。 首先还是来说日志,先要能确定其存储位置: Oracle 10g, 存储于$GRID HOME/log/name>/… ,当然在10g中其实还没有明确定义GRID HOME。 Oracle 11g, $GRID HOME/log/name>/ , 好像跟10g的没有区别 Oracle 12c,发生了改变,不加注意,容易在出问题时找不到日志 3.1 Standard cluster: $ORACLE_BASE/diag/crs/… 位置发生了改变,并且彻底使用ADR来管理日志。 3.2 Flex cluster: $ORACLE HOME/log/name>  因为Grid Infrastructure组件较多(CRSD,CSSD,EVENTD…),所以日志也就很多,总体来说,应该先查看alert.log ,再查看各组件的日志。 即使你已经对于去哪里能找到Grid Infrastructure的日志很清楚,真正面对目录中那么多日志、trace,以及日志中不知道什么意思的各种输出,很容易迷失。我的经验是,在“陷入”日志之前,先从操作系统角度查找一下,有没有什么明显的问题,导致Grid Infra不能启动。 OS级别的检查: 网络PING,将/etc/hosts中定义的,集群内的各个IP都ping一下 共享存储,以及其权限 文件系统空间使用、inode使用(Grid Infra经常因为产生日志太多,用尽inode,把自己撑死) … 总觉得还有别的,以后想到再补充 GI 启动顺序 操作系统启动ohasd —》

使用SQL*Plus生产CSV格式数据

使用SQL*Plus生产CSV格式数据 #工程师培训 #sqlplus# 因为Excel、很多BI工具、甚至一些数据库,都支持直接导入CSV(comma separated value)格式数据,所以一直以来,我们都有将Oracle数据库中表的数据行导出成为CSV格式的需求。从Oracle 12.2.0.1开始,SQL*Plus支持将查询输出为CSV格式。本文对此新特性进行演示。 演示环境 [SQL*Plus] CREATE TABLE BOOKS (
 BOOK_ID NUMBER GENERATED ALWAYS AS IDENTITY,
 TITLE VARCHAR2(250) NOT NULL,
 PAGES NUMBER NOT NULL,
 AUTHOR VARCHAR2(250) NOT NULL,
 CONDITION VARCHAR2(4000),
 CONSTRAINT BOOKS_PK PRIMARY KEY (BOOK_ID),
 CONSTRAINT BOOKS_UQ UNIQUE (TITLE)
);
 
[SQL*Plus] INSERT INTO BOOKS (TITLE, PAGES, AUTHOR, CONDITION) VALUES ('The Hobbit', 322, 'J.

检查Oracle redo log切换频率的SQL

这个SQL的特点是模拟日历(Calendar)形式,显示每小时产生的redo log数量: SELECT * FROM (SELECT A.* FROM (SELECT * FROM (SELECT TO_DATE(b.date_time, 'DD/MM/YYYY') dt,TO_CHAR(TO_DATE(b.date_time, 'DD/MM/YYYY'), 'DAY') DAY,"00", "01", "02", "03", "04", "05", "06", "07", "08", "09","10", "11", "12", "13", "14", "15", "16", "17", "18", "19", "20", "21", "22", "23", TOTALFROM (SELECT date_time,SUM(DECODE(HOUR,'00',1,NULL)) "00", SUM(DECODE(HOUR,'01',1,NULL)) "01", SUM(DECODE(HOUR,'02',1,NULL)) "02",SUM(DECODE(HOUR,'03',1,NULL)) "03", SUM(DECODE(HOUR,'04',1,NULL)) "04", SUM(DECODE(HOUR,'05',1,NULL)) "05",SUM(DECODE(HOUR,'06',1,NULL)) "06", SUM(DECODE(HOUR,'07',1,NULL))

获取用户User,对象Object的DDL定义

  获取用户、用户权限的DDL语句 [code language="sql"]set feedback off pages 0 long 90000 serveroutput onaccept USERNAME prompt "Enter username :" [/code] 获取对象、相关对象的DDL 特定表的DDL: [code language="sql"]SET LONG 2000000 SET PAGESIZE 0 SELECT DBMS_METADATA.GET_DDL(TABLE,EMP’,’SCOTT’) FROM DUAL; [/code]   获取表相关的授权: [code language="sql"]SET LONG 2000000 SET PAGESIZE 0 SELECT DBMS_METADATA.GET_DEPENDENT_DDL(‘OBJECT_GRANT’,’EMP’,’SCOTT’) FROM DUAL; [/code]   获取指定schema(这里用scott举例)的所有表DDL: [code language="sql"]-- ### Schema all object DDL