升级patchset是小事？不是，patchset的升级从来都不是小事。如12.1.0.1到12.1.0.2就多了一个引人注目的in-memory options。今天说一个你可能不知道的从11.2.0.3升级到11.2.0.4的变化。（Solaris操作系统）

在高并发的连接时，如果listener“太忙”，就会在tcpip这一层把包丢弃，我们可以在操作系统上用命令看：

如果上述两个值长时间大于0，说明有排队现象，会导致系统网络速度变慢。

对应于listener，我们可以适当的加大queuesize参数，来解决上面的问题。

可是问题是，在没有设置的情况下，默认值是多少？

在文档TNS-12535 / ORA-12535 on Connection to Database (Doc ID 214122.1)中有提及：

也就是说，在10.1之后，11.2.0.4之前，queuesize的大小是固定值32，而11.2.0.4（含）之后，大小就直接使用操作系统参数SOMAXCONN。

我们来验证一下：

我当前系统是11.2.0.4，也就是说，是受到SOMAXCONN的限制。我先设置了queuesize=123。

然后用truss开始跟踪：

从truss中，我们看到第三行变成了我预设的那个值（注：不同的主机，不同的操作系统版本，grep出来的行数可能不同，不一定在第三行）：

好，我们取消queuesize的设置，恢复成默认值。

然后我们继续truss，继续grep看truss的结果：

看到第三行已经变成了128。

也就是说，在我不设置queuesize的情况下，我的11.2.0.4的数据库的listener的queuesize取决于操作系统参数SOMAXCONN，这个值是128。

而操作系统SOMAXCONN的值，我们其实可以看/usr/include/sys/socket.h文件，里面有SOMAXCONN的值：

最后，再说一下，在同一台主机上，还有一个11.2.0.3的数据库，按照上面的truss方法，得到的默认queuesize值为32。确实如文档所说。

所以，这篇文章介绍了用truss验证listener默认queuesize的大小。如MOS文档所说，不同版本的数据库，queuesize的大小是不一样的。

有时候，你从11.2.0.3升级到11.2.0.4，发觉连接风暴的问题缓解了，其实是内部行为不一样了，11.2.0.4默认取操作系统SOMAXCONN值，而现在的主机的SOMAXCONN，一般都比32要大。而这些变化，是Oracle Database 11g Release 2 (11.2.0.4) New Features不会提到的。:)

在12c之前的行为，LGWR主线程负责redo strand的读取，而由spawn出来的thread来模拟异步IO进行redo的写入，然后由main thread通知FG进程而结束log file sync的等待。（可以看到第0个lwp的CPU占据比其他几个lwp稍高。）

12c中有了scalable lgwr的功能，LGWR作为主进程做协调工作，具体的事情有slave进程LGnn来做。LGWR负责保证redo是按照顺序写入的，而slave LGnn根据LGWR的指示来进行redo strand的读取和redo的磁盘写入，并且由LGnn来直接通知FG进程写入完成而结束log file sync的等待。

1. lgwr的子进程lgnn，适用在多CPU的系统中，Oracle由参数_use_single_log_writer控制，（默认值是adaptive，另外还有true和false），当设置为默认值adaptive，会根据系统负载，自动的调节是single log writer还是scalable log writer。调节的时候，在lgwr的trace文件中可以看到：

2. LGnn的最多个数，有_max_outstanding_log_writes决定。

3. Dataguard的SYNC模式不能用到multiple LGWR属性：
LGnn (Log Writer Worker) On multiprocessor systems, LGWR creates worker processes to improve the performance of writing to the redo log.
LGWR workers are not used when there is a SYNC standby destination. Possible processes include LG00-LG99.
参考：New Background Processes In 12c (Doc ID 1625912.1)

4. 存在 scheduling delay for the slaves。在single instance中，high priority和highest priority都没有放LGWR；在RAC中，high priority中有放LGWR，但是没有LG*，可能会导致LGWR虽然有较高优先级，但是子进程没有较高优先级。所以，可能需要设置和lgwr一样priority的lgwr slave进程 。
参考Bug 20055279 : RAC PERF: LGWR CHOOSES TO USE SCALABLE LGWR BUT SINGLE LGWR PERFORMS BETTER

5. multiple LGWR适合多CPU的系统，特别是CPU高于64个以上的系统。我个人猜测是一方面在scalable lgwr情况下，lgwr起到协调者的作用，协调的时候需要消耗CPU进行计算。另外一方面，多个子进程之间也需要CPU资源进行同步信息，以保证其写的顺序。
LGWR workers are used when using a single LGWR would perform better. This applies to small systems (<= 64 cpus).
参考Bug 20055279 : RAC PERF: LGWR CHOOSES TO USE SCALABLE LGWR BUT SINGLE LGWR PERFORMS BETTER

6. LGnn进程之间会进行同步，我想这也是为什么能保证写redo log的时候，保证其一致性的原因。有的时候，LGnn之间不必要的同步，会导致性能变慢。
This means there will be unneeded LGWR slaves in each group and we will incur intra group synchronization costs for these.
参考 Bug 18683889 : SIGNIFICANT WAIT ON ”LGWR INTRA GROUP SYNC” WITH SCALABLE LGWR

7. 在AIX和HPIA环境中，启用scalable lgwr还可能导致数据库起不来，需要提前打好patch 21915719(注：打完patch 21915719之后，_use_single_log_writer=true就自动设置好了。)
参考 ALERT: Bug 21915719 Database hang or may fail to OPEN in 12c IBM AIX or HPUX Itanium – ORA-742, DEADLOCK or ORA-600 [kcrfrgv_nextlwn_scn] ORA-600 [krr_process_read_error_2] (Doc ID 1957710.1)
注意，这个文档已经变成ALERT类型，说明已经发生过比较多的问题。一般ALERT文档都是值得注意的预警性文档。

