MS SQL Server 누적 업데이트-모범 사례

SQL Server 누적 업데이트에 대한 권장 모범 사례가 무엇인지에 대한 아이디어를 얻으려고합니다 .

현재, 우리는 "CU에 의해 해결 된 문제가 우리가 경험하는 문제가 아니라면 아무것도하지 마십시오"라는 아이디어를 실행합니다. "파산하지 않으면 해결하지 마십시오"접근 방식에서 작동하지만 많은 CU가 성능을 향상 시키므로 이것이 실제로 좋은 아이디어인지 궁금합니다. CU가 릴리스 된 후 한 달 또는 두 달 동안 정기적 인 유지 관리주기 동안 적용된 패치에 CU를 추가하는 것을 고려하고 있습니다.

다른 사람들은 무엇을하고 왜?

2016 년 3 월 24 일, 아래 답변에 영향을 미치는 질문에 대한 업데이트로 Microsoft SQL Server 팀은 서비스 모델 을 업데이트 한다고 발표했습니다 . 2016 년 1 월 이후에 릴리스 된 모든 CU를 모든 사용자가 설치하는 것이 좋습니다.

1 월 CU 릴리스부터 이러한주의 메시지가 업데이트되었으므로 CU를 사용할 수있게되면 지속적으로 사전 설치하는 것이 좋습니다. SP (서비스 팩)를 릴리스 할 때와 동일한 수준의 신뢰도로 CU를 설치해야합니다. CU가 SP 수준으로 인증되고 테스트 되었기 때문입니다. 또한 Microsoft CSS 데이터에 따르면 상당수의 고객 문제가 이전에 릴리스 된 CU에서 해결되었지만 사전에 적용되지 않았 음을 나타냅니다. 또한 CU에는 핫픽스 이상의 부가 가치가 포함되어 있습니다. 여기에는 전반적인 경험을 향상시키는 지원 가능성, 로깅 및 안정성 업데이트가 포함될 수 있습니다.

메시징 및 안내 업데이트 외에도 CU 획득 모델이 업데이트되었습니다.

획득 변경 :

• CU는 물론 "핫픽스"서버 ( 'QFE'또는 '핫픽스'와 관련된 "주의 언어"와 함께 제공됨)에서 전통적으로 제공되었습니다. 여기서 불일치는 CU가 더 이상 간단한 빠른 핫픽스가 아니라는 것입니다. 포함 된 업데이트는 오늘날 전체 시스템 통합 수준뿐만 아니라 개별적으로 잘 테스트됩니다.
• 따라서 현재 서비스 팩과 마찬가지로 microsoft.com/downloads에서 주류 지원 기준 (2012 SP2 / SP3 및 2014 RTM / SP1) 당 최신 CU를 배치하고 있습니다.
• 또한 곧 모든 CU를 Windows Update 카탈로그에 릴리스 및 유지 관리하여 수집 및 배포를 용이하게 할 것입니다.
• 임시 CU '온 디맨드'픽스 만 앞으로 핫픽스 서버에 배치됩니다.
• 마찰을 줄이기 위해 microsoft.com/downloads에서 CU를 다운로드하면 전자 메일 및 URL을 제공 / 수신 할 필요가 없습니다.
• 또한 현재 서비스 팩과 마찬가지로 최신 CU를 Microsoft Update의 선택적 업데이트로 제공하고 있습니다.

나는 가장 최근의 누적 업데이트를 최신 상태로 유지하는 것을 옹호합니다. 그러나 테스트 / QA주기가 완전하고 적절한 회귀 테스트를 보장 할 수있는 경우에만 가능합니다. 글렌 베리 SQLskills은 또한 이 방법의 제안자 .

Microsoft 자체 권장 사항은 최근 해당 입장 을 완화 했지만 귀하에게 영향을 미치는 문제를 해결하는 CU 만 적용 하는 것 입니다. 문제는 이러한 문제 중 하나 이상에 영향을 받아 알지 못하거나 아직 적중하지 않아도 내일 영향을받을 수 있다는 것입니다. 브랜치의 모든 단일 CU에서 모든 단일 수정 뒤에있는 문제를 재현하려고합니까? 여전히 영향을받지 않도록이 작업을 지속적으로 수행 하시겠습니까?

나는 매우 정직 할 것입니다. CU를 인스턴스에 적용하는 데 아무런 문제가 없었습니다. 실제로 CU 릴리스 프로세스는 서비스 팩 릴리스주기보다 훨씬 안정적이며, 대부분의 경우 ( 가장 최근 SQL Server 2012 서비스 팩 2 포함 ) 서비스 팩을 처음까지 적용하고 싶지 않습니다. 해당 지점의 CU가 어쨌든 릴리스되었습니다. 이 경우 서비스 팩 코드를 작성하기 위해 정시에 해결되지 않은 문제를 해결하기위한 임시 핫픽스가 있지만 항상 그런 것은 아닙니다.

우리는 CU를 따라 잡았습니다. 출시 후 약 1 개월 후에 수정 된 문제가 있는지 여부에 관계없이 적용합니다.

그러나 우리가 큰 문제에 부딪힌 후에 우리는이 관행을 멈췄습니다. 우리의 경우 서비스 팩을 설치하여 발생한 전체 텍스트 인덱싱 관련 문제를 해결했습니다. 몇 달 후 CU 중 하나 가 특정 수정 사항을 롤백했습니다 . 이로 인해 우리에게 모든 종류의 문제가 발생하여 어떤 일이 발생했는지 파악하기 위해 많은 연구가 필요했습니다. 우리는 새로운 CU가 다른 것을 깨 뜨렸을 때 나중에 문제를 일으킨 작업을 코딩했습니다. 결과 : 서버는 처음부터 특정 SP / CU 수준까지 서버를 다시 설치하고 고정했습니다.

우리의 응용 프로그램 성능은 새로운 SQL 성능 향상에 관심이 없기 때문에 문제가되지 않습니다. 또한보고 및 기타 쿼리는 유효한 결과를 지속적으로 철회하므로 새로운 조정이 필요하지 않습니다. 이는 현재 CU 적용을 고려하기 전에 보안 문제 여야한다는 것을 의미합니다.

본인은 Aaron과 완전히 동의 합니다. 테스트 / QA주기에서 올바르게 테스트 할 수있는 경우에만이 작업을 수행하십시오 . 그럼에도 불구하고 실제 데이터로 모든 작은 부분을 테스트하여 그들이 의존하고있는 것을 깨뜨리지 않았는지 확인하십시오.