1 / 46

运行 Oracle Solaris 的 SPARC 系统的 10 大数据库 性能 改善技巧

运行 Oracle Solaris 的 SPARC 系统的 10 大数据库 性能 改善技巧. Lawrence McIntosh 和 Roger Bitar 甲骨文公司 系统 事业部 Oracle 优化解决方案 组. 议题. 背景 目的 方法 Oracle 优化解决 方案 涵盖 领域 工具 和技术 要点. 以下内容旨在概述产品的总体发展方向。该内容仅供参考，不可纳入任何合同。本演示不承诺提供任何材料、代码或功能，也不应将其作为购买决策的依据。Oracle 有权自行决定任何产品的特性或功能的开发、发布和时间安排。. 背景.

norris
Download Presentation

运行 Oracle Solaris 的 SPARC 系统的 10 大数据库 性能 改善技巧

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 运行 Oracle Solaris 的 SPARC 系统的 10 大数据库性能改善技巧 Lawrence McIntosh 和 Roger Bitar甲骨文公司系统事业部Oracle 优化解决方案组

  2. 议题 • 背景 • 目的 • 方法 • Oracle 优化解决方案 • 涵盖领域 • 工具和技术 • 要点

  3. 以下内容旨在概述产品的总体发展方向。该内容仅供参考，不可纳入任何合同。本演示不承诺提供任何材料、代码或功能，也不应将其作为购买决策的依据。Oracle 有权自行决定任何产品的特性或功能的开发、发布和时间安排。

  4. 背景 • SPARC 系统和 Oracle Solaris 技术的发展： • SPARC T5 / M5 系统 • MPO、ZFS、区域、OVM、关键线程支持等 • ZFSSA、Exadata 存储、SAN 存储闪存技术 • 基于 Infiniband (IB) 的互联技术 • Oracle SuperCluster • Oracle 优化解决方案 • 性能技巧基于多年来对各种系统和数据库负载的内部性能分析和优化

  5. 目的 • 开发高度优化、平衡的系统 • 突出性能问题鲜为人知的事实 • 讨论诊断性能下降、性能差异等问题的技术 • 重点介绍如何改善运行 Oracle Solaris 的 SPARC 系统上的数据库性能 • 重点探讨实时监视对诊断系统问题的好处 • 鼓励使用 Oracle Solaris 工具关联各种离散事件

  6. 方法 • 性能低于期望、性能差异、性能随时间降低等。 • 采用已知“最佳实践” • 遵循性能优化流程 症状 诊断 优化 • 调优技巧 • 系统分析

  7. 覆盖整个开发周期的优化 从应用到磁盘都经过设计、测试和验证 故障注入测试 识别集成机会 互操作性测试 端到端功能验证 早期开发测试 一个工程团队 整个体系全面优化 性能和可扩展性测试 真实环境负载测试 选型与配置优化 负载/压力测试 补丁回归测试

  8. 可观察性 工具/技术 • 系统性能：Solaris + 平台  • 进程/线程分析：lockstat、plockstat、truss、prstat 和 pstack • 内存分布优化：plgrp、pmap、lgrpinfo  • 中断分配与负载平衡：mpstat、mdb、intrstat • 硬件利用率与容量规划：cpustat、corestat、pgstat、pginfo • 高级调试：Dtrace • 关联不同工具的数据，发现系统问题 • 例如，高 GC 延迟 <-> mpstat 输出 <-> prstat 输出 • 可让我们联想到调度程序问题或中断饱和等

  9. 分析技术 • DTrace • 系统分析：端到端的用户到内核再到用户 • 下钻分析：例如，运行最多的系统调用、是哪些系统调用、什么程序调用的、调用栈细节、调用参数等 • 推理分析 • Proc、Sched 和 IO 的Providers

  10. 涵盖领域 • 整合 • RAC 性能 • 内存分配 • CPU/内存关联 • 通过调度提高响应速度 • I/O 性能 • 系统克隆方法

  11. 整合最佳实践 • 优化共享硬件资源的利用率 • 共享 Oracle 安装，共用ORACLE_HOME • 优化实例资源使用 • 利用 Solaris 资源管理框架 (Oracle 11.2.0.3) • 启用处理器集感知的 lgroup 内存分配 • 考虑通过内核边界，实现最佳的逻辑域配置（T 系列） • Oracle Solaris 11.1 版为数据库整合提供了更好的虚拟化技术（区域中的 RDS V3 支持、IO 虚拟化等） # Configure Resource Pools: psets/Shares set processor_group_name = “PROCESSOR_GROUP_NAME” in init.ora In /etc/system set lgrp_mem_pset_aware = 1

  12. RAC 性能 响应时间长 • 症状： • “集群等待时间”长导致事务响应时间 (AWR) 长 • 诊断： • 监视 LMS 进程(prstat) 的 CPU 利用率 • 监视 CPU 处理网络中断时的 intrstat（需要权限） • 调优： • 在 FX60 中运行 LMS，切勿过量配置 LMS 进程数 • UDP 可调参数 — 遵循网络调优的最佳实践。 # prstat from saturated LMS PID USERNAME USR SYS TRP TFL DFL LCK SLP LAT VCX ICX SCL SIG PROCESS/LWPID 4816 oracle    70  21 0.5 0.0 0.0 0.0 8.1 0.7 10K  6K . 3M   6 oracle/1 # prstat from “good” LMS PID USERNAME USR SYS TRP TFL DFL LCK SLP LAT VCX ICX SCL SIG PROCESS/LWPID 4396 oracle    31  11 0.4 0.0 0.0 0.0  56 1.2 39K  4K 2M   6 oracle/1 In /etc/system set ip:ip_squeue_bind = 0

  13. 内存分配 Oracle Solaris 概念 • Solaris 内存组织（大小） • 支持数据库实例的多个页面大小 • 尝试使用最大可用页面大小来分配 SGA • 根据需要将较小的页面合并成较大的页面 • Solaris 内存组织（布置） • 将 CPU-内存相似性抽象为位置分组 (lgroup) • lgroup 感知的内存分配 • 数据库实例启动时间取决于大页面的可用性

  14. 内存分配 (SGA) 通过加快 SGA 分配缩短数据库启动时间 • 数据库实例启动时间取决于共享内存分配时间 • Oracle Solaris 使用内核线程 (VMTASK) 实现并行分配 • vmtask 的默认最大数量限制为 16 • 在较大的系统上，可通过提高 vmtask 限制来提高并行度 • 例如，在 /etc/system 中添加以下代码行 • 或者使用 mdb 在活跃系统上修改 • 将 vmtask_ntasks_max 设置为可用 CPU 的 10-20% set vmtask_ntasks_max = 0x20 # echo “vmtask_ntasks_max /W 0x20” | /bin/mdb -kw

  15. 内存分配 (SGA) 通过加快 SGA 分配缩短数据库启动时间（续） • vmtask 对 SGA 分配时间的影响

  16. 内存分配 (SGA) 通过加快 SGA 分配缩短数据库启动时间（续） • 不同 SGA 大小的 SGA 分配时间对比

  17. 内存分配 (SGA) 大页面可用性导致数据库启动变慢 • 症状： • 数据库实例启动速度慢 • 诊断： • 多次数据库启动/关闭、对文件系统执行 i/o 以及其他类型的 i/o 等导致内存碎片增加 • 页面合并问题导致页面大小不一 • 使用“ pmap –xs `pgrep –f ora_dbw0` ”监视页面大小 Address Kbytes RSS Anon Locked Pgsz Mode Mapped File 0000000380000000 262144 262144 - 262144 256M rwxsR [ ism shmid=0xd ] 0000000390000000 131072 131072 - 131072 4M rwxsR [ ism shmid=0xd ] 0000000400000000 56623104 56623104 - 56623104 2G rwxsR [ ism shmid=0xe ] 0000001180000000 24 24 - 24 8K rwxsR [ ism shmid=0xf ] Address Kbytes RSS Anon Locked Pgsz Mode Mapped File 0000000380000000 262144 262144 - 262144 256M rwxsR [ ism shmid=0x200005d ] 0000000390000000 131072 131072 - 131072 4M rwxsR [ ism shmid=0x200005d ] 0000000400000000 52428800 52428800 - 52428800 2G rwxsR [ ism shmid=0x200005e ] 0000001080000000 4194304 4194304 - 4194304 256M rwxsR [ ism shmid=0x200005e ] 0000001180000000 24 24 - 24 8K rwxsR [ ism shmid=0x200005f ]

  18. 内存分配 (SGA) 大页面可用性导致数据库启动变慢（续） • 建议技巧： • 将 ZFS 缓存大小限制为可用内存的 20% • 将以下内容添加至 /etc/system（例如，将其设置为 2GB）（需要重启） • 如果经常使用 ZFS，请参阅 ZFS 调优指南获取相关建议 • 考虑将系统重启作为最后的选择 • 下一代数据库可解决其中一些隐患 • 有助于改善实例启动 • 有助于提高数据库可用性 set zfs:zfs_arc_max = 2147483648

  19. 内存分配 (SGA) lgroup 间内存分配不均导致性能差异 • 症状： • OLTP 性能差异达到 5% 至 10% • 同一 Solaris 实例上逐渐启动多个数据库实例 • 诊断： • 使用“pmap –L”监视 lgroup 间的 SGA 分配 # pmap –Ls `pgrep –f ora_dbw0` | egrep “Address|shmid” Address Bytes Pgsz Mode Lgrp Mapped File 0000000380000000 262144K 256M rwxsR 3 [ ism shmid=0x1 ] 0000000390000000 786432K 256M rwxsR 2 [ ism shmid=0x1 ] 00000003C0000000 262144K 256M rwxsR 3 [ ism shmid=0x1 ] 00000003D0000000 262144K 256M rwxsR 4 [ ism shmid=0x1 ] 00000003E0000000 262144K 256M rwxsR 1 [ ism shmid=0x1 ] 00000003F0000000 1048576K 256M rwxsR 3 [ ism shmid=0x1 ] . .

  20. 内存分配 (SGA) lgroup 间内存分配不均（续） # lgrpinfo -cm lgroup 0 (root): CPUs: 0-255 Memory: installed 512G, allocated 256G, free 256G lgroup 1 (leaf): CPUs: 0-63 Memory: installed 128G, allocated 84G, free 44G lgroup 2 (leaf): CPUs: 64-127 Memory: installed 128G, allocated 44G, free 84G lgroup 3 (leaf): CPUs: 128-191 Memory: installed 128G, allocated 63G, free 65G lgroup 4 (leaf): CPUs: 192-255 Memory: installed 128G, allocated 65G, free 63G • 使用“lgrpinfo–cm”监视 lgroup 间的内存分配 • 技巧： • 在数据库启动前和启动后使用 lgrpinfo（Solaris S10U9 及更高版本） • 尽可能隔离数据库实例和/或应用

  21. 内存分配 (SGA/PGA) 大页面不足导致性能差异 • 症状： • OLTP 负载的性能差异达到 5% 至 10% • DSS 并行查询中出现性能差异 • 诊断：使用“pmap –xs”监视页面大小 • PGA 的大页面可用性 • PGA 内存以动态的形式分配/释放 — 大页面数量可能不会始终保持相同 Address Kbytes RSS Anon Locked Pgsz Mode Mapped File 0000000380000000 262144 262144 - 262144 256M rwxsR [ ism shmid=0xd ] 0000000390000000 131072 131072 - 131072 4M rwxsR [ ism shmid=0xd ] 0000000400000000 56623104 56623104 - 56623104 2G rwxsR [ ism shmid=0xe ] 0000001180000000 24 24 - 24 8K rwxsR [ ism shmid=0xf ] Address Kbytes RSS Anon Locked Pgsz Mode Mapped File 0000000380000000 262144 262144 - 262144 256M rwxsR [ ism shmid=0x200005d ] 0000000390000000 131072 131072 - 131072 4M rwxsR [ ism shmid=0x200005d ] 0000000400000000 52428800 52428800 - 52428800 2G rwxsR [ ism shmid=0x200005e ] 0000001080000000 4194304 4194304 - 4194304 256M rwxsR [ ism shmid=0x200005e ] 0000001180000000 24 24 - 24 8K rwxsR [ ism shmid=0x200005f ]

  22. CPU 利用率 负载不平衡导致性能差异 • CPU 利用率不均 • 动态创建/删除处理器集（CPU 联机/脱机） • 应用寿命短暂导致负载不平衡 • 诊断： • 使用 kstat监视平均负载，使用mpstat 进行关联 • 使用 plgrp 监视不均的主 lgroup 分配 • 技巧：通过适当的相似性分组来创建受控环境 # plgrp -a all $$ PID/LWPID HOME AFFINITY 1610/1 1 0-4/none # plgrp -A 2/strong $$ PID/LWPID HOME AFFINITY 1610/1 1 => 2 2/none => 2/strong # plgrp -a all $$ PID/LWPID HOME AFFINITY 1610/1 2 2/strong,0,1,3,4/none # kstat -m lgrp -s "load average" -p 10 lgrp:1:lgrp1:load average 60249 lgrp:2:lgrp2:load average 30075 lgrp:3:lgrp3:load average 50572 lgrp:4:lgrp4:load average 37336

  23. 进程调度 Oracle Solaris 概念 • 调度类型 • TS、FX、RT • 使用 priocntl动态修改（需要权限） • MPO 感知的负载平衡 • 均衡的主 lgroup 分配和 lgroup 感知的调度程序 • CMT 感知的调度 • 关键线程优化（Solaris 11 和 Solaris 10U10 中可用） • 动态提供对共享硬件资源的独占访问 • 通过在 FX 60 上运行关键软件进程/线程实现 • 可观察性 • proc 工具（plgrp、prstat）

  24. 进程调度 响应时间改善 • OLTP 应用可受益于关键线程优化 • 在 FX 60 上运行日志写入和 LMS 进程（需要权限） • 使用 ps –c、prstat -cvmL 监视关键进程 • USR/SYS 列显示CPU 利用率下降 • ICX 列代表非主动的上下文切换次数 # priocntl –c FX -m 60 -p 60 -s `/usr/bin/pgrep -f ora_lgwr` # priocntl –c FX -m 60 -p 60 -s `/usr/bin/pgrep -f ora_lms` # prstat -cvmL      PID USERNAME USR SYS TRP TFL DFL LCK SLP LAT VCX ICX SCL SIG PROCESS/LWPID     1421 oracle   24  28 0.2 0.0 0.0 0.0  44 3.6 81K  4K 86K   0 oracle/1 # prstat -cvmL      PID USERNAME USR SYS TRP TFL DFL LCK SLP LAT VCX ICX SCL SIG PROCESS/LWPID     1421 oracle   22  24 0.2 0.0 0.0 0.0  52 3.0 92K  3K 98K   0 oracle/1

  25. 进程调度 采用FX 调度可缩短响应时间 • 对前台 (OLTP) 和 PQ Slave (DSS) 使用 FX • 通常，使用 FX 相比TS有多达 5% 的改善 • 对于运行混合负载（OLTP、DSS、批处理等）的系统，请谨慎使用

  26. 日志文件同步 响应时间长 • 症状： • OLTP 事务响应速度慢 • 吞吐量未随负载的增加而一同增加（尽管在空闲 CPU 状态下） • 主要等待事件 (AWR) 中出现“日志文件同步” • “日志文件并行写入”不一定过高 (AWR) • 诊断： • 监视 lgwr 进程的 CPU 利用率 (prstat ) • 监视 lgwr 进程 %sys 时间较长的情况 (prstat) • 监视 lgwr 进程调度延迟较长的情况 (prstat)

  27. 日志文件同步 响应时间长（续） • 调优： • 减少信号竞争 • 将每个信号集的处理器数量 (process.max-sem-nsems) 减至 64 • 使用 projadd/projmod 在 /etc/project 中添加条目或者使用 prctl 进行动态更改 • 大幅提高 lgwr 效率，从而缩短“日志文件同步”时间 • 总吞吐量通常可提高 10% # projadd -U oracle -K "process.max-sem-nsems=(priv,64,deny)" user.oracle # projmod –a -K "process.max-sem-nsems=(priv,64,deny)" user.oracle # prctl -n process.max-sem-nsems -r -v 64 -i process <PID>

  28. 日志文件同步 响应时间长（续） • 调优： • 提高 LGWR 效率，缩短调度延迟 • 在 FX60 中运行 LGWR • 提供LGWR 对共享硬件资源的独占访问 • 考虑一些运行时场景，例如，多个数据库实例、运用技巧前实例的可用内核/CPU # priocntl –c FX -m 60 -p 60 -s `/usr/bin/pgrep -f ora_lgwr` # #Create Processor Set # psrset –c 56-63 # #Turn off all but one CPU in the processor set # psradm –f 57-63 # #Bind the lgwr to the processor set # psrset –b 1 `pgrep –f ora_lgwr` # #Mark the CPU as non-interruptible # psrset –f 56

  29. 日志文件同步 响应时间长（续） • 配置 CPU 数量和日志设备等参数可大大缩短日志文件同步时间 • 对数据执行 prstat 命令（lgwr 位于默认的TS 调度类中） • 将 lgwr 移至 FX60 后对数据执行 prstat 命令 • lgwr CPU 利用率降低 >10% • “日志文件同步”时间缩短 >10% # prstat -cvmL      PID USERNAME USR SYS TRP TFL DFL LCK SLP LAT VCX ICX SCL SIG PROCESS/LWPID     1421 oracle   24  28 0.2 0.0 0.0 0.0  44 3.6 81K  4K 86K   0 oracle/1 # prstat -cvmL      PID USERNAME USR SYS TRP TFL DFL LCK SLP LAT VCX ICX SCL SIG PROCESS/LWPID     1421 oracle   22  24 0.2 0.0 0.0 0.0  52 3.0 92K  3K 98K   0 oracle/1

  30. I/O 性能 I/O 响应时间长 • 症状： • OLTP 事务响应速度慢 • 主要等待事件 (AWR) 中出现“数据库文件顺序/并行读取” • 诊断： • 监视intrstat了解 CPU 对I/O 中断的处理情况 （需要权限） • 监视mpstat了解中断 CPU 饱和 # intrstat –c 15 5 # #intrstat,mpstat outputs       device |     cpu15 %tim------------- +---------------------       qlc#1 |    33644 70.5 CPU minf mjf  xcal  intr ithr   csw icsw  migr smtx srw syscl usr sys wt idl    15    0   0 97386 33451 33244 1421  471    0 8434   0     0   0  96  0   4 # #intrstat,mpstat outputs      device |    cpu2 %tim     cpu15 %tim-------------+---------------------------------------------       qlc#1 |         0  0.0     34793 40.9       qlc#5 |     34259 40.7        0  0.0 CPU minf mjf  xcal  intr ithr   csw icsw  migr smtx srw syscl usr sys wt idl 2    0   0 48854 34999 34135  2217   41  310 2918   0  1081   2  69  0  29 15    0   0 48668 35057 34716   147    0    4 2595   0    10   0  66  0  34

  31. I/O 性能 I/O 响应时间长（续） • 技巧： • 考虑使用处理器集隔离中断 CPU • 下一代数据库改善了 I/O 性能可诊断性 • Dtrace 与数据库监视框架紧密集成 • 添加新的 V$ 视图来报告 I/O 响应时间详情 # #intrstat,mpstat outputs       device |     cpu9 %tim------------- +---------------------       qlc#5 |    22862 52.6 CPU minf mjf  xcal  intr ithr   csw icsw  migr smtx srw syscl usr sys wt idl   9    0   0 29881 24613 22324  7017  163  2856 164   0  3302   3  89  0   8 # #intrstat,mpstat outputs after processor set       device |     cpu9 %tim------------- +---------------------        qlc#5 |    24230 53.3 CPU minf mjf  xcal  Intr ithr  csw icsw  migr smtx srw syscl usr sys wt idl   9    0   0 29602 23884 23633    48   10     0 3327   0     0    0  80  0 20

  32. I/O 性能 I/O 响应时间长（续） • 确保根据最佳实践安装了 HBA • 技巧： • 确保 I/O 分布在所有可用控制器/通道/端口上 • 考虑启用 MPXIO（针对 SAN 的情况）来缩短响应时间 • 使用 stmsboot(1M) 或者修改 /kernel/drv/fp.conf （针对光纤通道开发） • “mpathadm list lu”命令显示各个 Lun 的总操作路径： # mpathadm list lu         snip        /dev/rdsk/c0t000B080012004133d0s2                 Total Path Count:8                 Operational Path Count: 8 snip

  33. 说明 快照“处于负载下”的时间为 15 分钟：但缓冲区等待的时间达到 9.5 小时！ 提交时间 77 分钟 使用闪存缓存之前 • 此处有何瓶颈？ Top 5 Timed Foreground Events                     Avg %Total ~~~~~~~~~~~~~~~~~~                                 wait Call Event                           Waits    Time (s) (ms)   Time Wait Class ---------------------------- ---------- --------- ------ ---- --------- db file sequential read       3,189,229    34,272   11   67.8 User I/O CPU time                                   11,332        22.4 log file sync 2,247,374    4,612    2   9.1 Commit gc cr grant 2-way 1,365,247    793 1    1.6 Cluster enq: TX – index contention    140,257     720    5   3.1 Concurrenc           -------------------------------------------------------------

  34. 充当二级 SGA 将物理读取 I/O 改为逻辑 I/O 大小调整规则：2 – 10倍SGA 大小 加快处理读取密集型负载 缓冲区缓存 缓冲区缓存 11gR2 数据库智能闪存缓存 大量 I/O 数据库智能闪存 缓存 少量 I/O 存储 存储

  35. 将闪存模块聚集到池中 首选 ASM 串联。无镜像 — 它是缓存！ 设置两个 init.ora 参数 db_flash_cache_file = <+flashdg/FlashCacheFile> 到闪存文件/原始聚合/元设备的路径 db_flash_cache_size = <flash pool size> 二级缓冲区缓存大小：要使用的闪存量 数据库智能闪存缓存设置

  36. 结果：“数据库文件顺序读取”等待时间缩短至原来的1/140！结果：“数据库文件顺序读取”等待时间缩短至原来的1/140！ 平均闪存缓存读取时间从 10.75ms 缩短至 540us：提速 20 倍。 事务和提交率也提高了 40% 以上！ 使用闪存缓存之后 Top 5 Timed Foreground Events                     Avg %Total ~~~~~~~~~~~~~~~~~~                                 wait Call Event                           Waits    Time (s)  (ms)  Time Wait Class ---------------------------- ---------- --------- ------ ---- --------- CPU time                                   11,353        57.6 log file sync        1,434,247     6,587    3   33.4 Commit flash cache single block read 4,221,599     2,284    1   21.3 User I/O Buffer busy waits 723,807   1,502 329    3.3 Concurrenc db file sequential read       22,727     182   8  .9 User I/O           -------------------------------------------------------------

  37. 大多数 OLTP 数据库都有这一等待事件 阵列中的 HDD 替换为闪存之后，存储响应速度至少提高20 倍。 得益于更短的延迟 I/O 绑定时，SLA 通常可改善 2 倍。 有时可提升 5 倍甚至更高。 “数据库文件顺序读取”概要

  38. 如何通过克隆改进数据库生命周期管理 我们将采用一种系统方法来提高性能 • 应用开发和测试 • 无需停机即可更新基础设施 • 故障排除

  39. 克隆共享存储上的 Oracle 数据库和虚拟机 开发/测试系统 生产系统 Z1 Z2 Z4 Z5 Z3 Oracle ZFS 存储设备 数据文件存储在 ASM 中 RMAN 备份 数据文件：仅将更新内容写入存储

  40. 数据库克隆的好处Oracle 提供的克隆 Oracle 数据库的方法 数分钟即可将运行时区域克隆到若干个相同的区域中，并在完成后运行所有区域和数据库 可支持无限数量的克隆。 克隆占用空间极少，仅将更新内容写入磁盘 不影响生产数据库性能

  41. 总结：我们刚讨论过的内容 • Oracle 优化解决方案 • Solaris 性能工具 • 利用虚拟化和 Solaris/Oracle 数据库资源管理 • 使用共享 Oracle 安装，实现数据库整合 • 通过增加“vmtask”来缩短数据库启动时间 • 通过限制 ZFS ARC 来提高大页面可用性和缩短数据库启动时间 • 在一个受控环境中隔离数据库实例，实现可复制的性能提升 • 使用 FX 调度类最大限度减小性能差异 • 通过一些可行的调优来缩短日志文件同步时间 • 隔离中断 CPU 并启用 MPXIO 来提高 I/O 性能 • 通过克隆来改进数据库生命周期管理并快速完成操作系统和数据库设置

  42. 要点 • 性能优化是一个迭代过程 • “未测定项无法改进” • 持续增强 Solaris 可观察性框架 • 通过增强可观察性来提高可诊断性 • 症状出现在多个地方 • 可通过各种工具和技术完成系统级调优 • 通过 Solaris 调优实现稳定的性能 • 力争创建平衡的系统 • 考虑所有要素，打造一个全面的解决方案

  43. 参考资料 • 如何通过灵活的虚拟化服务整合、优化和部署 Oracle 数据库环境 • 如何通过快速克隆生产数据库和工作环境加快测试和开发速度 • 在 Oracle Solaris 平台上部署 Oracle 数据库 • Solaris 动态跟踪指南

More Related