9月的OOW快要到了，估计12.2的版本届时也会发布，今天我们来看提前一下相比于12.1，12.2多了那些新特性。
（注：这些新特性，大家仅当rumor看看就好，真正的12.2新特性，以实际发布为准。）

(1)PDB and CDB相关：

(2)TSDP(Transparent Sensitive Data Protection)相关：

(3)rman相关：

(4)在线重定义相关：

(5) online DDL增强：

(6) data pump相关：

(7)in-memory相关：

(8)Tuning相关：

(9)分区的新特性和sharding的新特性：

Partition：
『12.2 new feature of partition』

sharding:
『Oracle sharding database的一些概念』
『创建Oracle sharding database』
『闲聊sharding database架构』

12.1.0.2之后，duplicate target database for standby from active database的时候，总是hang死在restore controlfile的情况。这个由于Bug 19664695引起。（Bug22468652和Bug 20721271最终都可以归结到Bug 19664695上去。）

解决方法是在ORACLE_HOME和GRID_HOME的sqlnet.ora文件中都设置DISABLE_OOB=on 。详情可参考 RMAN active duplicate hanging on restore control file (Doc ID 2073604.1)

当我们用DBMS_STATS.CREATE_STAT_TABLE备份统计信息的时候，我们可以看对应的备份统计信息表各个字段的含义。

根据Type有分T=table，I=index，C=column，S=system。具体含义见下：

参考：Doc ID 188152.1 INTERNAL

_db_block_max_cr_dba 这个隐含参数的作用是控制每个block（即一个dba下，或者说x$bh.dbablk）的最多cr块的个数。默认值是6（5个CR+1个XCUR）。

当产生一致性读（CR）的时候，session会从前镜像读取块，加载到buffer cache中，加载的这个块，我们叫CR copy。

保留多个版本的CR，可以缓解对buffer中block的并发争用（buffer busy wait），避免多个session同时读取一个buffer block。

但是如果版本过多，挂在一个hash chain下的block太多，又会造成CBC latch的争用。所以oracle选择了6个版本。

我们来测试一下CR copy的特性（数据库版本11.2.0.4）：

刚刚启动的时候，我们发现file#=4，block#=1365没有在buffer中。

当开始DML之后，block中数据文件中加载到buffer中，此时一定会有一个xcur的block，和cr block。这是因为DML is always performed on the current copy of the block (Status=xcur).

Whenever an update is made to the block,
  If the current block is in the buffer (status = xcur)
    A clone of the current block is made (status=cr)
    Update is performed on the current block (status=xcur)
  Else (the desired block is not in the buffer)
    The block is read from the disk (status=xcur)
    A clone of the block is also made (status=cr)
    Update is performed on the current block (status=xcur)

xcur的block表示当前已经被修改过的block，是最新的block，注意DI列（Dirty列）已经是Y，表示这个block是buffer中的脏块。

cr block是在update之前，在内存中copy原来的xcur的block。我们看cr block的CR_SCN_BASE是update前一瞬间的SCN，即2687527。

即当update发生的时候，
   如果块在buffer中(块的状态为xcur)，
      那么copy一份这个在buffer中的xcur的块，copy出来的块是cr块。
      更新这个块，且这个块的标记还是xcur。
   如果在buffer中没有这个块
      那么将这个block从磁盘读到buffer中（此时状态为xcur。这个过程，类似进行了一次没有一致性读的select，select的时候，当前块状态也是为xcur）
      将buffer中的xcur块，做一份copy，copy出来的块成为cr块
      更新这个块，且这个块的状态还是xcur

====================

第一次的select，oracle一次性创建了2个CR block，分别是在SCN 2687545和SCN 2687546的时候。

这个时候，由于是需要一致性读，因此这次的select是从前镜像读取，从undo中读取，所以，也可以看到这个前镜像块是从undo的那个块上读取，可以看到有UBA（undo block address）的file id，block id和sequence。file id为3，是在undo tablespace上。

===============

第二次的select，oracle只创建了1个CR block，分别是在SCN 2687575的时候。 读取的是在undo上的同一个UBA file id，block id和sequence，所以，在undo文件上的块是同一个块，但是在buffer中，cr块目前已经有3个cr块了。

另外还有一个cr块，但是这个块是在做update的时候，对于该session来说在update之前的xcur的copy。不是从undo文件中读取的block。

===============

第三次的select，oracle只创建了1个CR block，分别是在SCN 2687595的时候。 读取的是在undo上的同一个UBA file id，block id和sequence，所以，在undo文件上的块是同一个块，但是在buffer中，cr块目前已经有4个cr块了。

另外我们注意到，oracle已经把第一次做update的时候，SCN 2687527的cr块刷出去了。这个被丢弃的CR block，对我做update的session来说，已经没有用处，因为当前session的block的值已经更新，当前session所需要的block是xcur的那个block。而对已其他session来说，由于还没有commit，需要读取前镜像，可以直接做第一次和第二次cr block的copy；或者直接从undo中加载。

===============

第四次的select，oracle只创建了1个CR block，分别是在SCN 2687615的时候。 读取的是在undo上的同一个UBA file id，block id和sequence，所以，在undo文件上的块是同一个块，但是在buffer中，cr块目前已经有5个cr块了。

===============

第五次的select，oracle只创建了1个CR block，分别是在SCN 2687643的时候。 创建这个CR block的时候，把当前cr block列表中最早的SCN 2687545的block丢弃了。只保留5个CR block。

至此，我们看到，不同的session的select，对cr block的影响：
update但不commit，在update时产生一个cr block。
第一次select从undo获得前镜像产生2个cr block，当前共3个cr block
第二次select再产生一个cr block，当前共4个cr block
第三次select再产生一个cr block，且丢弃update时的cr block，当前共4个cr block
第四次select再生产一个cr block，至此已经有了5个cr block和1个xcur block
第五次select再产生一个cr block，丢弃第一次select产生的第一个block，只保留5个cr block和1一个xcur block
再后续select的话，每产生一个cr block，丢弃最早的cr block


