小弟我最近做了几次补丁分析,最开始分析补丁,感觉挺痛苦的,因为补丁数量多,且涉及的知识点非常非常的广,客户的要求又非常高。挺伤不起的。不过随着分析的深入,我慢慢的掌握了一些小方法。也在support网站上找到了一些相关性的文章。现在进步了很多。所
小弟我最近做了几次补丁分析,最开始分析补丁,感觉挺痛苦的,因为补丁数量多,且涉及的知识点非常非常的广,客户的要求又非常高。挺伤不起的。不过随着分析的深入,我慢慢的掌握了一些小方法。也在support网站上找到了一些相关性的文章。现在进步了很多。所以想写篇文章,帮助那些受此困扰的兄弟们。
早在几年前,我的一个客户朋友告诉我一件事情,他们升级数据库到最新版本,结果上线后发现一条SQL运行错误,返回的结果集和以前版本返回的结果集不一致,他们紧急开了SR,申请了新补丁开发,可是这个过程需要一定的时间。最终他们选择了数据库降级处理。这真是一个血的教训。在很多大型的企业,对这种升级之后,都会做一系列的功能测试,但是对于他们这种小企业,就是领导脑门一热,一拍板就升上去了。这就导致了这个血的教训出现。
我们需要换位思考下。对于我们的客户来说,在升级的时候,考虑最多的就是平滑过渡,追求的是稳定与安全。那么我们作为服务商就需要给客户提供安全感,所以补丁分析这事情也就纳入到了议程。
已经修复的问题
我们遇到一般比较严重的问题有以下几种,这样的问题会严重影响到数据库的使用,我们在一开始就需要关注这方面的补丁是否已经修复。当然我们需要考虑一点,比如ASM的某个功能有BUG影响到Instance Crash,但是我们不使用ASM技术,所以这些补丁我们是可以不关注的。这个要求我们需要熟悉我们数据库使用者使用到的功能。
- Instance Crash
- Hang
- Reboot
- Corruption
- leak memory
- SQL wrong Result
针对已经修复的问题,建议参考文档:11.2.0.4 Patch Set – List of Bug Fixes by Problem Type (文档 ID 1562142.1)。同时这个文档还会列出一些已修复的重大问题,如下面列表所示:
13326736* | Dictionary corruption / ORA-959 due to DROP TABLESPACE. This bug is alerted in Note:1390632.1 |
13605839* | ORA-600 [ktbsdp1] ORA-600 [kghfrempty:ds]. Corruption in Rollback with Clusterwide Global Transactions in RAC. This bug is alerted in Note:1527740.1 |
13384397+ | wrong results / OERI:[kkooqb: bsj not used] with star transformation |
13460353+ | Registration of 11.2 database fails against 12.1 CRS stack (required fix for 11g DB with 12c GI) |
13467683+ | Join of temp and permanent tables in RAC might cause corruption of permanent table. Regression by bug 10352368 |
13550185+ | Hang / SGA memory corruption / ORA-7445 [kglic0] when using multiple shared pool subpools |
13645917+ | PMON block recovery loop – instance hang |
13786142+ | Cannot drop/replace trigger in editioning environment |
14398428+ | Sporadic Wrong results from Exadata (duplicate rows) |
14668670+ | Wrong results when execution plan shows nested loop batching |
16299065+ | ORA-1206 in SOURCE database after RMAN duplicate |
14332688P* | Solaris / HP: ORA-29701 raised in ASM i/o path. This bug is alerted in Note:1561271.1 |
13443029P+ | AIX: Excess "work USLA heap" process memory use in 11.2 on AIX |
可以看到这些补丁都是很严重的损坏,包括我们前面说到的corruption、wrong result、Hang等问题。在这个版本已经得到了修复。当然这里列出来的只是大版本的修复的一些严重的补丁。不包含小版本(PSU)修复的严重补丁。
已知缺陷和补丁
已知缺陷和补丁这个可以通过文档11.2.0.4 Patch Set – Availability and Known Issues (文档 ID 1562139.1)查看到,这个里面会列出该版本上的重要缺陷。有些缺陷在最新的PSU已经修复了,也可能没修复的。如下所示:
This section lists alerts and important issues relevant to 11.2.0.4
Bug/Doc | Fixed in PSU/Bundle | Description | Updated |
10194190P+ | Solaris: Process spin and/or ASM and DB crash if RAC instance up for > 248 days | <i>11/Feb/2014</i> |
|
17761775+ | 11.2.0.4.2 | ORA-600 [kclchkblkdma_3] ORA-600 [3020] or ORA-600 [kcbchg1_16] Join of temp and permanent table in RAC might lead to corruption | <i>14/Apr/2014</i> |
17752121+ | 11.2.0.4.2 | ORA-600 [kclchkblkdma_3] ORA-600 [3020] RAC diagnostic/fix to avoid a block being modified in Shared Mode and prevent corruption | <i>14/Apr/2014</i> |
文档1562139.1里面还会列出因为增强或者修复某个功能所造成的新版本一些行为上的变化,这也是我们需要注意的。
This section lists fixes / enhancements in 11.2.0.4 which may cause a notable change in behaviour.
13543207 | Allow Partial Filter push down on UNION ALL View – superseded |
13502700 | OS audit file naming algorithm can be slow |
最后文档还列出了一些严重缺陷或者是一般的问题,让我们去评估在11.2.0.3之上应用这些补丁的风险。
版本选择
这个问题也是让领导很头疼的,首先是大版本选择的问题。例如,是选择11.2.0.3还是选择11.2.0.4,这个我觉得首先得看你升级的时间,假设现在刚刚出11.2.0.4,还没有出任何的PSU,那么我建议你选择11.2.0.3,安装最新版的PSU。即使11.2.0.4包含了11.2.0.3 PSU 7的所有补丁,和2013年10月份的CPU补丁。第二点需要看你对新特性感不感兴趣,Oracle的每一个大版本都会有一些新特性。比如11.2.0.4的新特性有Tracle File Analyzer and Collector等等。11.2.0.3有ACFS anapshot。
大版本选择完了就要选择小版本。比如我们确定了数据库大版本为11.2.0.4后,那么小版本应该选择哪个呢?假设现在是4月份,刚刚出了11.2.0.4 PSU2,我们选择最新出的PSU 2,还是选择上一个版本PSU1呢?这需要我们做一个判断,我们需要去对比11.2.0.4.1和11.2.0.4.2的补丁,如果发现11.2.0.4.2这个版本所修复的功能我不需要,或者修复的关键bug不是很多。那么我建议是选择11.2.0.4.1+选装PSU2的关键补丁。如果11.2.0.4.2这个版本修复的bug众多,而且关键补丁也很多,那么建议直接打到11.2.0.4.2。对于小版本补丁的对比,我建议参考文档11.2.0.4 Patch Set Updates – List of Fixes in each PSU (文档 ID 1611785.1)。这篇文档的好处在于它把PSU1修复的问题和PSU2修复的问题都做了列出。我们可以从文档中看到PSU1只修复了17个补丁,而PSU2修复了多达66个补丁,而且PSU2上面有很多关键问题的修复,例如Buffer cache Management上的修复。解决了几个内存管理引起的ORA-600和ORA-7445错误,可以防止数据库宕机和坏块的出现。所以看完这个文档之后,可以把这些数据拿出来和领导及相关部门反馈,推荐安装PSU2,有理有据。
方法论
到了该结尾的时候了,现在精简一下我的方法。我们需要关注4篇文档。这4篇文档分别帮助我们发现该版本已经修复的问题,该版本还没有修复的问题,各个小版本(PSU)修复的问题清单,及新版本的新特性。通过这4篇文档我们能够给出一个大概的评估,在该版本上面数据库可能会有什么风险,能不能打补丁解决,如果不能,有什么规避措施。最终我们可以整理出一份补丁分析文档出来,交给我们的最终客户,让它去决定是否安装。
11.2.0.4 Patch Set – List of Bug Fixes by Problem Type (文档 ID 1562142.1)
11.2.0.4 Patch Set – Availability and Known Issues (文档 ID 1562139.1)
11.2.0.4 Patch Set Updates – List of Fixes in each PSU (文档 ID 1611785.1)
Oracle Database 11g Release 2 (11.2.0.4) New Features
原文地址:Oracle数据库补丁分析实践, 感谢原作者分享。

