介绍
目前 Oracle 官方推荐安装19c 的 linux 版本为Linux 7，不过强制安装到CentOS 8上，还是可以用的，接下来就来介绍怎么安装。
安装 Oracle Database 19c
安装Oracle Database 相关依赖
推荐先安装Oracle官方yum仓库，主要是为了通过yum安装 oracle-database-preinstall-19c.x86_64，来帮助我们完成 Oracle Databse 19c 的依赖检查安装。

注意：有时候dnf -y install 可能因为未导入证书或其他原因没能创建成功事务，若没看到：Complete!，再执行一遍dnf -y install …

cd /etc/yum.repos.d/
sudo curl -O http://yum.oracle.com/public-yum-ol7.repo
sudo dnf -y install oracle-database-preinstall-19c.x86_64

安装Oracle依赖的lib库
sudo dnf -y install libnsl

安装Oracle Database
首先导入Oracle 官方的GPG KEY(可不做)
cd /etc/pki/rpm-gpg/
sudo curl -o RPM-GPG-KEY-oracle http://public-yum.oracle.com/RPM-GPG-KEY-oracle-ol7

前置工作都做完了，切换到Oracle安装包的目录，现在是正式安装Oracle Database了。
sudo rpm -ivh oracle-database-ee-19c-1.0-1.x86_64.rpm --nodigest

初始化Oracle Database 19c
创建自己的CDB初始化配置文件
复制一份Oracle样本配置，并打开
sudo cp /etc/init.d/oracledb_ORCLCDB-19c /etc/init.d/oracledb_JRMCDB-19c
sudo vi /etc/init.d/oracledb_JRMCDB-19c

主要是修改环境变量配置，如CDB，PDB等。
export ORACLE_SID=JRMCDB
export PDB_NAME=JRMPDB1

复制配置文件
sudo cp /etc/sysconfig/oracledb_ORCLCDB-19c.conf /etc/sysconfig/oracledb_JRMCDB-19c.conf
sudo vi /etc/sysconfig/oracledb_JRMCDB-19c.conf

因为只有一个Oracle SID实例，不会冲突，所以这里不改端口配置等。
配置并创建Oracle SID实例
sudo /etc/init.d/oracledb_JRMCDB-19c configure

如果看到以下这句话，就安装完成了。

Database configuration completed successfully.

登录并修改Oracle Database管理员账号
修改oracle用户密码
在root账号下，修改oracle用户密码
passwd oracle

切换oracle账号
su - oracle

添加系统环境变量
vi .bash_profile

添加以下内容
export ORACLE_HOME=/opt/oracle/product/19c/dbhome_1
export PATH=$PATH:$ORACLE_HOME/bin
export ORACLE_SID=JRMCDB

加载环境配置
source .bash_profile 

登录oracle修改管理员密码
以数据库管理员登录，需要在orace账号下登录
sqlplus / as sysdba

修改密码
alter user system identified by "123456"; 

创建Oracle账号
切换容器
切换到我们创建的PDB
alter session set container=JRMPDB1;

创建用户
create user jeremy identified by "123456";

授权用户
GRANT CREATE SESSION,CREATE TABLE,CREATE VIEW,CREATE PROCEDURE,CREATE SEQUENCE to jeremy;