===============

我们看到，flush buffer cache之后，xcur的block，即标记为dirty的block也被刷出buffer cache，所有的buffer block都是显示free。

但进行第一次select的时候，被修改的xcur block，还是从db file加载到内存，且被记录成dirty的block。另外，select出来的前镜像，也从undo加载到内存，形成第一个cr block。

到了这个，顺便问个问题，现在都流行database in memory，如果我的内存是256G的，能放得下256G的database吗？读了上面的问题，相信你已经有了初步的答案。：）

rman连接catalog备份时使用的基表和view，解释如下：

参考 Doc ID 1054528.6

客户有个需求，需要将在一个包含多个rac、多个single instance的大cluster中的某个rac 节点，改成single instance。数据文件还在asm上，原来的数据文件还要继续时候用。

我们可以如下操作：

下面我们来具体操作：

（1）备份spfile

（2）停需要转换的数据库实例

（3）删除数据库实例在cluster中的注册信息

（4）修改pfile中关于cluster相关的内容

（5）启动单实例，并修改redo和undo

（6）将spfile还原回到asm上。

参考：Doc ID 759868.1 INTERNAL

问题是这样的：
在12c中，我们测试了2种情况：
第一种是加了hint，使得12c的执行计划和10g类似，只是由于12c的nlj_batching，多了一次nestloop。但是执行计划本质是相同的，都是索引S_CONTACT_X_U1返回表查询。
第二种是使用了10g的outline hint，OFE=10g的，执行计划完全一样。

但是我们发现，无论是在12c中的哪一种情况，驱动表S_SRV_REQ的索引PA_S_SRV_REQ_1_X的full index scan返回结果差异这么大？

文章最后附在10g和12c环境中的测试经过，以及10g环境中的10046 trace和12c第一种情况的10046 trace。

12c-第一种情况：

12c-第二种情况：

10g数据库的情况：

###################################

另外，根据过滤条件，10g和12c返回结果也差不多。且消耗也差不多！

12c：

10g：

在同事的Fred Liu的帮助下，我们终于找到了答案。（Fred Liu在他近期的微信公共账号也写了这个问题。大家可以关注：『老虎刘谈SQL优化』 ）

（1）首先，这个SQL逻辑有问题。可以见我附件10g.txt中的附件，有完整的sql文本

SQL的主要功能是分页，客户这里把rownum和order by写在一层关系中了。所以这个是错误的。

（2）就算是在逻辑错误，为什么10g跑快，A-rows小？
这是因为SQL语句中rownum<=10, 而10g的返回记录是10行，12c的返回记录只有4行。
在rownum<=10的情况下，10g扫描索引的时候，扫描了264行之后，已经够10行了，所以可以返回；而12c中扫描索引，只有4行，也就是说，从开头扫到结尾，扫描全部还没找齐10行。所以需要扫描整个索引。因此消耗就高了。
其实我将SQL语句改写成rownum<=4，这样也可以在3秒多返回记录了。或者我将SQL改成rownum<=8000，那么在10g中运行也很慢了。

（3）修正SQL逻辑后，客户的SQL还是跑的慢，15分钟，发现因为客户写的hint用到的索引不是最优执行计划，使用acct_open_dt这个字段的索引之后（或者不用指定，oracle自己的CBO会选择这个索引），还要把1/3移动到右边，结果不到1秒就出来了。（注，如果1/3不移动到右边，还是会很慢。）

在这个案例中，我们可以学到的知识点：
1. 要分析SQL语句的逻辑，不能光看执行计划
2. 要注意count stopkey和a-rows的值。不然会想不明白为什么在10g扫描了264行就停止了。
3. 对方说数据源是一样的，不能完全相信。上述例子就可以看到，同样语句实际数据源还是有差异的，一个返回10行一个返回4行，而这个原因导致执行效率差别很大。
4. 索引字段有运算关系，需要把运算放到右边。才能正常使用索引。

附件：完整的SQL信息和执行计划 sql_compare_in_10g_and_12c.zip

客户一个数据库，架构是2地3中心，本地有primary和standby，远程还有一个standby。

primary的rman archivelog deletion policy是ship to all standby
同城standby的rman archivelog deletion policy是backup 1 time，备份在同城standby上进行。
远程standby的rman archivelog deletion policy是applied on all standby。

某一天发现FRA区满了，FRA区积累了大量的规定日志，没有被自动删除，手动删除归档日志的时候，也报错：

RMAN-08120:WARNING: archived log not deleted, not yet applied by standby

只有加force参数才能强行删除日志。

这个问题，是因为在12.1.0.2中，删除归档日志的默认行为发生了变化。原来在11g中不考虑defer的路径，在12.1.0.2时如果有defer的路径，则会报错日志没有applied，即使这些日志实际上已经被applied了。

This behavior has changed and is related to:

Bug 16082541 RMAN DELETES ARCHIVELOGS WHICH HAVE NOT BEEN APPLIED TO A DEFERRED STANDBY
which was fixed in 12.1.0.2, ( but has changed behaviour in handling of deleting logs)

Changed behaviour:
-> Destinations that are marked DEFERRED (and valid_now=’UNKNOWN’) are considered in in 12.1.0.2 before deleting logs.

客户的这个环境，设置了log_archive_dest_n（这是为了switchover时方便继续做standby）：
在primary设置了log_archive_dest_2为远程standby，log_archive_dest_state_2为enable；log_archive_dest_3为同城standby，log_archive_dest_state_3为enable。
在同城standby设置了log_archive_dest_2为primary，log_archive_dest_state_2为defer；log_archive_dest_3为远程standby，log_archive_dest_state_3为defer。
在远程standby设置了log_archive_dest_2为primary，log_archive_dest_state_2为defer；log_archive_dest_3为同城stanby，log_archive_dest_state_3为defer。

