답변.

SQL에서 오류 처리를 하고 로깅을 구성하는 것은 복잡한 비즈니스 프로세스가 발전하면서 특히 인기를 얻고 있습니다. 오류 발생 시 단순히 실행을 중단하는 것이 아니라, 오류 발생 사실을 기록하고 가능한 경우 작업을 계속하는 것이 중요해졌습니다. 처음에 SQL은 발전된 try-catch 기능이 없어 각 데이터베이스 시스템마다 자체 메커니즘을 제공했습니다.

문제 역사:

이전 SQL 표준 버전에서는 프로시저 내에서 오류를 잡기 위한 내장된 연산자가 없었습니다. 이후 제조업체들은 Microsoft SQL Server의 TRY...CATCH 또는 MySQL의 HANDLER와 같은 구조를 도입하여 데이터베이스 수준에서 작업 프로세스를 좀 더 유연하게 제어할 수 있게 되었습니다.

문제점:

오류는 잘못된 데이터 때문이거나 시스템적 원인으로 인해 발생할 수 있습니다. 프로시저에서 오류 잡기 및 기록이 구현되지 않으면 디버깅 및 유지 보수가 매우 어려워집니다. 또한, 비즈니스 작업을 중단할 필요가 없는 경우 치명적인 오류와 처리된 오류를 구분할 수 있어야 합니다.

해결책:

현대 시스템에서는 오류 수집 및 로깅 구조를 도입해야 합니다. 별도의 로깅 테이블을 생성하고 TRY...CATCH (SQL Server) 또는 DECLARE ... HANDLER (MySQL)를 사용하여 예외에 대한 자세한 정보를 저장하여 후에 오류 원인을 분석할 수 있도록 해야 합니다.

코드 예제 (SQL Server):

CREATE PROCEDURE dbo.UpdateCustomer
  @CustomerID INT,
  @NewName NVARCHAR(100)
AS
BEGIN
  BEGIN TRY
    UPDATE Customers SET Name = @NewName WHERE CustomerID = @CustomerID;
  END TRY
  BEGIN CATCH
    INSERT INTO ErrorLog (ErrorMessage, ErrorSeverity, ErrorTime)
    VALUES (ERROR_MESSAGE(), ERROR_SEVERITY(), GETDATE());
    THROW;
  END CATCH
END;

주요 특징:

TRY...CATCH 사용은 잠재적으로 위험한 코드를 격리할 수 있게 합니다.
최대 세부정보로 오류를 로깅 테이블에 삽입합니다.
적절한 프로시저 종료 및 호출 층에 대한 정보 전달을 위해 Throw/Error raising 사용.

오해의 소지가 있는 질문.

모든 유형의 오류를 TRY...CATCH 블록(또는 핸들러)을 통해 잡을 수 있나요?

아니요, 모든 오류를 잡을 수 있는 것은 아닙니다. 예를 들어, 서버의 심각한 오류는 잡을 수 없습니다. "Attention" 유형의 오류나 연결 실패는 트랜잭션 처리 범위를 넘어섭니다.

오류가 발생할 경우 트랜잭션을 사용하지 않으면 프로시저 내에서 커밋되지 않은 변경 사항은 어떻게 되나요?

변경 사항은 부분적으로 커밋될 것이며, 일부 업데이트는 데이터베이스에 들어가고 일부는 손실될 수 있습니다. 불일치를 피하기 위해 항상 트랜잭션을 사용하는 것이 좋습니다.

BEGIN TRY
  BEGIN TRANSACTION;
  --...코드
  COMMIT;
END TRY
BEGIN CATCH
  ROLLBACK;
END CATCH

다른 컨텍스트에서 오류를 기록하기 위해 CATCH 블록 내에서 INSERT EXEC을 사용할 수 있나요?

항상 가능한 것은 아닙니다: INSERT EXEC은 몇몇 컨텍스트에서 금지되어 있습니다(예: 이미 활성 트랜잭션이 있는 경우) 따라서 이는 2차 오류를 일으킬 수 있습니다. 오류 세부정보를 로컬에서 수집한 후 단일 INSERT로 기록하는 것이 좋습니다.

일반적인 오류 및 안티 패턴

오류 로깅이 없음.
트랜잭션 무시로 데이터 단절 발생.
오류 코드 및 사용자 시간/코드 없이 텍스트만 로깅.

실생활 사례

부정적인 사례

고객이 RAISERROR만 사용하여 로깅 없이 논리를 구현했기 때문에 오류가 저장되지 않고 분석할 수 없었습니다.

장점:

코드가 적음.

단점:

실패 원인을 이해할 수 없고 프로덕션 문제를 분석할 수 없습니다.

긍정적인 사례

TRY...CATCH와 ErrorLog 테이블을 사용하여 시간, 오류 코드, 사용자, 텍스트 및 추적 정보를 기록했습니다.