Oracle 19c 做为该版本的长期支持板，将会持续发布RU更新。 Oracle在每年的1月，4月，7月和10月每个季度发布一个RU。为了使客户能够在其环境稳定之后即刻获得最新的安全相关修复，将在每年的1月，4月，7月，10月为最近的两个RU提供RUR。
https://www.cndba.cn/cndba/dave/article/4277https://www.cndba.cn/cndba/dave/article/4277
https://www.cndba.cn/cndba/dave/article/4277
Oracle RU 19.8 发布了
https://www.cndba.cn/dave/article/4275https://www.cndba.cn/cndba/dave/article/4277
Oracle 19c 与 11g 在安装上有一个明显的区别，在Oracle 11g中，我们可以将数据库升级到11.2.0.3，11.2.0.4， 也可以在安装的时候直接安装成11.2.0.4。但是在12c 以后的体系中，我们只能通过先安装19c 的基础版，然后通过patch 进行升级。
Oracle 19c 的基础版可以直接从Oracle 官网进行下载，Oracle 对基础版提供开放下载的一个原因，就是基础版是一个bug非常多的版本，正式的商用，需要打RU的补丁，修复这些bug。 https://www.cndba.cn/cndba/dave/article/4277
目前官网可以看到2个版本的19c 基础版信息：19.3和19.5.
https://www.cndba.cn/cndba/dave/article/4277
但是19.5 目前只提供了Solaris平台，对于X86 平台来说，如果使用19c，还是必须先安装19.3 的基础版，然后通过Patch升级到最新的RU 19.8。不过根据RU的发布规则，2020年10月份应该会发布19.9的RU了。 https://www.cndba.cn/cndba/dave/article/4277https://www.cndba.cn/cndba/dave/article/4277
版权声明：本文为博主原创文章，未经博主允许不得转载。

JIRA Software是优秀的敏捷项目工具，协助您追踪问题，集成代码，规划，开发，发布高质量的软件产品。点击下载JIRA Software v8.4最新试用版。
问题归档进入下一级别（数据中心） 
    在最新版中，已经扩展了问题归档功能，现在，如果您在问题> 已存档问题中打开存档问题列表，则可以使用一系列过滤器浏览存档问题。通过这种方式，您可以快速找到所需的问题。您可以通过报告，存档日期或存档来过滤问题。您还可以从存档问题页面轻松导出所有或选定的问题。
    为了能够浏览所有存档问题，您需要Browse Archive 全局权限。但是，您还可以使用浏览项目存档权限，该权限允许您浏览属于特定项目的存档问题。 
     此外，系统管理员可以轻松地将存档的问题导出到CSV文件。  从一开始就提供更好的电子邮件通知 
    在Jira 8.0中，引入了批量电子邮件通知，将所有发生在一起的小事件分组到摘要电子邮件中，只是为了给您的邮箱留出一些喘息空间。现在，在添加了一些改进并允许您选择摘要电子邮件的频率之后，将会将这些通知作为每个人的默认通知。   
这对Jira Service Desk客户通知有何影响？
    客户收到的电子邮件通知他们的请求活动不受Jira电子邮件批处理的影响，并且仍将大约每分钟发送一次。 多用户选择器自定义字段中的过滤器
    为了响应用户请求，现在可以模仿多用户选择器自定义字段以只保留特定的用户集，这是为了防止由于错误输入用户名而向随机用户发送通知，这增加了问题的整体安全性。 
外部链接在新选项卡中打开
    当您每次想要在浏览器的新选项卡中打开添加到Jira问题的外部链接时，都需要右键单击，但是现在不需要了，我们已将此选项设为默认外部链接。但是，如果您希望在同一选项卡中打开所有链接，则可以在YourUserProfile  >配置文件>首选项>外部链接中轻松更改此链接。Jira变得更加容易和清晰
    为了改善Jira的可访问性并满足电机和视觉障碍用户的需求，我们在按钮和消息中修复了颜色对比度，为屏幕阅读器添加了UI元素的标签，并确保您可以添加评论使用键盘快捷键。 
    此外，由于已经升级了AUI版本8.4，提高了表单字段的可读性，更改了表单或焦点样式，并更改了菱形颜色。您可以在下面看到一些更改：
电路板可以使用大量版本
    现在，即使您有大量的开放版本，您的Jira也是安全的，没有电路板坏掉。 批量编辑时间跟踪
    在批量编辑问题时将问题时间跟踪信息添加到问题中，而不使用Jira REST API执行此操作。当您编辑多个问题或使用批量问题转换解决问题（并且时间跟踪在分辨率屏幕上）时，您可以简单地提供原始估计值和剩余估计值。
    这是一个很好的节省时间，因为您不需要通过逐个解决问题来纠正或添加时间估计。 
