프로덕션 데이터베이스 데이터를 안전하게 고정

버그가 발생하고 때로는 데이터를 프로덕션에서 수정해야합니다. 대기업 입장에서이 문제를 해결하는 가장 안전한 방법은 무엇입니까? 도움이되는 도구가 있습니까? 이 요구 사항을 추진하는 몇 가지 고려 사항은 다음과 같습니다.

1. 쿼리를 실행 한 사람과 실행 한 내용을 기록해야합니다.
2. 이상적으로는 해당 테이블에 대해 짧은 시간 동안 만 쿼리를 실행할 수있는 권한을 사용자에게 제공해야합니다.
3. 쿼리를 실행하는 것은 명시적인 권한없이 SQL을 오래 실행하고 잠금을 실행하지 못하게하기 위해 약간의 지능이 필요합니다
4. 이 프로세스는 DB에 구애받지 않거나 최소한 DB2, Oracle 및 SQL Server를 이해해야합니다.

우리는 임시 픽스 수정 쿼리가 "잘못된 일"을 수행하는 위험을 줄이고 동시에 프로세스에 일부 보안 / 보증을 추가하려고합니다. 생각이나 아이디어?

프로덕션 데이터베이스를 수동으로 업데이트하지 마십시오.

스크립트를 작성하십시오.

세 번 확인하고 한 사람이 세 번만하는 것이 아니라 여러 사람이 그렇게하도록하십시오.

해당 스크립트에 변경 후 유효성 검사 쿼리를 포함시킵니다.

상황이 허용 될 때마다 변경 후 유효성 검증이 실행 된 후 마지막에 롤백 된 트랜잭션 내에서 전체 변경을 테스트하십시오. 결과에 확신이 있으면 롤백을 커밋으로 변경하십시오.

테스트 데이터베이스에 대해 이러한 스크립트 광고 구역질을 테스트하십시오.

프로덕션 데이터베이스에 대해 스크립트를 실행하기 전에 백업하십시오.

스크립트를 실행하십시오.

변경 후 유효성 검증 스크립트를 사용하여 변경된 데이터를 확인, 유효성 검증 및 삼중 확인하십시오.

어쨌든 육안으로 확인하십시오.

문제가 발생하면 백업을 종료하고 복원하십시오.

모든 것이 정상인지 확인하고 관련 (비즈니스) 관리자로부터 사인 오프 할 때까지 변경된 데이터를 프로덕션 데이터로 진행하지 마십시오.

Marjan Venema의 답변은 기술적으로 유효하며 가능하면 따라야합니다. Alas, Marjan은 이론 가나 관점을 깨끗하게 만드는 것을 좋아 하는 순수 데이터베이스 관리자 의 관점에서 대답합니다 . 실제로 비즈니스 제약으로 인해 깨끗한 방식으로 작업을 수행하지 못하는 경우가 있습니다.

다음과 같은 경우를 상상해보십시오.

1. 소프트웨어 제품에 데이터베이스의 일부 데이터가 일치하지 않는다고 생각되는 것을 감지하면 작동을 멈추게하는 버그가 있습니다.

2. 애플리케이션에서 버그를 잠재적으로 수정할 수있는 모든 개발자는 접근 할 수 없습니다.

3. 이 회사는 현재 시간당 수천 달러를 잃고 있습니다 (예 : $ 6 000, 즉 분당 $ 100).

4. 버그는 여러 테이블에 영향을 미치며 그 중 하나는 거대하며 스키마 자체가 아닌 데이터 자체에만 영향을 미칩니다.

5. 버그를 피하기 위해 데이터를 약간 실험 해보아야합니다.

6. 데이터베이스가 커서 백업을 가져 오거나 복원하는 데 3 시간이 걸립니다.

7. 마지막 전체 백업은 3 주 전에 수행되었습니다. 일일 증분 백업도 있으며 마지막 일일 증분 백업은 14 시간 전에 수행되었습니다.

8. 데이터베이스 백업은 안정적인 것으로 간주됩니다. 최근에 포함해서

9. 14 시간의 데이터 손실은 허용되지 않지만 1 ~ 2 시간의 데이터 손실은

10. 준비 환경은 6 개월 전에 마지막으로 사용되었습니다. 최신 상태가 아닌 것 같습니다. 설정하는 데 몇 시간이 걸릴 수 있습니다.

11. 데이터베이스는 Microsoft SQL Server 2008 Enterprise입니다.