산성 속성에는 원자력, 일관성, 분리 및 내구성이 포함되며 데이터베이스 설계의 초석입니다. 1. 원자력은 거래가 완전히 성공적이거나 완전히 실패하도록합니다. 2. 일관성은 거래 전후에 데이터베이스가 일관성을 유지하도록합니다. 3. 격리는 거래가 서로를 방해하지 않도록합니다. 4. 지속성은 거래 제출 후 데이터가 영구적으로 저장되도록합니다.

MySQL은 데이터베이스 관리 시스템 (DBMS) 일뿐 만 아니라 프로그래밍 언어와 밀접한 관련이 있습니다. 1) DBMS로서 MySQL은 데이터를 저장, 구성 및 검색하는 데 사용되며 인덱스 최적화는 쿼리 성능을 향상시킬 수 있습니다. 2) SQL과 같은 ORM 도구를 사용하여 Python에 내장 된 SQL과 프로그래밍 언어를 결합하면 작업을 단순화 할 수 있습니다. 3) 성능 최적화에는 인덱싱, 쿼리, 캐싱, 라이브러리 및 테이블 부서 및 거래 관리가 포함됩니다.

MySQL은 SQL 명령을 사용하여 데이터를 관리합니다. 1. 기본 명령에는 선택, 삽입, 업데이트 및 삭제가 포함됩니다. 2. 고급 사용에는 조인, 하위 쿼리 및 집계 함수가 포함됩니다. 3. 일반적인 오류에는 구문, 논리 및 성능 문제가 포함됩니다. 4. 최적화 팁에는 인덱스 사용, 선택*을 피하고 한계 사용이 포함됩니다.