在您的移动应用中打开链接
    为了帮助您在页面之间导航，您可以直接从链接（例如在电子邮件通知中）转到应用程序。如果您还没有该应用程序，单击该链接将转到Play商店中的应用程序下载页面（仅适用于Android）。只需单击移动网站中显示的open in app按钮。Jira Docker
    在之前的版本已经创建了用于在Docker容器中部署Jira Server和Data Center的官方模板，加入了其他Atlassian应用程序的行列，如Confluence，Bamboo或Bitbucket。尝试使用模板快速旋转Jira实例，或者自己定制Docker部署，这些模板适用于Jira 8.0及更高版本。新支持的数据库
    此版本之后，增加了新的数据库——Oracle 18c和19c。此外，之后还会为Jira数据中心添加对Aurora PostgreSQL的支持，敬请期待！修复：    
JSWSERVER-20188-批量操作后删除或重命名确认按钮的问题。   
JRASERVER-69942-JIRA管理员不可以检查Lucene索引和问题的一致性的问题。    
JRASERVER-69897-不可以创建新的REST API以列出具有范围的问题类型和字段的问题。
    如果您有任何的问题和建议都可以点击相关资料查看最新的jira资源合集了解，或者在评论区留言，大家一起讨论。

	

亲爱滴伙伴们！本萎专家又来了，今天咱来实践19C的GI升级。
前面提到过，Oracle19C替代12C将成为oracle线条接下来这两年的主要工作。本萎大湿所在客户现场后续数据库集成安装都将以19C为标准版本。本篇就19C打最新的GIRU(19.7.0.0.200414)步骤及遇到的问题做总结分享。
●GIRU实施步骤●
补丁升级均采取滚动升级方式进行
0119更新opatch版本
打GIRU(19.7.0.0.200414)所需要的opatch版本为12.2.0.1.19及以上最新版本。建议使用19C版本进行补丁升级，所以我们这次使用的opatch是19C，具体命令如下：
更换GI HOME的opatch版本:
su - grid
cd /oracle/app/19.3.0/grid/
cp /oraclelog/pa/opatch_20200622/p6880880_190000_Linux-x86-64.zip ./
mv OPatch OPatch_20200622
unzip p6880880_190000_Linux-x86-64.zip
chown -R grid:oinstall OPatch
chmod -R 775 OPatch
/oracle/app/19.3.0/grid/OPatch/opatch version
更换DB HOME的opatch版本:
su - oracle
cd  /oracle/app/oracle/product/19.3.0/db
cp /oraclelog/pa/opatch_20200622/p6880880_190000_Linux-x86-64.zip ./
mv OPatch OPatch_20200622
unzip p6880880_190000_Linux-x86-64.zip
/u01/app/oracle/product/12.2.0.1/dbhome_1/OPatch/opatch version
02目录备份
该备份将作为补丁升级出错，rollback也报错时的最后救命稻草。备份app及oraInventory两目录即可。
ps -ef|grep LOCAL=NO|awk '{print $2}'|xargs kill -9
srvctl stop instance -d racdb -n racdb1
su - root
/oracle/app/19.3.0/grid/bin/crsctl stop crs
/oracle/app/19.3.0/grid/bin/crsctl stat res -t
tar -cvf /oraclelog/pa/opatch_20200622/gi_home_`hostname`_20200622.tar /oracle/app
tar -cvf /oraclelog/pa/opatch_20200622/oraInventory_`hostname`_20200622.tar /oracle/app/oraInventory
备份目录为啥要停库停CRS？部分看官们估计会有疑问。这个还得从很早之前一次Oracle11G GI PSU升级说起，当时本萎大湿碰到这样一种情况，在确认当时备份命令运行正常，备份出来的文件大小正常情况下，在不停CRS的情况下备份出来的文件竟然不可用......还好当时值得庆幸的是补丁回滚成功了。。所以这次“惊魂动魄”之后这个备份都“唯经验论”了。
03拉起CRS进行补丁冲突分析
启动crs,不起db
/oracle/app/19.3.0/grid/bin/crsctl start crs
/oracle/app/19.3.0/grid/bin/crsctl stat res -t
tail -100f /oracle/app/grid/diag/crs/*/crs/trace/alert*.log
补丁冲突分析
su - grid
opatch prereq CheckConflictAgainstOHWithDetail –phBaseDir /oraclelog/pa/opatch_20200622/30899722/30869156
opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /oraclelog/pa/opatch_20200622/30899722/30894985
opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /oraclelog/pa/opatch_20200622/30899722/30869304
opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /oraclelog/pa/opatch_20200622/30899722/
opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /oraclelog/pa/opatch_20200622/30899722/30898856
su  - oracle
opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /oraclelog/pa/opatch_20200622/30899722/30869156
opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /oraclelog/pa/opatch_20200622/30899722/30894985
su - root
cd /oraclelog/pa/opatch_20200622/30899722
/oracle/app/19.3.0/grid/OPatch/opatchauto apply /oraclelog/pa/opatch_20200622/30899722 -analyze
预计这里有的看官又有疑问了，为啥启动crs,不起db？升级过程GI会自动把DB及CRS停下来并进行目录升级，这样不是多此一举吗。各位看官应该清楚，繁忙生产库的DB因为并发和繁忙程度是没这么容易停下来的，一般作为老鸟来说，为了最大限度的万无一失，都会手动kill会话及手动做checkpoint，switch logfile让系统在自己眼皮子底下顺利停下来。这样做一来让系统停机可控，二来避免因让系统自动去停DB可能导致的各种各样的问题(如导致打补丁需要很长的时间等)。
冲突分析部分截图：
04实施补丁
su - root
cd /oraclelog/shsnc/opatch_20200622/30899722
/oracle/app/19.3.0/grid/OPatch/opatchauto apply /oraclelog/shsnc/opatch_20200622/30899722
05 数据字典更新并检查
在所有节点补丁实施完成后，拉起实例，开始数据字典更新
su - oracle
cd $ORACLE_HOME/OPatch
./datapatch -verbose
--检查补丁
./opatch lsinventory
sqlplus / as sysdba
set line 300 pages 100
col ACTION_TIME for a30
col DESCRIPTION for a60
select PATCH_ID, FLAGS,ACTION,STATUS,INSTALL_ID,ACTION_TIME,DESCRIPTION   from DBA_REGISTRY_SQLPATCH order by ACTION_TIME;
补丁升级成功截图：
●问题汇总●06 补丁升级失败，报oui-patch.xml文件没有权限
报错截图如下：
从以上截图我们可以看到补丁在DB HOME已经成功应用，但是在GI HOME应用时失败，报/oracle/app/oraInventory/ContentsXML/oui-patch.xml文件权限问题。我们查看文件权限发现问题所在，同组grid用户该文件无写权限
补丁回滚失败后，把之前备份的目录tar回来发现数据库安装之后是没有这个文件的。由此我们可以知道oui-patch.xml是在DB HOME进行补丁升级时派生的。
再次进行补丁升级时，发现oui-patch.xml已生成
紧急给oui-patch.xml赋予664权限(注：只要文件一旦生成，需立即赋权)，补丁升级成功
Warning是告知实例未启动，需要手动启动并运行脚本进行数据字典更新，可忽略。
07补丁升级成功之后，节点1 CRS报错如下
在节点1 CRS alert日志中我们发现节点1会去检查所有节点的这些文件。当发现文件不存在时就报该错。前往各节点查看这些文件，确认在所有节点都不存在。
核实部分截图：
这些jackson开头的jar包均是Jackson工具所属jar包。从当前来看这个应该是Oracle为以后版本新功能准备的，但是当前目录又没有添加对应的jar包，所以报错。通过核查集群及数据库均确认正常的情况下，该报错可忽略。
●总结●
以上2个报错在MOS均查不到详细信息，对于本来就是吃螃蟹的尝新过程，或多或少会遇到各种未知BUG，这个过程我们遇山开路，逢水搭桥，依托自己深厚的撸功，相信自己，总会找到问题导致原因及解决方案。本次分享到此结束，谢谢大家，咱们下回再见。