SQL Server 2005에서 Trigger Create가 30 분 이상 걸립니다.

StackOverflow https://stackoverflow.com/questions/230642

  •  04-07-2019
  •  | 
  •  

문제

라이브/프로덕션 데이터베이스에서는 테이블에 트리거를 추가하려고하지만 실패했습니다. 몇 번 시도했지만 Create Trigger 문이 완료하는 데 30 분 이상 걸렸으며 취소했습니다.

테이블은 몇 가지 다른 프로세스에 의해 자주 읽거나 쓰여진 테이블입니다. 테이블을 업데이트하는 예정된 작업을 비활성화하고 테이블에 활동이 적을 때 때때로 시도했지만 테이블에 액세스하는 모든 것을 중지 할 수는 없습니다.

생성 트리거 문 자체에 문제가 있다고 생각하지 않습니다. 테스트 환경에서 트리거 제작 명령문은 성공적이고 빠르며 행을 테이블에 삽입/업데이트 할 때 트리거가 올바르게 작동합니다. 테스트 데이터베이스에서 트리거를 만들었을 때 테이블에로드가 없었으며 라이브/프로덕션 데이터베이스 (100 vs. 13,000,000+)와는 상당히 적은 행이있었습니다.

다음은 내가 실행하려는 트리거 진술서입니다.

CREATE TRIGGER [OnItem_Updated] 
    ON  [Item]
   AFTER UPDATE
AS 
BEGIN
    SET NOCOUNT ON;

    IF update(State)
    BEGIN
        /* do some stuff including for each row updated call a stored 
          procedure that increments a value in table based on the 
          UserId of the updated row */
    END
END

행이 업데이트되는 동안 또는 행이 많은 경우 테이블에 트리거를 만드는 데 문제가있을 수 있습니까?

SQLSERVER 트리거는 기본적으로 활성화됩니다. 기본적으로 비활성화 된 트리거를 만들 수 있습니까?

다른 아이디어가 있습니까?

도움이 되었습니까?

해결책

문제는 테이블 자체가 아니라 트리거를 만들기 위해 업데이트 해야하는 시스템 테이블에있을 수 있습니다. 일반 프로세스의 일부로 다른 종류의 DDL을하고 있다면 그것을 유지할 수 있습니다.

SP_WHO를 사용하여 블록이 어디에서 왔는지 알아 봅니다. 그런 다음 거기에서 조사하십시오.

다른 팁

나는 Create Trigger가 전체 테이블에 잠금을 넣으려고 시도 할 것이라고 생각합니다.

그 테이블에 많은 활동이 있다면 오랫동안 기다려야 할 수도 있고 교착 상태를 만들 수 있습니다.

모든 스키마 변경의 경우 실제로 데이터베이스의 모든 사람을 얻어야합니다.

그것은 활성 연결로 "작은"변화를 입히고 싶은 유혹이 있다고 말했다. 잠금 장치가 어디에 있는지 확인하려면 잠금 / 연결을 살펴 봐야합니다.

이상하다. an AFTER UPDATE 트리거는 테이블에서 기존 행을 점검 할 필요가 없습니다. 트리거를 추가하기 위해 테이블에서 잠금을 얻을 수 없을 가능성이 있다고 생각합니다.

기본적으로 아무것도하지 않는 트리거를 만들려고 할 수도 있습니다. 당신이 그것을 만들 수 없다면, 그것은 잠금 문제입니다. 가능하다면 해당 트리거를 비활성화하고 의도 한 코드를 신체에 추가하고 활성화 할 수 있습니다. (창조 중에 방아쇠를 비활성화 할 수 있다고 생각하지 않습니다.)

문제의 일부는 트리거 자체 일 수도 있습니다. 트리거가 실수로 테이블의 모든 행을 업데이트 할 수 있습니까? 테스트 데이터베이스에서 100 행 사이에서 13,000,000 행 사이에 큰 차이가 있습니다. 성능을 예측할 수없는 큰 데이터 세트가있을 때 작은 세트에 대해 코드를 개발하는 것은 매우 나쁜 생각입니다. 100 레코드에서 잘 작동하는 SQL은 몇 시간 동안 수백만 달러의 시스템을 완전히 잠글 수 있습니다. Prod로 홍보 할 때가 아니라 Dev에서 알고 싶어합니다.

방아쇠에 저장된 Proc를 호출하는 것은 일반적으로 매우 나쁜 선택입니다. 또한 트리거에서 더 나쁜 선택 인 레코드를 통해 반복해야한다는 것을 의미합니다. 트리거는 여러 레코드 인서트/업데이트 또는 삭제를 설명해야합니다. 누군가가 10 만 행을 삽입하는 경우 (13,000,000 개의 레코드가있는 경우에는 가능하지 않음), 레코드 기반 저장된 Proc를 통해 반복하면 시간이 걸리고 전체 테이블을 잠그고 모든 사용자가 개발자를 사냥하고 죽이기를 원합니다 (또는 적어도 MAIM). 그들이 일을 끝낼 수 없기 때문에 그분.

나는 당신이 Simliar의 크기가 Prod에 대해 테스트 할 때 까지이 트리거를 Prod에 넣는 것을 고려하지 않을 것입니다.

내 친구 Dennis는이 기사를 썼는데, 많은 정보가있을 때 소수의 정보를 테스트하는 이유를 보여줍니다.http://blogs.lessthandot.com/index.php/datamgmt/?blog=3&title=your-testbed-has-to-have-the-volume&disp=single&c=1&tb=1&pb=1210

운영 DISABLE TRIGGER triggername ON tablename 방아쇠를 변경하기 전에 다시 활성화 할 수 있습니다 ENABLE TRIGGER triggername ON tablename

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top