ANBOB™

前两节学习了String和Hash, Hash可以把关连性的字段组合到一起用一个KEY, key值多同样会耗费内存和CPU, 在这点上Hash要优于String, 当然String在字符操作上如追加、部分值更新、Key 过期上更加灵活， 都是为特定的场景制定，这里学习另一个数据结构LIST列表，List顾名思义可以认为左右延伸的队列，一种有序存放的数据结构。

前一篇学习了String类型， 由于Redis的数据保存在内存中，查询方式非常块，像String类型可以存储浏览量，投票，文章点击等小量级的数据记录中，如果数据量超过百万级别使用简单的string映射关系会浪费大量的内存，此时Redis推荐使用另一种数据结构:HASH. 存储相同量级的数据Hash 消耗内存约String的四分之一，使用一种压缩存储，同时查询速度也并不差。

Redis支持5种数据类型，这里记录第一个String字符，Redis中的字符串和其它编程语言或键值库功能相似，函数丰富方便，字符串的值可以存储3种类型的值：字节串、整数、浮点数。KEY可以是数字、大小写字母、下划线或中文， Value 有空格要以引号括起。如果value是整数或符点数可以对其自增、减操作。可以增、删、改、查等操作, KEY 和Value可以是中文，但是key是中文是使用keys 列出键时中文为unicode码

In Oracle 12.2.0.1.0 (12cR2), “row cache mutex” replaced 12.1.0.2.0 (12cR1) and 11g “latch: row cache objects”, similar to “latch: library cache” substitution by “library cache: mutex X” in the previous release. High waits on “row cache mutex” when looking up user or role information in user row cache (dc_users)

无论出于安全、特性、性能、支持周期都需要考虑升级数据库，但是也会导致有些功能改变而影响软件使用或管理方式，升级后经验格外重要，因为oracle官方提供的功能无法模拟各行业生产环境中所有的应用场景， 尤其是从最近要面临的11g升级19c大版本升级，防止踩雷，像wm_concat 在新版本不支持一样。

如果在有OGG的表上增加列，又未启用同步DDL ，操作流程不当会遇到很多麻烦， 这里记录replicat进程异常终止。
OGG-00918 Oracle GoldenGate Delivery for Oracle, rep_zwa.prm: Key column NOTE is missing from map.

“酒虽好，不要贪杯” ! OGG在同步效率、安全、兼容性上一致做的很出色，广泛用于数据同步，支持异构， 但是在它的使用过程中也要严格按照流程使用，如何在OGG同步的表上做DDL操作有严格流程，如果任性的使用，后期维护必将带给诸多麻烦， 这里简单记录在OGG进程正在同步事务的情况下增加字段导致的抽取进程异常终止。

Redis是一个速度非常快的非关系型内存数据库，最初由Salvatore Sanfilippo创建，可以存储Key与5种不同类型的Value之前映射，可以将内存键值持久化到硬盘，也可以使用复制特性扩展读性能，算是一个远程内存库，有强劲的性能，致力于帮助用户解决问题，并且开源，通过复制、持久化、分片可以扩展成一个包含数百GB数据，每秒处理上百万次请求的系统，所以在目前的高并发应用中普遍采用

ORA-00600: internal error code, arguments: [kcbbxsv_nwp], [], [], [], [], [], [], [], [], [], [], []
kge_experr : Found error ORA-600 not in expected list.
kge_experr: Dumping error frames [top = 1 : barrier top = 0]
kge_experr : [0] : Error = ORA-600 :
Call stack = ksedsts()+426<-kge_snap_callstack()+77<-kgeadse()+557<-kgerinv_internal()+44 <-kgerinv()+40<-kserin()+180<-kcbbxsv()+17478<-kcbb_coalesce_int()+326<-kcbb_coalesce()+438< -kcbbwthc()+817<-kcbbdrv()+8765<-ksb_act_run_int()+117<-ksb_act_run()+130<-ksbcti()+18

上周在使用TTS传输表空间从11.2.0.4到19C， 在最后impdp metadata的环节提示ora-942 结果提示有大量索引没有创建成功，但是查看报错的表实际是存在的， 后来发现这是一个收权问题导致的。后分析这种场景是发生在如一开始给了一个用户如create ANY table/index的系统权限或者dba 角色或是on object上的权限，后来创建了跨SCHEMA的index（indexes and tables differenct owners）或FK 约束时，再后来安全整改收回大权限，就导致了这个问题。

DRM is driven by the following
1.) _gc_affinity_time = Time in minutes at which statistics will be evaluated (default = 10 mins)
2.) _gc_affinity_limit = # of times a node accesses a file/object (default = 50)
3.) _gc_affinity_minimum = minimum # of times per minute a file/object is accessed before affinity kicks in
(default = 600 per minute per cpu )
4.) _lm_drm_disable = LEVEL disable drm in different level( default=0 )

Oracle RMAN was able to take incremental backups already in 9i. However, prior to introduction of Oracle 10g block change tracking (BCT), RMAN had to scan the whole datafile to and filter out the blocks that were not changed since base incremental backup and overhead or incremental backup was as high as full backup.

在使用TTS迁移一个8T 的11.2.04到19c PDB时，发现expdp和imdp元数据过程中statistic占用了约1个多小时的时间， 但是我检查了实时步骤中确实有写exclude=statistics，猜测是参数没启作用，不能忍. 结果发现这是一个预期行为

数据库会话同样会占用数据库资源，如客户端异常断开在客户端成为一个dead session会永远存在，如果客户端没有断开也没有活动就是一个idle session， 如果这个idle session做了一些修改未提交，然后下班或去吃饭、上WC、开会等，这时就会堵塞其他人对相同的数据做修改，这类会话可以叫做idle blocker session. 在自治数据库中这些session 都可以被释放或者kill / teminal 终结掉，下面对不同的session如何被释放

From 12.2, DataPump import (impdp) will always use non-parallel index creation during import overriding parameter ‘parallel’ in command line or parameter file.

无法提供摘要。这是一篇受保护的文章。

Insufficent memory related errors (i.e: ORA-27xxx).ORA-27102 error may occur because of insufficient shared memory segments.
ORA-27102: out of memory
Linux-x86_64 Error: 12: Cannot allocate memory

HW enqueue根本存在目的是为了串行化对segment高水位线的移动以及回收lob segment中的空间。造成HW enqueue contention争用的根本原因多种多样，但最终HW enqueue总是只在数据段segment High Water Mark高水位线需要移动时才被持有。

Oracle is undoing an index leaf key operation. If the key is not found, ORA-00600 [6006] is logged.
ORA-600[6006] is usually caused by a media corruption problem related to either a lost write to disk or a corruption on disk.

方法一使用了bbed修改 index key的方法， 因为表列上只有这一个索引，所以只改一个索引就可以。这里还使用相同的方法模拟ora-8102,使用第二种方法，删除bootstrap$中的index I_OBJ4 记录解决。