这样在switchover的时候，只需将defer的参数改成enable，就可以继续做dataguard。

可是，就是因为这样的参数设置，加上12.1.0.2的删除日志规则的改变，造成了在远程standby上，由于规则是applied on all standby，且设置成了defer，所以就无法删除。

在远程standby上检查
SQL> SELECT * from v$archive_dest where (valid_now = 'UNKNOWN' AND status = 'DEFERRED') ;
返回有2行记录，即primary和本地standby。

目前可以参考的解决方案：
1. 不改log_archive_dest_state_n，设置log_archive_dest_n=''
2. 不取消log_archive_dest_state_n，修改log_archive_dest_n为enable
3. alter system set "_deferred_log_dest_is_valid"=false
4. archivelog deletion policy从applied on all standby改成applied on standby

参考：Doc ID 2022958.1

12c的数据库在安装的时候，有一个检查项目，叫做Maximum locked memory check。

这是要求设置/etc/security/limits.conf中的memlock的值，官方文档在11g要求是设置比物理内存稍小的一个值，在12c中要求至少为90%的物理内存。

而memlock的设置，是启用huge page的一部分。开启hugepage在大内存大sga的环境下，可以提供系统的性能。

启用hugepage需要设置/etc/security/limits.conf和vm.nr_hugepages(Doc ID 361468.1)

注1：
在asm中，当启用hugepage时oracle建议asm的SGA增大到至少2G，设置hugepage至少1300个以上的大页面（Doc ID 2111010.1）

在Exadata中，默认启用了hugepage，且安装Exadata的时候，就默认禁用了asm的AMM（PGA不使用hugepage，这也是为什么使用hugepage不能同时使用AMM，只能使用ASMM的原因。因为AMM是自动管理SGA+PGA。而hugepage不能被PGA使用。），设置了SGA大小为2G。（Doc ID 1681467.1）。
上述的大小只是一个大概的估算值，如果需要计算大小，也是可以计算的。asm的shared pool的大小，在150M的基础上，external冗余的disks，每增加100G的空间大小，需要额外的1M内存（Doc ID 437924.1）

注2：
在12c中grid中多了一个MGMTDB来记录GI资源信息，这个DB的SGA使用，也要考虑看hugepage的配置中。不过由于mgmtdb不确定会跑在那个节点上，在Exadata的health check检查项目中，是建议把mgmtdb使用hugepage属性关闭的。（Doc ID 1274318.1）

注3：
还有一个参数pre_page_sga，在9i～11g中默认值是false，在12c中默认值是true。在12c之前，默认值false可以避免在进程启动时，access sga中所有的page页面加快进程的启动速度（见connection management call elapsed time）。而在12.1之后，算法发生了改变，设置为true和false几乎没有差别。

注4：
上面说的hugepages，指的是regular hugepages，而对于transparent hugepages，我们是需要禁用的。见Disable Transparent HugePages on SLES11, RHEL6, RHEL7, OL6, OL7, and UEK2 and above (Doc ID 1557478.1)。
regular hugepages是提前分配，不是动态分配，transparent hugepages是通过khugepaged线程动态配置的，这可能会导致Oracle运行过程中出现一些奇怪的问题，Oracle建议关闭Transparent HugePages功能。

注5：
放在small pages上的sga，不会直接占用物理内存（这样应该是在page fault时才会申请物理内存）。即ipcs -am看到占用的内存的是在vm中，不是在RSS中，实际物理内存中。

所以，
（1）oracle推荐在大内存大sga的情况下，使用hugepage。文档上说是大于8G物理内存（Doc ID 361468.1）；在实际使用中，客户如果超过64G内存，我们一般都推荐使用。
（2）对于asm我们可以设置sga至少2G，同时注意要求至少1300个以上的大页面。
（3）对于mgmtdb，我们可以设置use_large_pages=false禁用mgmtdb使用hugepage。
（4）如果多个数据库共享一个主机，但是如果我们提前把hugepage的配置能覆盖到所有instance，那么就不存在什么问题。在11g中，有use_large_page参数，默认值为true。即默认尝试配合OS使用hugepage。但是在11.2.0.2的时候，如果hugepage不够cover sga，会导致数据库启动不了。在11.2.0.3以后，oracle会在hugepage不够的情况下，将使用small page来弥补剩余的page，从而启动数据库（Doc ID 1392497.1）
（5）禁用transparent hugepages(Doc ID 1557478.1)

索引是一般索引还是分区索引，可以看dba_indexes的partitioned字段。

如果partitioned字段是YES，说明是分区索引，那么，这个索引是global还是local，可以看dba_part_indexes的LOCALITY字段。

另外，我们还可以看ALIGNMENT字段，看这个索引是基于前导列（prefixed）还是非前导列。(注：global肯定是基于前导列，因为不能建基于非前导列的global索引。而local索引可以基于前导列和非前导列)

SQL> drop table invoices;

Table dropped.

--创建分区表，是range分区：
SQL> CREATE TABLE invoices
  2  (invoice_no    NUMBER NOT NULL,
  3   invoice_date  DATE   NOT NULL,
  4   invoice_area varchar2(200),
  5   invoice_serial number,
  6   comments      VARCHAR2(500),
  7   invoice_name varchar2(20)
  8   )
  9  PARTITION BY RANGE (invoice_date)
 10  (PARTITION invoices_q1 VALUES LESS THAN (TO_DATE('01/04/2001', 'DD/MM/YYYY')) TABLESPACE users,
 11   PARTITION invoices_q2 VALUES LESS THAN (TO_DATE('01/07/2001', 'DD/MM/YYYY')) TABLESPACE users,
 12   PARTITION invoices_q3 VALUES LESS THAN (TO_DATE('01/09/2001', 'DD/MM/YYYY')) TABLESPACE users,
 13   PARTITION invoices_q4 VALUES LESS THAN (TO_DATE('01/01/2002', 'DD/MM/YYYY')) TABLESPACE users);

