大规模升级来了，说说Oracle12cR2的使用体验。一、升级到12cR2的必要性随着2019年2月13日Oracle19c（Oracle12.2.0.3）forExadata的发布，Oracle12cR2系统的数据库版本终于迎来了长期支持版本（最后一个大版本Oracle12c版本），也就是说数据库版本还在Oracle10g/11g系统，是时候考虑升级了。尤其是Oracle11.2.0.4之前的版本，使用dblink的系统一定要升级。事实上，根据Oracle数据库生命周期和版本演进路线，截至2018年12月31日，Oracle11.2已经结束免费延长服务期（FeeWaivedES），部分新遇到的bug补丁将不在普通SR覆盖范围内帐户。下载权限。同时考虑到SCN上限速率算法的改变，12c的升级就变得更加必要了（当然应用没变，或者没有使用dblink）。Oracle每个版本都有很多BUG，但不是因为Oracle数据库软件不好，而是因为Oracle在OLTP领域是绝对的王者，提供了太多方便的功能，所以BUG比较多。所以在每次升级之前，我们都会翻阅修复列表，看看有没有其他人发现并解决的新错误。到目前为止，Oracle12.2系列修复补丁数为2078个：当然这个补丁数还是远低于Oracle11.2系列的27782个：也远低于Oracle10.2系列的26281个（这些补丁不包括Cluster补丁）：这个结果有些出人意料，12cR2上的补丁数量比前两个版本少了一个数量级。一种可能是12cR2的bug少了很多，另一种可能是12cR2还没有迎来大规模升级，而今年是升级到12cR2的最佳时机。2.Oracle12c系统的一些新特性与Oracle11g相比，Oracle12c有3个广受期待的特性：多租户：12cR1最多允许252个租户，12cR2-19c最多允许4098个租户，受控于max_pdbs参数In-MemoryOptionSharding从两年多的案例来看：Sharding功能几乎没有用到。主要原因是：在12.2中，一个SDB只支持一个TableFamily，正常的业务数据库会需要有多个TableFamily；而在Oracle19c这个版本中，增加了MultipleTableFamilies的特性，或许可以很好的使用它。In-MemoryOption之所以没有大规模使用，一方面是因为使用场景，另一方面是维护成本。多租户特性成为了这个版本的亮点。.Multitenant是12c系统最重要的特性，在12.1.0.1版本引入。开创性的是，一个容器数据库（cdb）可以包含多个可插拔数据库（pdb），每个pdb可以有自己独立的参数和资源占用限制，所以这个特性成为了12c版本中最受欢迎的特性。很多企业利用多租户特性，将分散的、占用单一数据库的小应用整合起来，大大减少了机器数量和数据库许可费用，pdb迁移也更加灵活。pdb的使用有几个bug，影响还是蛮大的。其中之一就是pdb在DataGuard的standby端运行一段时间后会“消失”：Bug25576813-V$PDBandSHOWPDBSmaynotdisplaysomePDBsinStandbyDatabaseORORA-65011onPDBOpenORPDBDatafileonStandbywrongGUID(DocID25576813.8)这个bug从17年前就有了一次性补丁，但它还没有完全修复。完整修复只能升级到Oracle18c，或今年到期的19c。之前我一直很好奇，为什么不能在下一个PSU中将一个bugpatch和这个一次性patch一起打包呢？直到2018年，一位名叫oraguy的用户在HackerNews上爆出如下信息：Oracle12.2版本，有近2500万行C代码！（相比之下，最流行的NoSQL数据库Redis最新的5.0.4版本只有2万多行代码，真是又短又精。）oraguy是这样描述一个Oracle数据库程序员的Workflow:Getanewtask:解决一个新的错误。花两周的时间学习大约20个不同的标志（flags），它们以一种非常奇怪的方式制造了这个bug。尝试添加标志，编写几行代码，注意不要产生更多错误。更改已提交给由大约100-200台服务器组成的测试服务器集群，该集群编译代码、构建新的Oracle数据库软件并以分布式方式运行数百万个测试。回家。第二天来上班，继续处理其他bug。测试可能需要20-30小时才能完成。再回家。回来工作，查看集群测试结果。好的一天，大约会有100次失败的测试；在糟糕的一天，大约会有1000次失败的测试。随机选择一些测试并尝试找出您的假设有什么问题。也许您需要考虑10个以上的标志才能真正了解错误的性质。添加更多标志以尝试解决问题。再次提交更改以进行测试。再等20-30小时。来来回回，周而复始，大概明白了这个bug的原因。有一天，在你差点自杀之前，你发现某项测试完全通过了。再写一百个测试，这样下次某个不幸的孩子接触这个项目时，它就不会弄乱你的更改……提交上一轮测试的结果。然后提交审核。审核本身可能还需要2周到2个月的时间。所以继续下一个错误。2周到2个月后，一切就绪，代码最终会合并到master分支。看看上面的10,000到20,000个补丁，其中一些无法合并到主分支（PSU）中是可以理解的。PDB除了用于小库集成之外，还有一个方便之处，就是在机器资源使用不均衡的情况下，可以在不同的CDB之间进行热插拔。但实践证明，同版本之间最好做热插拔，否则可能会出现异常。在12c构建pdb的语法中，新增了一个选项PATH_PREFIX，用于限制某些对象（directoryobjects/oracleXML/createpfile/oraclewallets）只能在特定的目录下。一旦添加了这个目录前缀，它就会伴随pdb一直到生命结束。连datapump都改不了目录，所以添加的时候一定要小心。在Oracle18c中进行pdb迁移时，执行DBMS_PDB.CHECK_PLUG_COMPATIBILITY，可能会报ORA-7445[__intel_ssse3_rep_memcpy()]，这是Bug28502403-ORACLE18.3.0MULTITENANT:COMPATIBILITYCHECKDOESNOTWORK。不过这个bug只出现在18.2和18.3，最新的18c可以绕过这个问题。随着国家网络安全法的实施，企业安全检查更加严格，“定期更换数据库密码”由检查变为严格执行。这对于11gdg的DBA来说是一件极其痛苦的事情。每次修改主库密码，都需要手动将密码文件同步到各个备库实例。如果某个实例不同步，数据就会不同步。向上。12cR2中引入的新功能-密码文件自动同步到DataGuard备用数据库。当SYS、SYSDG等的密码更改时，主数据库中的密码文件会更新，然后更改会传播到配置中的所有备用数据库。结合这个，11gR2引入的一个新参数REDO_TRANSPORT_USER创建一个单独的日志传输授权用户，授予SYSOPER权限，然后封存这个账号。请注意，用户名区分大小写。在最新的Oracle19c中，也引入了很多新特性。我最关心的两个：自动统计信息管理统计信息管理一直是大型企业数据库管理中的难题。SQL语句选择了次优的执行计划（据官网介绍，这是AWS放弃Oracle而选择Aurora的重要原因）。Oracle19c内置专家系统，内置算法将应用程序的SQL历史记录抓取到SQL仓库中，识别出对新SQL有利的候选索引，进行验证、决策、在线验证、监控自动创建索引，如果自动创建的索引在一段时间内不合适会被自动删除。AutomaticIndexCreation自动索引创建功能引入了一个切换视图dba_auto_index_config。鉴于目前只有19c的Exadata版本可用，这两个特性能否在生产中使用还有待评估。3.一些谨慎使用的特性将事务型生产数据库迁移到Oracle12c（包括Oracle12cR2、Oracle18c、Oracle19c），部分特性建议关闭（部分从Oracle10g开始建议关闭），设计比较理想，现实很骨感，我们能做的就是帮助它尽可能地平滑。以下默认数据库都是OracleRAC：1.实例并行执行PARALLEL_FORCE_LOCAL。此参数默认为False。从理论上讲，集群多个节点是最优方案，多个节点协同工作，以平衡并行处理时的受力。事实是多节点并行处理的协调成本非常高，节点之间的通信负载很重。所以应该改为True，实现进程级本地化并发处理。2.自动内存管理从10g开始sga自动管理sga_target到12c内存级别自动管理memory_target。建议把核心生产库全部改成手动，几个月没看的非核心库可以设置成自动管理。3、查询结果缓存一次，百次使用。它可能适用于一些特定的“静态”查询类型的系统，这在OLTP中几乎不存在。所有result_cache_max_size=0。4、Bloomfilter算法BloomFilter由Bloom于1970年提出，用于检索一个对象是否在某个集合中。优点是空间效率高于其他算法，缺点是存在一定的误识别率。一旦发现错误，效率将下降一百倍，这对于一个高效稳定的系统来说是无法接受的。_bloom_filter_enabled=false;_bloom_pruning_enabled=false动态资源重组：每个数据库资源都有自己的master、owner和requester。初衷是根据请求情况动态调整master，减少实例间的数据传输。_gc_policy_time=0；_gc_undo_affinity=false；“_gc_read_mostly_locking”=假。5.新建一个带段延迟的数据表。Oracle只会创建这个对象，暂时不会分配段。只有当第一条数据插入到表中时才会创建段。初衷是为了节省存储空间，但是这个功能有很多bug。deferred_segment_creation=false6.In-MemoryOption是12c的一大亮点，适合特定的应用。通常建议关闭：inmemory_size=0；inmemory_query=禁用；4.若干问题/Bug升级到Oracle12c后遇到的一些重要Bug，建议修复。问题一：SGA手动管理模式下，Oracle自动偷偷增加Sharedpool（Oracle19.2解决）。HittingBug26405036LargeAllocationOf"gesenqueues"and"gesresourcedynamic"InTheSharedPool将自动将共享池的大小从20g调整到200g以上，直到sga_max_size中没有可用空间，应用程序将报告ora-04031。解决方法是打补丁，目前Oracle18.5的补丁已经出：临时解决方法如下：SQL>oradebugsetmypidSQL>oradebuglkdebug-mreconfiglkdebug问题2：大量trace文件或单个大文件在home目录下生成，空间占满，导致系统挂掉。这个问题很相似，但不仅仅是一个错误：原因1：跟踪文件的生成带有消息“AUTOSGA:kmgs_parameter_update_timeoutgen00mmonalive1”。这是Bug25415713，安装一次性补丁即可解决。原因2：使用KRB消息从RMAN模块生成的跟踪文件。可能是：错误28174827：安装修复错误22700845后RMAN无条件KRB跟踪文件错误28390273：补丁24setbtraalter补丁2767438后RMAN无条件KRB跟踪文件已通过*]磁盘禁用，内存禁用';解决了。原因3：KZAN：在CLI写入期间出现ORA-55917。KZAN：SYS用户审计记录现在将被写入文件。需要禁用KTLI跟踪：altersystemsetevent='55901tracenamecontextoff';altersystemsetevent='TRACE[RecordCompose]off';altersystemsetevent='TRACE[FileWrite]off';altersystemsetevent='TRACE[QueueWrite]off';问题三：在RAC集群环境下，truncate一个大表会导致另外一个节点hanglive。dbaplus社区有专门的诊断文章：你敢在Oracle12cR2上做一个大表truncate吗？最新版PSU已修复该bug：问题4：升级到Oracle12c/18c后，低版本数据库客户端连接会报错：ORA-28040:Nomatchingauthenticationprotocol/ORA-01017:invalid用户名密码;logondenied需要先在sqlnet.ora中添加SQLNET.ALLOWED_LOGON_VERSION_CLIENT=8/SQLNET.ALLOWED_LOGON_VERSION_SERVER=8，然后重新设置密码解决。（参考MOS文档ID2296947.1）五、几个重要参数还有一些其他的推荐参数，大部分是为了避免bug，还有一些是为了关闭某些Oracle特性。ASM初始化参数，memory_target设置为2G，process设置为200以上。数据库参数：_serial_direct_read=AUTO；避免高直接路径读取_lm_tickets=5000；默认1000，增加GESmessagingtickets_px_use_large_pool=TRUE；使用大池而不是共享池进行并行会话，减少ora4031_b_tree_bitmap_plans=FALSE；写敏感_gc_defer_time=0；减少热块的进程争用_datafile_write_errors_crash_instance=FALSE；当发现数据文件（除表空间以外的系统）I/O读写错误时，发生错误的数据文件将离线，而不关闭实例。event='10949tracenamecontextforever:28401tracenamecontextforever,level1:10849tracenamecontextforever,level1';关闭用户不断输入错误密码导致大量库缓存锁的数据库；关闭自动串口直接路径读取功能，避免直接路径读取过多，消耗过多IO资源_undo_autotune=FALSE;关闭撤销自动调整_use_adaptive_log_file_sync=FALSE;将日志缓冲区写入文件的默认方法是Post/wait方法，从11.2.0.3版本开始增加了Polling方法。关闭此参数不允许切换。"_fix_control"='14142884:ON','8560951:ON','8893626:OFF','9344709:OFF','9195582:OFF','9380298:ON','13704562:OFF','16053273:OFF','8611462:OFF','17760375:OFF','17938754:OFF','8560951:ON'当然同时需要注意的是，这些只是需要注意的参数，还有实际环境中的其他参数也要注意。如果大家在阅读过程中觉得还有一些参数需要调整，欢迎在文末留言，以供其他同仁参考。六、升级参考文章核心数据库的升级是一项复杂的系统工程，必须经过严密的方案制定、升级测试、性能测试以及最后的割接迁移过程。虽然我们经历了上千个系统的12c升级，但是每次升级前的测试还是会发现新的bug。有的是应用代码，有的是SQL性能，有的是数据库软件，甚至有的是存储链接。充分的测试是成功升级的唯一保证。针对大数据量的升级迁移，Oracle副总裁Swonger发表演讲：不到1天迁移+200TB数据库，讲了欧洲电网的案例，使用TTS+expdp+perl等方式，它值得一看。链接：https://www.neooug.org/gloc/Presentations/2018/Swonger_Migrate_200TB.pdf对于升级，我们不仅要关心升级本身能否按时完成，还要关心性能、稳定性、可用性，数据的一致性和完整性同样重要，正式升级割接前应进行全仿真验证。作者介绍杨志红，dbaplus社区联合创始人，新居网络首席布道师，对数据库和数据管理有深入研究，联合翻译《Oracle核心技术》《Oracle Exadata专家手册》。
