Oracle 18.3 : 透过告警日志从安装初始化过程看 18c 的新改变

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介: Oracle Database 18c 已经正式对外发布,第一个公共版本的版本号是 18.3 ,让我们从 18.3 的安装过程来一睹 18c 的改变。

Oracle Database 18c 已经正式对外发布,第一个公共版本的版本号是 18.3 ,让我们从 18.3 的安装过程来一睹 18c 的改变。

image

首先我们看看版本,18c 发布的第一个版本是 18.1.0 :

SQL> select banner_full from v$version;

BANNER_FULL
--------------------------------------------------------------------------------
Oracle Database 18c Enterprise Edition Release 18.0.0.0.0 - Production
Version 18.1.0.0.0

而现在发布的版本,演进到 18.3.0 :

[oracle@sdb0 ]$ sqlplus / as sysdba

SQL*Plus: Release 18.0.0.0.0 - Production on Wed Jul 25 21:18:09 2018
Version 18.3.0.0.0

SQL> select banner_full from v$version;

BANNER_FULL
--------------------------------------------------------------------------------
Oracle Database 18c Enterprise Edition Release 18.0.0.0.0 - Production
Version 18.3.0.0.0

在MOS 上已经更新了产品发布计划,HP-UX 和 AIX 版本将在 8 月份发布:

image

当然我们不要恐惧 Oracle 版本的快速变化,再来看看这个版本路线图,18c 相当于 12.2.0.2 ,而 19c 则相当于 12.2.0.3 ,而 20c 将会是一个全新的版本:

image

整个数据库的安装过程非常流畅,没有遇到任何问题,我选择创建了一个 SID 为 enmo ,包含一个 PDB ,PDB 的名称是 enmotech :

image

完成安装之后,让我们从数据库的告警日志开始,看看 18.3 中带来了什么改变。当然,如果您没有安装过 18.1 ,那么事实上这些就是 18c 的改变。

改变一:详细的补丁信息

在告警日志中,数据库创建完成之后,会输出详细的补丁信息,告知数据库中已经应用的补丁列表,我删节了大部分BUG号,这是一个超长的列表。有同事说:看到修复了这么多BUG,就放心了。(其实 12.2 初始版本也有这个特性)。

注意,这里的 Patch ID 28090523 就是 2018年7月 17日发布的 RU 版本,可以从 MOS 上找到详细的信息:

===========================================================
Dumping current patch information
===========================================================
Patch Id: 28090523
Patch Description: Database Release Update : 18.3.0.0.180717 (28090523)
Patch Apply Time: 2018-07-19T01:39:24+08:00
Bugs Fixed: 9062315,13554903,21547051,21766220,21806121,23003564,23310101,
24489904,24689376,24737581,24925863,25035594,25035599,25287072,25348956,
25634405,25726981,25743479,25824236,25929650,25943740,26226953,26336101,
26423085,26427905,26450454,26476244,26598422,26615291,26646549,26654411,
...
28072130,28098865,28106402,28132287,28169711,28174827,28184554,28188330,
28264172

Patch Id: 28090553
Patch Description: OCW RELEASE UPDATE 18.3.0.0.0 (28090553)
Patch Apply Time: 2018-07-19T01:40:01+08:00
Bugs Fixed: 12816839,18701017,22734786,23698980,23840305,25709124,25724089,
26299684,26313403,26433972,26527054,26586174,26587652,26647619,26827699,
26860285,26882126,26882316,26943660,26996813,27012915,27018734,27032726,
27034318,27040560,27080748,27086406,27092991,27098733,27106915,27114112,
...
27609819,27625010,27625050,27627992,27654039,27657467,27657920,27668379,
27906509,27931506,27935826,27941514,27957892,27978668,27984314,27993298,
28023410,28025398,28032758,28039471,28039953,28045209,28099592,28109698,
28174926,28182503,28204423,28240153

Patch Id: 27923415
Patch Description: OJVM RELEASE UPDATE: 18.3.0.0.180717 (27923415)
Patch Apply Time: 2018-07-19T01:41:38+08:00
Bugs Fixed: 27304131,27461740,27539876,27636900,27642235,27952586