Table created.

SQL>
SQL> --创建global分区索引，分区类型可以和表一样，也可以不一样。这个索引是和表分区类型一样，但是value less值不一样。
SQL> CREATE INDEX idx_glob_inv_ser ON invoices (invoice_serial,comments) GLOBAL
  2  PARTITION BY range (invoice_serial)
  3  (PARTITION invoices_q1 VALUES LESS THAN (10) TABLESPACE users,
  4   PARTITION invoices_q2 VALUES LESS THAN (20) TABLESPACE users,
  5   PARTITION invoices_q3 VALUES LESS THAN (30) TABLESPACE users,
  6   PARTITION invoices_q4 VALUES LESS THAN (40) TABLESPACE users,
  7   PARTITION invoices_qmax VALUES LESS THAN (MAXVALUE) TABLESPACE users);

Index created.

SQL>
SQL> --注意global分区索引，必须使用前导列，及如果索引列是 (comments,invoice_serial)，
SQL> --但partition by xx(invoice_serial)用了非前导列，是会报错，不能创建成功的。
SQL> CREATE INDEX idx_glob_inv_date ON invoices (comments,invoice_serial) GLOBAL
  2  PARTITION BY hash (invoice_serial) partitions 16;
PARTITION BY hash (invoice_serial) partitions 16
                                 *
ERROR at line 2:
ORA-14038: GLOBAL partitioned index must be prefixed


SQL>
SQL>
SQL> --创建另一个global分区索引，这个索引的分区类型是和表分区类型不一样的。用了hash分区。但是prefix前导列的原理也是一样的，需要使用前导列。
SQL> CREATE INDEX idx_glob_inv_date ON invoices (comments,invoice_serial) GLOBAL
  2  PARTITION BY hash (comments) partitions 16;

Index created.

SQL>
SQL>
SQL> --创建local索引，注意不能指定partition by的类型的，local索引的分区类型和分区数量必须和table一致，但是可以指定不同的表空间。这个local使用了前导列。
SQL> CREATE INDEX idx_glo_inv_dt ON invoices (invoice_date,invoice_serial) LOCAL
  2   (PARTITION invoices_q1 TABLESPACE users,
  3    PARTITION invoices_q2 TABLESPACE users,
  4    PARTITION invoices_q3 TABLESPACE users,
  5    PARTITION invoices_q4 TABLESPACE users);

Index created.
SQL>
SQL> --如果分区数量必须和table不一致，会报错：
SQL> CREATE INDEX idx_glo_inv_dt ON invoices (invoice_date,invoice_serial) LOCAL
  2   (PARTITION invoices_q1 TABLESPACE users,
  3    PARTITION invoices_q2 TABLESPACE users,
  4    PARTITION invoices_q3 TABLESPACE users,
  5    PARTITION invoices_q4 TABLESPACE users,
  6    PARTITION invoices_q5 TABLESPACE users);
CREATE INDEX idx_glo_inv_dt ON invoices (invoice_date,invoice_serial) LOCAL
                               *
ERROR at line 1:
ORA-14024: number of partitions of LOCAL index must equal that of the underlying table

SQL> --创建local索引，注，local索引可以使用非前导列。而global索引只能使用前导列，不能使用非前导列。
SQL> CREATE INDEX idx_glo_inv_serl ON invoices (invoice_serial,invoice_date) LOCAL
  2   (PARTITION invoices_q1 TABLESPACE users,
  3    PARTITION invoices_q2 TABLESPACE users,
  4    PARTITION invoices_q3 TABLESPACE users,
  5    PARTITION invoices_q4 TABLESPACE users);

Index created.
SQL>
SQL> --如果分区数量必须和table不一致，会报错：
SQL> CREATE INDEX idx_glo_inv_serl ON invoices (invoice_serial,invoice_date) LOCAL
  2   (PARTITION invoices_q1 TABLESPACE users,
  3    PARTITION invoices_q2 TABLESPACE users,
  4    PARTITION invoices_q3 TABLESPACE users,
  5    PARTITION invoices_q4 TABLESPACE users
  6    PARTITION invoices_q5 TABLESPACE users,
  7    PARTITION invoices_q6 TABLESPACE users);
  PARTITION invoices_q5 TABLESPACE users,
  *
ERROR at line 6:
ORA-14010: this physical attribute may not be specified for an index partition


SQL>
SQL> --创建一般索引（即非分区索引）：
SQL> create index idx_glo_inv_comm on invoices (comments);

Index created.

SQL>
SQL>
SQL>
SQL>
SQL> select index_name,PARTITIONED from dba_indexes where table_name='INVOICES';

INDEX_NAME           PARTIT
-------------------- ------
IDX_GLOB_INV_SER     YES
IDX_GLOB_INV_DATE    YES
IDX_GLO_INV_DT       YES
IDX_GLO_INV_SERL     YES
IDX_GLO_INV_COMM     NO

SQL>
SQL> select INDEX_NAME,PARTITIONING_TYPE,LOCALITY,ALIGNMENT from dba_part_indexes where table_name='INVOICES';

INDEX_NAME           PARTITIONING_TYPE  LOCALITY     ALIGNMENT
-------------------- ------------------ ------------ ------------------------
IDX_GLOB_INV_SER     RANGE              GLOBAL       PREFIXED
IDX_GLOB_INV_DATE    HASH               GLOBAL       PREFIXED
IDX_GLO_INV_DT       RANGE              LOCAL        PREFIXED
IDX_GLO_INV_SERL     RANGE              LOCAL        NON_PREFIXED

SQL>

11g之前：

select spid, program from v$process
where program!= 'PSEUDO'
and addr not in (select paddr from v$session)
and addr not in (select paddr from v$bgprocess )
and addr not in (select paddr from v$shared_server);

11g之后：

select * from v$process where addr=(select creator_addr from v$session where sid=140);

