라이브 데이터베이스를 조심하는 # 1 방법은 무엇입니까?

라이브 데이터베이스를 조심하는 # 1 방법은 무엇입니까?

---

내 고객을 위해 나는 때때로 그들이 스스로 만든 문제를 수정하거나 내 제품의 버그가 만든 잘못된 데이터를 수정하기 위해 라이브 데이터베이스에서 작업합니다. Unix 루트 액세스와 마찬가지로 위험합니다. 미리 어떤 교훈을 배워야합니까?

라이브 데이터에서 작업 할 때 가장주의해야 할 일은 무엇입니까?

---

내가 수년 동안 힘들게 배운 세 가지 ...

첫째, 라이브 데이터를 업데이트하거나 삭제하는 경우 먼저 사용할 WHERE 절을 사용하여 SELECT 쿼리를 작성합니다. 작동하는지 확인하십시오. 올바른지 확인하십시오. 그런 다음 UPDATE / DELETE 문을 알려진 작업 WHERE 절 앞에 추가합니다.

당신은 갖고 싶지 않다

DELETE FROM Customers

쿼리 분석기에 앉아 WHERE 절을 작성하기를 기다리고 있습니다. 실수로 "실행"을 누르고 방금 Customer 테이블을 종료했습니다. 죄송합니다.

또한 플랫폼에 따라 테이블의 빠르고 더러운 백업을 수행하는 방법을 찾으십시오. SQL Server 2005에서는

SELECT *
INTO CustomerBackup200810032034
FROM Customer

전체 Customer 테이블의 모든 행을 CustomerBackup200810032034라는 새 테이블로 복사합니다. 그런 다음 업데이트를 완료하고 모든 것이 정상인지 확인하면 삭제할 수 있습니다. 최악의 상황이 발생하면 어젯밤의 백업을 디스크 나 테이프에서 복원하는 것보다이 테이블에서 누락 된 데이터를 복원하는 것이 훨씬 쉽습니다.

마지막으로, 삭제하려고하지 않은 항목을 제거하는 계단식 삭제에주의하십시오. 수정하기 전에 테이블의 관계와 키 제약 조건을 확인하십시오.

---

BEGIN TRANSACTION;

이렇게하면 실수 후 롤백 할 수 있습니다.

---

먼저 백업을 수행하십시오. 어쨌든 시스템 관리의 제 1 법칙이어야합니다.

편집 : 다른 사람들이 말한 것을 통합하여 업데이트에 적절한 WHERE 절이 있는지 확인하십시오.

이상적으로는 라이브 데이터베이스 변경이 발생해서는 안됩니다 (INSERT 및 기본 유지 관리 외에). 라이브 DB의 구조를 변경하는 것은 특히 잠재적 인 업장으로 가득 차 있습니다.

---

사본을 변경하고 만족 스러우면 수정 사항을 적용하십시오.

---

종종 UPDATE 또는 DELETE를 수행하기 전에 동등한 SELECT를 작성합니다.

---

BEGIN TRAN t1에 있지 않는 한 업데이트를 수행하지 마십시오. 개발 데이터베이스가 아니고 프로덕션이 아닙니다. 주석 외부에서 COMMIT TRAN t1을 실행하지 마십시오.

--COMMIT TRAN t1

실행하려면 문을 선택하십시오. (분명히 이것은 GUI 쿼리 클라이언트에만 적용됩니다.) 이러한 작업을 수행하면 두 번째 특성이되어 거의 시간을 잃지 않을 것입니다.

실제로 이것을 입력하는 "업데이트"매크로가 있습니다. 업데이트를 설정하기 위해 항상 이것을 붙여 넣습니다. 삭제 및 삽입을 위해 유사한 것을 만들 수 있습니다.

begin tran t1
update 
set 
where 
rollback tran t1
--commit tran t1

---

항상 UPDATE 및 DELETE에 적절한 WHERE 절이 있는지 확인하십시오.

---

내 질문에 답하려면 :