작업을 수행하는 깨끗한 방법은 다음과 같습니다.

1. 준비 환경에서 백업을 복원합니다.

2. 거기서 실험 해

3. 마지막 스크립트를 두 번 확인하십시오.

4. 프로덕션 서버에서 스크립트를 실행하십시오.

첫 번째 단계는 회사에 18,000 달러가 소요됩니다. 세 번째 단계를 완벽하게 수행하면 위험이 매우 낮아 지지만 극심한 압박을 받으면 위험이 훨씬 높아집니다. 스테이징에서 완벽하게 작동하는 스크립트가 생겨 프로덕션 데이터베이스를 망칠 수 있습니다.

대신 다음과 같이 할 수 있습니다.

1. 스냅 샷 생성 (Microsoft SQL Server는이를 지원하며 백업하는 데 1 시간이 걸리는 데이터베이스의 스냅 샷을 되 돌리는 데 몇 초도 걸리지 않습니다. 다른 데이터베이스 제품도 스냅 샷을 지원한다고 생각합니다),

2. 프로덕션 데이터베이스에서 직접 실험하여 문제가 발생하면 스냅 샷으로 되돌립니다.

순수 주의자는 데이터베이스를 깨끗한 방식으로 수정하고 회사의 2 만 달러 이상을 낭비하면서 시간 압력을 가하면 문제를 해결할 위험이 있지만 비즈니스 제약 조건을 고려하는 데이터베이스 관리자는 데이터베이스를 어떤 방식 으로든 수정합니다. 이렇게하면 위험을 최소화하면서 (스냅 샷 덕분에) 신속하게 수행 할 수 있습니다.

결론

나는 순수 주의자이며, 깨끗하지 않은 방식으로 일을하는 것을 싫어합니다. 개발자는 수정 한 코드를 리팩터링하고 리팩터링 할 수없는 어려운 부분에 대해 언급하고 코드베이스를 단위 테스트하고 코드 검토를 수행합니다. 그러나 나는 또한 당신이 깨끗하게 일하고 다음날 해고당하는 상황이나 빠른 해킹을 통해 위험과 재정적 영향을 최소화하는 상황을 고려합니다.

일부 IT 직원이 회사를 위해 수천 달러의 손실을 입히는 동안 청결 을 위해 깨끗하게 일하기 를 원한다면이 IT 직원은 자신의 직업에 대해 깊은 오해를 가지고 있습니다.

프로덕션 데이터베이스 데이터를 안전하게 수정합니다. 대기업 입장에서이 문제를 해결하는 가장 안전한 방법은 무엇입니까? 도움이되는 도구가 있습니까?

그것은이다 나쁜 연습 과 더 많은 데이터 문제와 문제에 대한 초대 문입니다. 이 접근 방식을 " 빠르고 더러워 " 라고 설명하는 문구도 있습니다 .

프로덕션 서버에서 직접 수정 / 업데이트를 계속하는 것은 매우 위험 합니다. 회사 / 재산 ( 법률, 불량 / 더러운 데이터, 사업 손실 등 )에 막대한 비용이 소요될 수 있습니다 .

그러나 버그가있을 것이며 수정해야합니다. 사실상의 산업 표준은에 패치 / (배포 스크립트)를 적용하는 것입니다 준비 (자극 데이터베이스의 최신 복사본으로 사전 프로덕션 환경) 및 데이터 분석 / QA 수정 프로그램을 확인 할 수 있습니다. 문제를 피하려면 동일한 스크립트를 버전 제어 하고 Prod 환경에 적용해야합니다.

이 관련 게시물 -Staging 데이터베이스 우수 사례에 언급 된 우수 사례가 많이 있습니다.

살펴볼 좋은 참조 세트는 다음과 같습니다.

• 프로덕션에 수정 된 버그를 얼마나 빨리 얻을 수 있습니까?
• 소프트웨어 개발 비용 피라미드
• 테스트 및 버그 수정에 얼마나 많은 시간을 할당해야합니까

대부분의 조직에서 라이브 환경의 데이터 업데이트 작업은 항상 소규모 그룹의 사람들이 액세스 권한을 가지고 있으며 일반적으로 DBA와 같은 직책으로 수행되었습니다. 소수의 사람들 만 업데이트를 수행 할 수 있기 때문에 데이터에 익숙해 져서 문제의 위험을 줄일 수는 있습니다.