参考：
How To Find The Process Identifier (pid, spid) After The Corresponding Session Is Killed? (Doc ID 387077.1)

在oracle数据库hang的情况下，我们可以用sqlplus -prelim / as sysdba登录数据库，进行一些收集信息的操作，也可以进行shutdown database的操作。这里需要注意几点：

1. process满是可以用sqlplus -prelim / as sysdba登录的

2. 从11.2.0.2开始，sqlplus -prelim / as sysdba是不能收集hanganalyze的信息，即使hanganalyze命令运行成功，但是在trace文件中看不到对应的信息，只能看到如下的报错：

ERROR: Can not perform hang analysis dump without a process state object and a session state object.
( process=(nil), sess=(nil) )

3. sqlplus -prelim / as sysdba可以收集process state dump，system state dump，dump errorstack，short_stack的操作。

参考：How to Collect Diagnostics for Database Hanging Issues (Doc ID 452358.1)

有一个库自从上线之后，主库的alertlog中一直有如下报错：

Tue Dec 20 14:42:16 2016
Error 12154 received logging on to the standby
PING[ARC2]: Heartbeat failed to connect to standby 'rmydb'. Error is 12154.

1. 检查远端的standby库已经启动，且已经到了mount以上的状态（即在read only的模式下Real Time Apply）。

2. 检查主库到远端的tnsping，正常。

3. 检查主库sqlplus user/pwd@tns 也是正常连接。

4. defer log_archive_dest_state_2后再enable，让archive进程意识到tnsnames.ora的变动。（怕之前修改过，archive进程没有意识到。），还是没用。依旧报错。

5. 再检查了一下，发现TNS_ADMIN的环境变量没有设置。所以用于心跳检测的archive进程，会找不到tns的配置文件。

临时解决办法：

不使用tnsnames.ora的配置文件，直接在log_archive_dest_2中设置：
alter system set log_archive_dest_2='SERVICE="(description=(address_list=(address=(protocol=TCP)(host=rhost)(port=1534)))(connect_data=(sid=mydb)))" LGWR ASYNC NOAFFIRM reopen=60 valid_for=(online_logfile,primary_role) db_unique_name=rmydb';

alter system set log_archive_dest_state_2=defer;

alter system set log_archive_dest_state_2=enable;

修改环境变量，添加TNS_ADMIN，待下次重启数据库生效。

参考：
Error 12154 received logging on to the standby whenever primary instance startup with srvctl (Doc ID 1943178.1)
RFS Is not coming up on standby Due to ORA-12154 on transport (primary side) (Doc ID 2196182.1)
Troubleshooting – Heartbeat failed to connect to standby (Doc ID 1432367.1)

我申请的vultr主机是单核CPU，15GB的ssd的硬盘，768M内存，每月1TB的流量，对于ss来说已经完成足够，目前有日本，新加坡，美国，德国，荷兰，法国等地的服务器。价格是每月5刀（每小时0.007刀），首次注册，如果用我这个Summer Promo Code，你可以额为获得20刀的费用；或者这个Linking Code，获得10刀的费用。前者的优惠幅度比较大，送你20刀，但是可能过了夏天就没有了，后者送10刀的优惠长期存在。目前已经运行了几个月，运行的非常稳定。除了php-fpm比较吃内存（单个进程40m~50M，有10个进程），其他都还好。

因此写了脚本当free小于50M的时候，自动重启php-fpm进程，当mysqld进程数小于2的时候，重启主机。两个多月下来，没有重启过主机，mysqld只是重启了3次。

另外由于将博客走了https，申请了letsencrypt的证书，每个月用脚本更新一次。更新的时候，先停nginx和php-fpm（其实只要停nginx就可以了。但是由于php-fpm比较吃内存，导致更新证书的时候，有时候需要更新Python packages，而在installing Python packages会因为内存不足而失败。所以我就干脆停了二者）,然后调用certbot-auto renew –quiet 自动进行证书更新。

####################[2016-12-10 02:10:01] OPERATION START ##################################
#
#
Free Memory before stop nginx&php-fpm: 64 MB
Stopping nginx: [  OK  ]
Stopping php-fpm: [  OK  ]
Free Memory after stop nginx&php-fpm: 233 MB
/root/.local/share/letsencrypt/lib/python2.6/site-packages/cryptography/__init__.py:26: DeprecationWarning: Python 2.6 is no longer supported by the Python core team, please upgrade your Python. A future version of cryptography will drop support for Python 2.6
  DeprecationWarning
Starting php-fpm: [  OK  ]
Starting nginx: [  OK  ]
Free Memory after restart nginx&php-fpm: 180 MB
#
#
####################[2016-12-10 02:10:15] OPERATION END ##################################

（1）一个月的osw记录：

（2）vultr官方的后台性能数据：

（3）loader.io网站进行了并发压力测试：
如果响应时间是2秒为可接受时间，那么大概可以承受500个左右的并发。

Unix/Linux中oracle数据库进程采用多进程模式，如我们可以在系统进程列表中看到pmon，smon，dbwr，lgwr，ckpt等oracle系统进程。随着oracle数据库功能增多，进程数量也随之增加，创建进程的开销以及进程上下文切换的开销也越来越大（进程状态切换 switching 是要直接硬件CPU资源），多线程结构中，线程切换在用户空间通过库函数实现，开销不在一个量级。所以，在oracle 12c中，有一个关于多线程的参数：threaded_execution，默认为false。启用的话，将其设置为true。启用之后，有如下变化：

1.进程数变少：
之前：