업데이트 문을 작성할 때 순서대로 작성하십시오.

1. 쓰다 UPDATE [table-name]
2. 쓰다 WHERE [conditions]
3. 돌아가서 쓰기 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. 업데이트를 수행하는 모든 설명을 확인하고 다시 확인하고 다시 확인하십시오. 간단한 단일 열 업데이트를 수행한다고 생각하더라도 조만간 커피가 충분하지 않고 'where'절을 잊어 버리고 전체 테이블을 누를 수 있습니다.

도움이되는 몇 가지 다른 사항 :

• MySQL을 사용하는 경우 안전한 업데이트 활성화

• DBA가있는 경우 요청하십시오.

나는이 3 가지가 심각한 해를 끼치 지 못하도록 만들었다.

---

• 아무도 백업을 원하지 않지만 모두는 복구를 위해 울고
• Create your DB with foreign key references, because you should:
• make it as hard as possible for yourself to update/delete data and destroying the structural integrity / something else with that
• If possible, run on a system where you have to commit the changes before you permanently store them (i.e. deactivate autocommit while repairing the db)
• Try to identify your problem's classes so that you get an understanding how to fix without trouble
• Get a routine in playing backups into a database, always have a second database on a test server at hand so you can just work on that
• Because remember: If something fails totally, you need to be up and running again as fast as any possible

Well, that's about all I can think of now. Take the bold passages and you see whats #1 for me. ;-)

---

Maybe consider not using any deletes or drops at all. Or maybe reduce the user permissions so that only a special DB user can delete/drop things.

---

If you're using Oracle or another database that supports it, verify your changes before doing a COMMIT.

---

Data should always be deployed to live via scripts, which can be rehearsed as many times as it is required to get it right on dev. When there's dependent data for the script to run correctly on dev, stage it appropriately -- you can not get away with this step if you truly want to be careful.

---

Check twice, commit once!

---

Backup or dump the database before starting.

---

To add on to what @Wayne said, write your WHERE before the table name in a DELETE or UPDATE statement.

---

BACK UP YOUR DATA. Learned that one the hard way working with customer databases on a regular basis.

---

Always add a using clause.

---

My rule (as an app developer): Don't touch it! That's what the trained DBAs are for. Heck, I don't even want permission to touch it. :)

---

Different colors per environment: We've setup our PL\SQL developer (IDE for Oracle) so that when you logon to the production DB all the windows are in bright red. Some have gone as far as assigning a different color for dev and test as well.

---

Make sure you specify a where clause when deleting records.

---

always test any queries beyond select on development data first to ensure it has the correct impact.

---

1. if possible, ask to pair with someone
2. always count to 3 before pressing Enter (if alone, as this will infuriate your pair partner!)

---

If I'm updating a database with a script, I always make sure I put a breakpoint or two at the start of my script, just in case I hit the run/execute by accident.

---

I'll add to recommendations of doing BEGIN TRAN before your UPDATE, just don't forget to actually do the COMMIT; you can do just as much damage if you leave your uncommitted transaction open. Don't get distracted by phones, co-workers, lunch etc when in the middle of updates or you'll find everyone else is locked up until you COMMIT or ROLLBACK.

---

I always comment out any destructive queries (insert, update, delete, drop, alter) when writing out adhoc queries in Query Analyzer. That way, the only way to run them, is to highlight them, without selecting the commented part, and press F5.

I also think it's a good idea, as already mentioned, to write your where statement first, with a select, and ensure that you are altering the right data.

---

1. Always back up before changing.
2. Always make mods (eg. ALTER TABLE) via a script.
3. Always modify data (eg. DELETE) via a stored procedure.

---

Create a read only user (or get the DBA to do it) and only use that user to look at the DB. Add the appropriate permissions to schema so that you can view the content of stored procedures/views/triggers/etc. but not have the ability to change them.

참고URL : https://stackoverflow.com/questions/168486/whats-your-1-way-to-be-careful-with-a-live-database