업데이트 스크립트를 작성하는 사람은 테스트에서 (다른 답변에 따라) 그렇게하고 비 기술자 (시스템을 아는 사람과 고위 권한을 가진 사람)로부터 기능이 '다시'나타나는 것처럼 심각한 사인을받습니다. 자신의 편집증 테스트에 추가. 스크립트와 데이터는 프로덕션에 들어가기 전에 테스트에서 다른 기술자 (종종 내가 언급 한 DBA 역할)에 의해 독립적으로 검증됩니다. 결과는 예상 값과 비교하여 확인됩니다 (모든 시나리오마다 고유하지만 종종 행 수와 같은 것들).

내가 일한 한 회사에서 백업을 수행하는 것은 현실적인 옵션이 아니었지만 업데이트 전에 모든 참조 행을 텍스트 파일에 기록한 다음 업데이트를 참조해야 할 경우 업데이트 후에 다시 참조하십시오. 스크립트와이 데이터는 올바르게 구성된 데이터 변경 로그에 보관됩니다.

모든 비즈니스는 고유하며 일부 데이터를 업데이트 할 때의 위험은 다른 비즈니스보다 훨씬 높습니다.

사람들이 이러한 업데이트를 수행하기 위해 후프를 뛰어 넘을 수있는 프로세스를 가짐으로써 사람들이 이것을 최후의 수단으로 취급하고 싶어하는 문화를 홍보 하고이 물건에 대해 건강한 "더블 체크, 트리플 체크"태도를 창출하기를 바랍니다.

다른 서버에는 존재하지 않는 Prod의 데이터를 수정해야하는 경우가 있습니다. 이것은 버그뿐 아니라 클라이언트가 보낸 파일에서 잘못된 데이터를 가져 오거나 누군가가 시스템을 해킹하여 발생한 문제에서 가져온 데이터 일 수 있습니다. 또는 잘못된 데이터 입력으로 인한 문제로 인한 것입니다. 데이터베이스가 크거나 시간이 중요한 경우 최신 백업을 복원하고 dev에 수정해야 할 시간이 없을 수 있습니다.

첫 번째 방어 (및 Enterprise 데이터베이스가 없어서는 안되는 것)는 감사 테이블입니다. 이를 사용하여 잘못된 데이터 변경을 취소 할 수 있습니다. 또한 감사 된 데이터를 되돌리기 훨씬 전에 스크립트를 작성하여 데이터를 이전 상태로 되돌리고 다른 서버에서 테스트 할 수 있습니다. 그런 다음 유일한 위험은 되돌릴 올바른 레코드를 식별하는 것입니다.

다음으로 프로덕션에서 데이터를 변경하는 모든 스크립트에는 다음이 포함되어야합니다.

이들은 명시 적 트랜잭션이어야하며 TRY Catch 블록이 있어야합니다.

변경 사항을 확인한 후 롤백하는 데 사용할 수있는 테스트 모드가 있어야합니다. 변경 전에 올바른 선택문이 있어야하고 변경이 올바른지 확인하기 위해 변경 후 한 번 실행해야합니다. 스크립트는 처리 된 행 수를 표시해야합니다. 우리는이 사전 설정 중 일부를 템플릿으로 완성하여 조각이 완료되도록합니다. 변경 사항을위한 템플리트는 수정 사항을 작성하는 데 시간을 절약하는 데 도움이됩니다.

변경하거나 업데이트 할 데이터가 많은 경우 각 배치마다 커밋을 사용하여 배치로 실행할 스크립트 작성을 고려하십시오. 백만 개의 레코드를 수정하는 동안 전체 시스템을 잠그고 싶지 않습니다. 수정해야 할 대량의 데이터가있는 경우 dba 또는 성능 조정에 익숙한 사람이 실행 전에 스크립트를 검토하고 가능하면 근무 외 시간 동안 실행해야합니다.

다음으로 프로덕션 환경에서 변경하는 모든 스크립트를 코드 검토하고 소스 제어에 포함시킵니다. 예외없이.

마지막으로 개발자는이 스크립트를 실행하지 않아야합니다. dbas 또는 구성 관리 그룹에서 실행해야합니다. 그 중 어느 것도 가지고 있지 않다면, 기술 책임자 또는 그 이상인 사람들 만이 제품을 실행할 수있는 권리가 있어야합니다. 제품을 실행하는 사람이 적을수록 문제를 쉽게 추적 할 수 있습니다. 스크립트는 간단하게 실행되고 강조 부분이없고 한 번에 한 단계 씩 실행되도록 작성해야합니다. where 절을 강조 표시하는 것을 잊었을 때 사람들이 종종 곤경에 빠지게하는 것은 중요한 일입니다.