[oracle@ol6-121-rac2 diag]$ ps -ef |grep ora_
oracle    7562     1  0 14:54 ?        00:00:00 ora_pmon_cdbrac_1
oracle    7564     1  0 14:54 ?        00:00:00 ora_psp0_cdbrac_1
oracle    7567     1  4 14:54 ?        00:00:20 ora_vktm_cdbrac_1
oracle    7571     1  0 14:54 ?        00:00:00 ora_gen0_cdbrac_1
oracle    7573     1  0 14:54 ?        00:00:00 ora_mman_cdbrac_1
oracle    7577     1  0 14:54 ?        00:00:00 ora_diag_cdbrac_1
oracle    7579     1  0 14:54 ?        00:00:00 ora_dbrm_cdbrac_1
oracle    7581     1  0 14:54 ?        00:00:00 ora_ping_cdbrac_1
oracle    7583     1  0 14:54 ?        00:00:00 ora_acms_cdbrac_1
oracle    7585     1  0 14:54 ?        00:00:01 ora_dia0_cdbrac_1
oracle    7587     1  0 14:54 ?        00:00:00 ora_lmon_cdbrac_1
oracle    7589     1  0 14:54 ?        00:00:04 ora_lmd0_cdbrac_1
oracle    7591     1  0 14:54 ?        00:00:03 ora_lms0_cdbrac_1
oracle    7595     1  0 14:54 ?        00:00:00 ora_rms0_cdbrac_1
oracle    7597     1  0 14:54 ?        00:00:00 ora_lmhb_cdbrac_1
oracle    7599     1  0 14:54 ?        00:00:02 ora_lck1_cdbrac_1
oracle    7601     1  0 14:54 ?        00:00:00 ora_dbw0_cdbrac_1
oracle    7603     1  0 14:54 ?        00:00:00 ora_lgwr_cdbrac_1
oracle    7605     1  0 14:54 ?        00:00:00 ora_ckpt_cdbrac_1
oracle    7607     1  0 14:54 ?        00:00:00 ora_smon_cdbrac_1
oracle    7609     1  0 14:54 ?        00:00:00 ora_reco_cdbrac_1
oracle    7611     1  0 14:54 ?        00:00:00 ora_lreg_cdbrac_1
oracle    7613     1  0 14:54 ?        00:00:00 ora_rbal_cdbrac_1
oracle    7615     1  0 14:54 ?        00:00:00 ora_asmb_cdbrac_1
oracle    7617     1  0 14:54 ?        00:00:01 ora_mmon_cdbrac_1
oracle    7621     1  0 14:54 ?        00:00:00 ora_gcr0_cdbrac_1
oracle    7623     1  0 14:54 ?        00:00:00 ora_mmnl_cdbrac_1
oracle    7625     1  0 14:54 ?        00:00:00 ora_d000_cdbrac_1
oracle    7627     1  0 14:54 ?        00:00:00 ora_s000_cdbrac_1
oracle    7629     1  0 14:54 ?        00:00:00 ora_lck0_cdbrac_1
oracle    7634     1  0 14:54 ?        00:00:00 ora_rsmn_cdbrac_1
oracle    7644     1  0 14:54 ?        00:00:00 ora_ppa7_cdbrac_1
oracle    7668     1  0 14:54 ?        00:00:00 ora_mark_cdbrac_1
oracle    8033     1  0 14:55 ?        00:00:00 ora_o000_cdbrac_1
oracle    8038     1  0 14:56 ?        00:00:00 ora_tmon_cdbrac_1
oracle    8040     1  0 14:56 ?        00:00:00 ora_tt00_cdbrac_1
oracle    8042     1  0 14:56 ?        00:00:00 ora_gcr1_cdbrac_1
oracle    8044     1  0 14:56 ?        00:00:00 ora_smco_cdbrac_1
oracle    8046     1  0 14:56 ?        00:00:00 ora_w000_cdbrac_1
oracle    8049     1  0 14:56 ?        00:00:00 ora_gtx0_cdbrac_1
oracle    8054     1  0 14:56 ?        00:00:00 ora_rcbg_cdbrac_1
oracle    8101     1  0 14:56 ?        00:00:00 ora_aqpc_cdbrac_1
oracle    8126     1  3 14:56 ?        00:00:11 ora_p000_cdbrac_1
oracle    8188     1  0 14:56 ?        00:00:00 ora_o001_cdbrac_1
oracle    8247     1  1 14:56 ?        00:00:04 ora_p001_cdbrac_1
oracle    8249     1  0 14:56 ?        00:00:00 ora_p002_cdbrac_1
oracle    8251     1  0 14:56 ?        00:00:00 ora_p003_cdbrac_1
oracle    8302     1  0 14:56 ?        00:00:00 ora_qm02_cdbrac_1
oracle    8304     1  0 14:56 ?        00:00:00 ora_qm05_cdbrac_1
oracle    8306     1  0 14:56 ?        00:00:00 ora_q002_cdbrac_1
oracle    8310     1  0 14:56 ?        00:00:00 ora_q004_cdbrac_1
oracle    8327     1  0 14:56 ?        00:00:00 ora_ppa6_cdbrac_1
oracle    8663     1  1 14:56 ?        00:00:02 ora_cjq0_cdbrac_1
oracle    8708     1  0 14:56 ?        00:00:00 ora_p004_cdbrac_1
oracle    8710     1  0 14:56 ?        00:00:00 ora_p005_cdbrac_1
oracle    9052     1  0 14:58 ?        00:00:00 ora_q003_cdbrac_1
oracle    9118     1  0 14:59 ?        00:00:00 ora_p006_cdbrac_1
oracle    9120     1  0 14:59 ?        00:00:00 ora_p007_cdbrac_1
oracle    9294  7647  0 15:01 pts/0    00:00:00 grep ora_
[oracle@ol6-121-rac2 diag]$

之后：