Patch Id: 27908644
Patch Description: UPDATE 18.3 DATABASE CLIENT JDK IN ORACLE HOME TO JDK8U171
Patch Apply Time: 2018-07-19T01:44:11+08:00
Bugs Fixed: 27908644
===========================================================

这个封包,在 MOS 上就是包含以下这几个补丁列表:

Build Date:     July 17, 2018 16:00

Software home of Oracle Database software 
This zip file contains Database  software version: 18.3.0.0.180717 
To use this patch with OEDA, copy this file to OEDA's WorkDir before running OEDA. 
Refer to the Exadata database machine owners guide for information about the Oracle Exadata deployment assistant
Patches installed: 
27923415;OJVM RELEASE UPDATE: 18.3.0.0.180717 (27923415)
28090523;Database Release Update : 18.3.0.0.180717 (28090523)
28090553;OCW RELEASE UPDATE 18.3.0.0.0 (28090553)

整个补丁集合也就是我们今天公开下载到的,4.4 G 的补丁安装包,MOS 上的下载次数是 0 ,我贡献第一个下载:

image

改变二:Redo 日志的 DAX 存储支持

在告警日志中,可以看到如下的信息:

Redo log for group 1, sequence 1 is not located on DAX storage
Redo log for group 3, sequence 12 is not located on DAX storage

也就是数据库检查,Redo 日志没有位于 DAX 存储设备,也就是说,Oracle 支持将 Redo 放置于 Direct Access Storage (DAX) 上,更好的支持 NVRAM 等高速存储设备(这个改进不确认,需要测试验证)。

初始化参数中, _simulate_dax_storage 可以用于模拟 DAX 存储,具体需要测试看:

SQL> select ksppinm,ksppdesc from x$ksppi where ksppinm like '%dax%';

KSPPINM
--------------------------------------------------------------------------------
KSPPDESC
----------------------------------------------------------------------------------
_simulate_dax_storage
Simulate log on DAX storage

同时,在进行网络传输时,增加了 日志网络传输调节 的新特性:
2018-07-25T18:36:51.730072+08:00
.... (PID:14041): Redo network throttle feature is disabled at mount time

强势插播广告:

image

改变三:创建DBaaS 和 SaaS lockdown Profile

在 Oracle 12.2 中引入了安全增强,lockdown profile ,进行了更细粒度的权限控制:

2018-07-25T17:37:46.285748+08:00
create lockdown profile PRIVATE_DBAAS
Completed: create lockdown profile PRIVATE_DBAAS
create lockdown profile SAAS
Completed: create lockdown profile SAAS
create lockdown profile PUBLIC_DBAAS
Completed: create lockdown profile PUBLIC_DBAAS

以下通过一个简单的测试来看看这个特性的基本功能。 首先在CDB下创建一个profile,这个Profile将对全局可用:

SQL> connect / as sysdba
Connected.
SQL> CREATE LOCKDOWN PROFILE enmotech;
Lockdown Profile created.

SQL> ALTER LOCKDOWN PROFILE enmotech DISABLE STATEMENT  = ('ALTER SYSTEM');
Lockdown Profile altered.

连接到PDB YHEM,在PDB级别启用lockdown profile :

SQL> connect sys/oracle@yhem as sysdba
Connected.
SQL> ALTER SYSTEM SET PDB_LOCKDOWN = enmotech;
System altered.

测试一下,可以看到所有的ALTER SYSTEM的操作都被禁用了:

SQL> alter system checkpoint;
alter system checkpoint
*
ERROR at line 1:
ORA-01031: insufficient privileges

SQL> alter system set optimizer_mode = first_rows_1;
alter system set optimizer_mode = first_rows_1
*
ERROR at line 1:
ORA-01031: insufficient privileges

同事我们注意到 APP Container 被初始化:

alter pluggable database application APP$CDB$SYSTEM begin install '1.0'
Completed: alter pluggable database application APP$CDB$SYSTEM begin install '1.0'
alter pluggable database application APP$CDB$SYSTEM end   install '1.0'
Completed: alter pluggable database application APP$CDB$SYSTEM end   install '1.0'

改变四:创建过程中的缺省压缩

在数据库创建过程中,可以看到对于 SYSTEM 、SYSAUX 表空间,启用了所有操作压缩:

alter tablespace system default compress for all operations
Completed: alter tablespace system default compress for all operations
PDB$SEED(2):alter tablespace system default compress for all operations
PDB$SEED(2):Completed: alter tablespace system default compress for all operations
alter tablespace sysaux default compress for all operations
Completed: alter tablespace sysaux default compress for all operations
PDB$SEED(2):alter tablespace sysaux default compress for all operations
PDB$SEED(2):Completed: alter tablespace sysaux default compress for all operations

表压缩是 Oracle 9i 就有的特性,11g 做出了很多增强,OLTP 压缩需要 高级压缩 选件,是一个收费的组件。
所以在数据库创建完成之后,这个压缩被禁用了,当然也一定是基于性能的考虑:

image

但是创建数据库过程中的压缩,是第一次被观察到。

SYSTEM 还有一个特殊之处,被启用了 force logging :

2018-07-25T17:27:48.447861+08:00
alter tablespace system force logging
Completed: alter tablespace system force logging
PDB$SEED(2):alter tablespace system force logging
PDB$SEED(2):Completed: alter tablespace system force logging

改变五:增加详细的环境控制信息

在数据库启动时,能够看到详细的环境控制信息,之前发布的Exadata版本就是通过这些信息控制安装的:

2018-07-25T17:27:16.850169+08:00
Initial number of CPU is 10
Number of processor cores in the system is 10
Number of processor sockets in the system is 10
Capability Type : Network 
capabilities requested : 1 detected : 0 Simulated : 0
Capability Type : Runtime Environment 
capabilities requested : 400000FF detected : 40000000 Simulated : 0
Capability Type : Engineered Systems 
capabilities requested : 3 detected : 0 Simulated : 0

改变六:SCN兼容性版本信息

虽然这不是 18c 才有的,但是因为其重要性,列出在这里:

Database SCN compatibility initialized to 1

目前 18c 采用的是 兼容性版本 1,当然这个参数是动态调整的。
具体参考之前的文章:Oracle SCN 兼容性版本解密

改变七:全数据库缓存

全数据库缓存是 12c 的新特性,之前未注意是否会被缺省启用,在 18.3 的初始按照中,可以看到如下过程,全库缓存被启用,也就是说如果内存足够,Oracle 会尽量将全部数据库内容缓存到内存中去:

Buffer Cache Full DB Caching mode changing from FULL CACHING DISABLED to FULL CACHING ENABLED

我的 Demo 库由于 Cache 设置过低,所以最后全库缓存被禁用:

2018-07-25T17:27:24.364156+08:00
Buffer Cache Full DB Caching mode changing from FULL CACHING ENABLED to FULL CACHING DISABLED 
Full DB Caching disabled: DEFAULT_CACHE_SIZE should be at least 456 MBs bigger than current size.

Oracle 18.3 已至,管中窥豹,让我们一起开始 18c 自治数据库之旅吧。

原文发布时间为:2018-07-26
本文作者:盖国强
本文来自云栖社区合作伙伴“数据和云”,了解相关信息可以关注“数据和云”。

