내 고객을 위해 나는 때때로 그들이 스스로 만든 문제를 수정하거나 내 제품의 버그가 만든 잘못된 데이터를 수정하기 위해 라이브 데이터베이스에서 작업합니다. Unix 루트 액세스와 마찬가지로 위험합니다. 미리 어떤 교훈을 배워야합니까?
라이브 데이터에서 작업 할 때 가장주의해야 할 일은 무엇입니까?
내 고객을 위해 나는 때때로 그들이 스스로 만든 문제를 수정하거나 내 제품의 버그가 만든 잘못된 데이터를 수정하기 위해 라이브 데이터베이스에서 작업합니다. Unix 루트 액세스와 마찬가지로 위험합니다. 미리 어떤 교훈을 배워야합니까?
라이브 데이터에서 작업 할 때 가장주의해야 할 일은 무엇입니까?
답변:
내가 수년 동안 힘들게 배운 세 가지 ...
첫째, 라이브 데이터에 대해 업데이트 또는 삭제를 수행하는 경우 먼저 사용할 WHERE 절을 사용하여 SELECT 쿼리를 작성합니다. 작동하는지 확인하십시오. 올바른지 확인하십시오. 그런 다음 UPDATE / DELETE 문을 알려진 작업 WHERE 절 앞에 추가합니다.
당신은 갖고 싶지 않다
DELETE FROM Customers
쿼리 분석기에 앉아 WHERE 절을 작성하기를 기다리고 있습니다. 실수로 "실행"을 누르고 방금 Customer 테이블을 종료했습니다. 죄송합니다.
또한 플랫폼에 따라 테이블의 빠르고 더러운 백업을 수행하는 방법을 찾으십시오. SQL Server 2005에서는
SELECT *
INTO CustomerBackup200810032034
FROM Customer
전체 Customer 테이블의 모든 행을 CustomerBackup200810032034라는 새 테이블로 복사합니다. 그런 다음 업데이트를 완료하고 모든 것이 정상인지 확인하면 삭제할 수 있습니다. 최악의 상황이 발생하면 어젯밤의 백업을 디스크 나 테이프에서 복원하는 것보다이 테이블에서 누락 된 데이터를 복원하는 것이 훨씬 쉽습니다.
마지막으로, 삭제하지 않으려는 항목을 제거하는 계단식 삭제에주의하십시오. 변경하기 전에 테이블의 관계와 키 제약 조건을 확인하십시오.
BEGIN TRANSACTION;
이렇게하면 실수 후 롤백 할 수 있습니다.
종종 UPDATE 또는 DELETE를 수행하기 전에 동등한 SELECT를 작성합니다.
BEGIN TRAN t1에 있지 않는 한 업데이트를 수행하지 마십시오. 개발 데이터베이스가 아니고 프로덕션이 아닙니다. 주석 외부에서 COMMIT TRAN t1을 실행하지 마십시오.
--COMMIT TRAN t1
실행하려면 문을 선택하십시오. (분명히 이것은 GUI 쿼리 클라이언트에만 적용됩니다.) 이러한 작업을 수행하면이 작업을 수행하는 것이 제 2의 천성이되고 거의 시간을 잃지 않을 것입니다.
실제로 이것을 입력하는 "업데이트"매크로가 있습니다. 업데이트를 설정하기 위해 항상 이것을 붙여 넣습니다. 삭제 및 삽입을 위해 유사한 것을 만들 수 있습니다.
begin tran t1
update
set
where
rollback tran t1
--commit tran t1
항상 UPDATE 및 DELETE에 적절한 WHERE 절이 있는지 확인하십시오.
내 질문에 답하려면 :
업데이트 문을 작성할 때 순서대로 작성하십시오.
UPDATE [table-name]WHERE [conditions]SET [columns-and-values]변경하려는 값을 말하기 전에 업데이트 할 행을 선택하는 것이 다른 순서로 수행하는 것보다 훨씬 안전합니다. update person set email = 'bob@bob.com'쿼리 창에 앉아 잘못 배치 된 키 입력으로 실행할 준비가되어 테이블의 모든 행을 엉망으로 만들 준비가되어있는 것은 불가능 합니다.
편집 : 다른 사람들이 말했듯이 작성 WHERE하기 전에 삭제 조항을 작성하십시오 DELETE.
예를 들어 다음과 같은 SQL을 만듭니다.
--Update P Set
--Select ID, Name as OldName,
Name='Jones'
From Person P
Where ID = 1000
마지막부터 SQL 선택 및 실행까지 텍스트를 강조 표시합니다. 업데이트하려는 레코드를 가져 오는지 확인한 후 Shift-up을 눌러 Update 문을 강조 표시하고 실행합니다.
별칭을 사용했습니다. 테이블 이름을 명시 적으로 업데이트하지 않습니다. 나는 항상 별칭을 사용합니다.
트랜잭션 및 롤백 / 커밋과 함께이 작업을 수행하면 정말 안전합니다.
라이브 데이터베이스를 조심하는 # 1 방법? 만지지 마십시오. :)
백업은 데이터베이스에 가한 손상을 되돌릴 수 있지만 그 기간 동안 여전히 부정적인 부작용을 일으킬 가능성이 있습니다.
작업중인 스크립트가 아무리 견고하다고 생각하더라도 테스트주기를 통해 실행하십시오. "테스트주기"가 자신의 데이터베이스 인스턴스에 대해 스크립트를 실행하는 것을 의미하더라도 반드시 수행하십시오. 프로덕션 환경보다 로컬 박스에 결함을 도입하는 것이 훨씬 낫습니다.
도움이되는 몇 가지 다른 사항 :
MySQL을 사용하는 경우 안전한 업데이트 활성화
DBA가있는 경우 요청하십시오.
이 3 가지가 심각한 해를 끼치 지 못하도록했습니다.
그게 제가 지금 생각할 수있는 전부입니다. 대담한 구절을 보시면 제 1 위가 무엇인지 알 수 있습니다. ;-)
Oracle 또는이를 지원하는 다른 데이터베이스를 사용하는 경우 COMMIT를 수행하기 전에 변경 사항을 확인하십시오.
레코드를 삭제할 때 where 절을 지정해야합니다.
스크립트로 데이터베이스를 업데이트하는 경우 실수로 실행 / 실행할 경우를 대비하여 스크립트 시작 부분에 중단 점을 한두 개 넣었는지 항상 확인합니다.
읽기 전용 사용자를 만들고 (또는 DBA에게 요청) 해당 사용자 만 사용하여 DB를 확인합니다. 저장 프로 시저 /보기 / 트리거 등의 내용을 볼 수 있도록 스키마에 적절한 권한을 추가합니다. 그러나 그것들을 바꿀 수있는 능력은 없습니다.