[oracle@ol6-121-rac1 admin]$ ps -ef |grep ora_
oracle   10514     1  0 14:59 ?        00:00:00 ora_pmon_cdbrac_1
oracle   10516     1  0 14:59 ?        00:00:00 ora_psp0_cdbrac_1
oracle   10548     1  3 14:59 ?        00:00:13 ora_vktm_cdbrac_1
oracle   10552     1  2 14:59 ?        00:00:07 ora_u004_cdbrac_1
oracle   10558     1  7 14:59 ?        00:00:28 ora_u005_cdbrac_1
oracle   10563     1  0 14:59 ?        00:00:00 ora_ping_cdbrac_1
oracle   10569     1  0 14:59 ?        00:00:02 ora_u010_cdbrac_1
oracle   10578     1  0 14:59 ?        00:00:00 ora_dbw0_cdbrac_1
oracle   11244  9828  0 15:05 pts/0    00:00:00 grep ora_
[oracle@ol6-121-rac1 admin]$

2. 必须网络登录，不能本地验证：

[oracle@ol6-121-rac1 admin]$ sqlplus "sys/oracle@CDBRAC as sysdba"

SQL*Plus: Release 12.1.0.1.0 Production on Wed Dec 9 15:04:33 2015

Copyright (c) 1982, 2013, Oracle.  All rights reserved.


Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,
Advanced Analytics and Real Application Testing options

SQL>
SQL>

3. 可以不同实例不同值：

SQL> select instance_name from v$instance;

INSTANCE_NAME
----------------
cdbrac_1

SQL> show parameter thread

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
parallel_threads_per_cpu             integer     2
thread                               integer     0
threaded_execution                   boolean     TRUE
SQL>


SQL> select instance_name from v$instance;

INSTANCE_NAME
----------------
cdbrac_2

SQL> show parameter thread

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
parallel_threads_per_cpu             integer     2
thread                               integer     0
threaded_execution                   boolean     FALSE
SQL>

4. listener相关修改：
当threaded_execution这个字被设置成true后，在listener.ora文件中，需要加上：

DEDICATED_THROUGH_BROKER_[listener-name]=ON。

参考：
http://docs.oracle.com/database/121/REFRN/GUID-7A668A49-9FC5-4245-AD27-10D90E5AE8A8.htm#REFRN10335
http://docs.oracle.com/database/121/CNCPT/process.htm#CNCPT1245

2017年的第一天，因为闰秒的关系，加上时差的原因，我国将在北京时间2017年1月1日的7时59分59秒和全球同步进行闰秒调整，届时会出现7:59:60的特殊现象。(国家授时中心闰秒公告)

那么闰秒对数据库有什么影响？

（一）具体的说：
可以参考：Information Center: Leap Second Information for All Products – Database – Exadata – Middleware – Exalogic – Linux – Sun – Fusion – EBS – JDE – Siebel – Peoplesoft (Doc ID 2019397.2)

这是一篇非常详尽的关于Oracle所有产品，是否受闰秒影响的汇总文档。包括了Sun Microsystems，Linux & VM，Database & EM，Exadata & Exalogic，Fusion Middleware，Applications。

（二）简单的说：

1. 对于RAC系统，NTP闰秒问题可能会导致节点reboot。但以下两种情况将不受影响：
1.1 使用了第三方cluster 软件，如Sun Cluster or Veritas SFRAC 配置。
1.2 使用 Oracle Clusterware 10.2.0.4 及更高的版本(包括 11g、12c 等)。

2. 对于Linux 及Oracle VM，部分应用程序无法处理该非常规“23:59:60”的时间戳，可能会导致应用挂起或主机重启。

3. 对于单节点数据库运行无影响，系统层闰秒调整不会对RDBMS 产生影响。

解决方案：
对于10.2.0.4以下的版本的RAC，导致节点reboot的触发条件必须同时满足如下2个条件：
1. xntpd没有启用slewing
2. oracle的clusterware（10g还没有gi），没有打上fix for bug 5015469 or bug 6022204

因此，推荐的解决方案是避免上面的条件1，启用xntpd的slewing来解决问题：

a). 在linux中修改/etc/sysconfig/ntpd中，修改:
OPTIONS="-u ntp:ntp -p /var/run/ntpd.pid -x"，使用-x参数启动ntp。

b). 在solaris中修改/etc/inet/ntp.conf中，添加:
slewalways yes
disable pll

c). 其他平台，请参考厂家的系统管理手册

修改后重启ntpd服务。

参考：
Information Center: Leap Second Information for All Products – Database – Exadata – Middleware – Exalogic – Linux – Sun – Fusion – EBS – JDE – Siebel – Peoplesoft (Doc ID 2019397.2)
How Leap Second Affects The OS Clock on Linux and Oracle VM (Doc ID 1453523.1)
NTP leap second event causing Oracle Clusterware node reboot (Doc ID 759143.1)

Solaris系统将被停止开发，这个消息，据我所看到的，最初的来源是来自thelayoff网站的消息『Solaris being canned, at least 50% of teams to be RIF’d in short term』

All hands meetings being cancelled on orders from legal to prevent news from spreading.

Hardware teams being told to cease development.

There will be no Solaris 12, final release will be 11.4.

Orders coming straight from Larry.

No info on timing yet.

但是Oracle官方一直没有回应这个消息。

估计很多客户也在求证这个消息，上周，system团队的老大发了个邮件，希望澄清这个事情。

首先，开篇就说了solaris没有死。

然后说Solaris后续的功能更新将基于版本的后面的小数点，而不是大版本。———— 所以……谣言没错，确实没有了solaris 12，只有solaris 11.XX。

然后，说了solaris 11的Premier Support至少会持续到2031年。

最后，说了如果客户需要和硬件团队的领导邮件沟通上述情况，他们会很乐意。

客户一个测试环境，一个主机上面运行了很多数据库，某库的程序会时不时报错ora-4030。

加大了pga，然后还检查了ulimit的 data 和 stack都是ulimit。还是报错。

进而检查/var/adm/messages，发现有报错swap不足的情况。

所以，解决方法是加大物理内存，或者加大swap（文档要求是对于8G以上物理内存，swap的设置是0.7倍物理内存），

参考：『一个奇怪的ora-4030错误的诊断过程』（其实这个文档中的客户和我的客户，是同一个。：））