相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
相关文章
|
26天前
|
SQL Oracle 关系型数据库
【赵渝强老师】Oracle的控制文件与归档日志文件
本文介绍了Oracle数据库中的控制文件和归档日志文件。控制文件记录了数据库的物理结构信息,如数据库名、数据文件和联机日志文件的位置等。为了保护数据库,通常会进行控制文件的多路复用。归档日志文件是联机重做日志文件的副本,用于记录数据库的变更历史。文章还提供了相关SQL语句,帮助查看和设置数据库的日志模式。
【赵渝强老师】Oracle的控制文件与归档日志文件
|
26天前
|
Oracle 关系型数据库 数据库
【赵渝强老师】Oracle的参数文件与告警日志文件
本文介绍了Oracle数据库的参数文件和告警日志文件。参数文件分为初始化参数文件(PFile)和服务器端参数文件(SPFile),在数据库启动时读取并分配资源。告警日志文件记录了数据库的重要活动、错误和警告信息,帮助诊断问题。文中还提供了相关视频讲解和示例代码。
|
2月前
|
存储 Oracle 关系型数据库
|
2月前
|
Oracle 关系型数据库 网络安全
Oracle 19c 安装教程学习
Oracle 19c 安装教程学习
64 2
|
26天前
|
SQL Oracle 关系型数据库
【赵渝强老师】Oracle的联机重做日志文件与数据写入过程
在Oracle数据库中,联机重做日志文件记录了数据库的变化,用于实例恢复。每个数据库有多组联机重做日志,每组建议至少有两个成员。通过SQL语句可查看日志文件信息。视频讲解和示意图进一步解释了这一过程。
|
2月前
|
缓存 Linux 编译器
【C++】CentOS环境搭建-安装log4cplus日志组件包及报错解决方案
通过上述步骤,您应该能够在CentOS环境中成功安装并使用log4cplus日志组件。面对任何安装或使用过程中出现的问题,仔细检查错误信息,对照提供的解决方案进行调整,通常都能找到合适的解决之道。log4cplus的强大功能将为您的项目提供灵活、高效的日志管理方案,助力软件开发与维护。
64 0
|
4月前
|
缓存 NoSQL Linux
【Azure Redis 缓存】Windows和Linux系统本地安装Redis, 加载dump.rdb中数据以及通过AOF日志文件追加数据
【Azure Redis 缓存】Windows和Linux系统本地安装Redis, 加载dump.rdb中数据以及通过AOF日志文件追加数据
137 1
【Azure Redis 缓存】Windows和Linux系统本地安装Redis, 加载dump.rdb中数据以及通过AOF日志文件追加数据
|
1月前
|
XML 安全 Java
【日志框架整合】Slf4j、Log4j、Log4j2、Logback配置模板
本文介绍了Java日志框架的基本概念和使用方法,重点讨论了SLF4J、Log4j、Logback和Log4j2之间的关系及其性能对比。SLF4J作为一个日志抽象层,允许开发者使用统一的日志接口,而Log4j、Logback和Log4j2则是具体的日志实现框架。Log4j2在性能上优于Logback,推荐在新项目中使用。文章还详细说明了如何在Spring Boot项目中配置Log4j2和Logback,以及如何使用Lombok简化日志记录。最后,提供了一些日志配置的最佳实践,包括滚动日志、统一日志格式和提高日志性能的方法。
206 30
【日志框架整合】Slf4j、Log4j、Log4j2、Logback配置模板
|
2月前
|
XML JSON Java
Logback 与 log4j2 性能对比:谁才是日志框架的性能王者?
【10月更文挑战第5天】在Java开发中,日志框架是不可或缺的工具,它们帮助我们记录系统运行时的信息、警告和错误,对于开发人员来说至关重要。在众多日志框架中,Logback和log4j2以其卓越的性能和丰富的功能脱颖而出,成为开发者们的首选。本文将深入探讨Logback与log4j2在性能方面的对比,通过详细的分析和实例,帮助大家理解两者之间的性能差异,以便在实际项目中做出更明智的选择。
271 3
|
2月前
|
存储 缓存 关系型数据库
MySQL事务日志-Redo Log工作原理分析
事务的隔离性和原子性分别通过锁和事务日志实现,而持久性则依赖于事务日志中的`Redo Log`。在MySQL中,`Redo Log`确保已提交事务的数据能持久保存,即使系统崩溃也能通过重做日志恢复数据。其工作原理是记录数据在内存中的更改,待事务提交时写入磁盘。此外,`Redo Log`采用简单的物理日志格式和高效的顺序IO,确保快速提交。通过不同的落盘策略,可在性能和安全性之间做出权衡。
1668 14

推荐镜像

更多