MySQL은 데이터 저장 및 관리에 적합한 효율적인 관계형 데이터베이스 관리 시스템입니다. 장점에는 고성능 쿼리, 유연한 트랜잭션 처리 및 풍부한 데이터 유형이 포함됩니다. 실제 애플리케이션에서 MySQL은 종종 전자 상거래 플랫폼, 소셜 네트워크 및 컨텐츠 관리 시스템에서 사용되지만 성능 최적화, 데이터 보안 및 확장성에주의를 기울여야합니다.

SQL과 MySQL의 관계는 표준 언어와 특정 구현의 관계입니다. 1.SQL은 관계형 데이터베이스를 관리하고 운영하는 데 사용되는 표준 언어로, 데이터 추가, 삭제, 수정 및 쿼리를 허용합니다. 2.MySQL은 SQL을 운영 언어로 사용하고 효율적인 데이터 저장 및 관리를 제공하는 특정 데이터베이스 관리 시스템입니다.

InnoDB는 Redologs 및 Undologs를 사용하여 데이터 일관성과 신뢰성을 보장합니다. 1. Redologs는 사고 복구 및 거래 지속성을 보장하기 위해 데이터 페이지 수정을 기록합니다. 2. 결점은 원래 데이터 값을 기록하고 트랜잭션 롤백 및 MVCC를 지원합니다.

설명 명령에 대한 주요 메트릭에는 유형, 키, 행 및 추가가 포함됩니다. 1) 유형은 쿼리의 액세스 유형을 반영합니다. 값이 높을수록 Const와 같은 효율이 높아집니다. 2) 키는 사용 된 인덱스를 표시하고 NULL은 인덱스가 없음을 나타냅니다. 3) 행은 스캔 한 행의 수를 추정하여 쿼리 성능에 영향을 미칩니다. 4) Extra는 최적화해야한다는 Filesort 프롬프트 사용과 같은 추가 정보를 제공합니다.

Temporary를 사용하면 MySQL 쿼리에 임시 테이블을 생성해야 할 필요성이 있으며, 이는 별개의, 그룹 비 또는 비 인덱스 열을 사용하여 순서대로 발견됩니다. 인덱스 발생을 피하고 쿼리를 다시 작성하고 쿼리 성능을 향상시킬 수 있습니다. 구체적으로, 설명 출력에 사용되는 경우, MySQL은 쿼리를 처리하기 위해 임시 테이블을 만들어야 함을 의미합니다. 이것은 일반적으로 다음과 같은 경우에 발생합니다. 1) 별개 또는 그룹을 사용할 때 중복 제거 또는 그룹화; 2) OrderBy가 비 인덱스 열이 포함되어있을 때 정렬하십시오. 3) 복잡한 하위 쿼리 또는 조인 작업을 사용하십시오. 최적화 방법은 다음과 같습니다. 1) Orderby 및 GroupB


핫 AI 도구

Undresser.AI Undress
사실적인 누드 사진을 만들기 위한 AI 기반 앱

AI Clothes Remover
사진에서 옷을 제거하는 온라인 AI 도구입니다.

Undress AI Tool
무료로 이미지를 벗다

Clothoff.io
AI 옷 제거제

AI Hentai Generator
AI Hentai를 무료로 생성하십시오.

인기 기사

뜨거운 도구

Dreamweaver Mac版
시각적 웹 개발 도구

에디트플러스 중국어 크랙 버전
작은 크기, 구문 강조, 코드 프롬프트 기능을 지원하지 않음

Atom Editor Mac 버전 다운로드
가장 인기 있는 오픈 소스 편집기

VSCode Windows 64비트 다운로드
Microsoft에서 출시한 강력한 무료 IDE 편집기

SublimeText3 Mac 버전
신 수준의 코드 편집 소프트웨어(SublimeText3)