프로덕션 데이터베이스를 실행할 때 데이터를 여러 번 업데이트했습니다. 위의 답변에 동의합니다. 이는 표준 운영 절차가 아닙니다.

그것은 비싸다 (우리는 서로의 어깨를 살펴보고 아마도 2 또는 3을 논의 할 것이다)

황금 규칙 : 항상 select / statement를 실행하기 전에 수행 할 작업을 보여주기 위해 select 문을 만듭니다.

팀의 다른 두 사람에 의해 시행되는 황금률!

다시 : MainMa의 대답 ...

소프트웨어 제품에 데이터베이스의 일부 데이터가 일치하지 않는다고 생각되는 것을 감지하면 작동을 멈추게하는 버그가 있습니다.

• "버그"인지 어떻게 알 수 있습니까? 소프트웨어 제품 개발자가 규정 한 규칙에 따라 데이터가 일치하지 않습니다.

애플리케이션에서 버그를 잠재적으로 수정할 수있는 모든 개발자는 접근 할 수 없습니다.

이 회사는 현재 시간당 수천 달러를 잃고 있습니다 (예 : $ 6 000, 즉 분당 $ 100).

• 유능한 개발자가 실수로 실수를 해결하고 데이터베이스를 복원하도록 도와주기 위해 회사 관리에 $ 100 / 분의 손실이 중요하지 않은 것 같습니다.

버그는 여러 테이블에 영향을 미치며 그 중 하나는 거대하며 스키마 자체가 아닌 데이터 자체에만 영향을 미칩니다.

• 모든 데이터베이스 문제는 스키마를 "인식"합니다. 스키마가 설계되는 방식은이 문제를 해결하는 방법을 결정하는 것입니다.

버그를 피하기 위해 데이터를 약간 실험 해보아야합니다.

• 이것이 준비 데이터베이스의 목적입니다. 프로덕션의 전체 온라인 백업을 수행 한 직후 프로덕션 데이터베이스의 "손상된"데이터로 데이터를 다시 채워야 할 수 있습니다.

데이터베이스가 커서 백업을 가져 오거나 복원하는 데 3 시간이 걸립니다.

• 그런 다음 문제를 분석하고 수정 스크립트를 개발하고 개발자 및 기타 DBA와 함께 스크립트를 테스트 및 수정하는 동안 실행할 수 있도록 즉시 시작하는 것이 좋습니다.

마지막 전체 백업은 3 주 전에 수행되었습니다. 일일 증분 백업도 있으며 마지막 일일 증분 백업은 14 시간 전에 수행되었습니다.

• 적어도 매일 전체 온라인 백업이 없습니까? 넌 망했어. 그러나 당신은 아마 그것에 익숙 할 것입니다. 위에서 시작한 전체 백업이 실행 중입니다. 매일 온라인 백업으로 피할 수있는 모든 비용을 1 분마다 관리해야합니다.

데이터베이스 백업은 안정적인 것으로 간주됩니다. 최근에 포함해서

• 우수한! 그런 다음 데이터베이스를 두 번 이상 복원하지 않아도됩니다.

14 시간의 데이터 손실은 허용되지 않지만 1 ~ 2 시간의 데이터 손실은

• 설명한 시나리오에서 모든 베팅이 해제되었습니다. 이것은 "정보 재난 관리"상황입니다. 경영진이이 작업을 수행하는 데있어 좋은 점은 향후 백업 백업 및 복구 절차와 리소스를 사용하여 피할 수있는 비용을 문서화하는 것입니다.

준비 환경은 6 개월 전에 마지막으로 사용되었습니다. 최신 상태가 아닌 것 같습니다. 설정하는 데 몇 시간이 걸릴 수 있습니다.

• 백업 시스템이 온라인 백업 (즉, 백업 중 데이터베이스가 완전히 작동하는 경우)을 지원하는 경우 백업 속도 저하를 피할 수있는 충분한 하드웨어 리소스가있는 경우 추출을 수행하여 준비 데이터베이스를 동시에 다시 채울 수 있습니다.

데이터베이스는 Microsoft SQL Server 2008 Enterprise입니다.

• 이 모든 것을하기는 어렵지만 불가능하지는 않습니다. 행운을 빕니다!