SQL Server의 저장 프로시저는 하나 이상의 Transact-SQL 문 그룹 또는 Microsoft .NET Framework CLR(공용 런타임 언어) 메서드에 대한 참조입니다. 프로시저는 다음을 수행할 수 있으므로 다른 프로그래밍 언어의 구문과 유사합니다.
입력 매개 변수를 수락하고 출력 매개 변수 형식의 여러 값을 호출 프로그램에 반환합니다.
데이터베이스에서 작업을 수행하는 프로그래밍 문을 포함합니다. 여기에는 다른 프로시저 호출이 포함됩니다.
성공 또는 실패(및 실패 원인)를 나타내기 위해 호출 프로그램에 상태 값을 반환합니다.
저장 프로시저 사용의 이점
다음 목록에서는 프로시저를 사용할 때의 몇 가지 이점에 대해 설명합니다.
서버/클라이언트 네트워크 트래픽 감소
프로시저의 명령은 단일 일괄 처리 코드로 실행됩니다. 따라서 프로시저를 실행할 호출만 네트워크에서 전송되기 때문에 서버와 클라이언트 간의 네트워크 트래픽이 크게 줄어들 수 있습니다. 프로시저에서 제공하는 코드 캡슐화가 없으면 모든 개별 코드 줄이 네트워크를 통과해야 합니다.
보안성 강화
여러 사용자 및 클라이언트 프로그램이 기본 데이터베이스 개체에 대한 직접적인 사용 권한이 없는 경우에도 프로시저를 통해 이러한 기본 개체에 대해 작업을 수행할 수 있습니다. 프로시저는 수행되는 프로세스 및 작업을 제어하고 기본 데이터베이스 개체를 보호합니다. 따라서 개별 개체 수준에서 사용 권한을 부여할 필요가 없으며 보안 계층이 간소화됩니다.
CREATE PROCEDURE 문에서 EXECUTE AS 절을 지정하여 다른 사용자를 가장하거나 사용자 또는 애플리케이션이 기본 개체 및 명령에 대한 직접 권한 없이 특정 데이터베이스 작업을 수행할 수 있도록 할 수 있습니다. 예를 들어 TRUNCATE TABLE과 같은 일부 작업에는 부여할 수 있는 권한이 없습니다. TRUNCATE TABLE을 실행하려면 지정된 테이블에 대한 ALTER 권한이 있어야 합니다. 테이블에 대한 사용자 ALTER 사용 권한을 부여하는 것은 사용자에게 테이블을 자르는 기능을 넘어서는 권한을 효과적으로 부여하기 때문에 이상적이지 않을 수 있습니다. 모듈에 TRUNCATE TABLE 문을 통합하고 모듈이 테이블을 수정할 수 있는 권한이 있는 사용자로 실행되도록 지정하면 테이블을 잘라내어 모듈에 EXECUTE 권한을 부여한 사용자로 확장할 수 있습니다.
네트워크를 통해 프로시저를 호출할 때 프로시저를 실행하는 호출만 표시됩니다. 따라서 악의적인 사용자는 테이블 및 데이터베이스 개체 이름을 보거나, Transact-SQL 문을 포함하거나, 중요한 데이터를 검색할 수 없습니다.
프로시저 매개 변수를 사용하면 SQL 삽입 공격을 방지할 수 있습니다. 매개 변수 입력은 실행 코드가 아닌 리터럴 값으로 처리되므로 공격자가 프로시저 내의 Transact-SQL 문에 명령을 삽입하고 보안을 손상시키는 것이 더 어렵습니다.
프로시저를 암호화하여 소스 코드를 난독 분석할 수 있습니다. 자세한 내용은 SQL Server 암호화를 참조하세요.
코드 재사용
반복적인 데이터베이스 작업에 대한 코드는 프로시저에서 캡슐화할 수 있는 완벽한 후보입니다. 이렇게 하면 동일한 코드를 불필요하게 다시 작성할 수 없고, 코드 불일치가 감소하며, 필요한 권한을 가진 사용자 또는 애플리케이션에서 코드에 액세스하고 실행할 수 있습니다.
보다 간편한 유지 관리
클라이언트 애플리케이션에서 프로시저를 호출하고 데이터베이스 작업을 데이터 계층에 유지하면 기본 데이터베이스의 모든 변경 내용에 대해 프로시저만 업데이트하면 됩니다. 애플리케이션 계층은 별도로 유지되며 데이터베이스 레이아웃, 관계 또는 프로세스에 대한 변경 내용을 알 필요가 없습니다.
성능 향상
기본적으로 프로시저는 처음 실행될 때 컴파일하고 후속 실행에 다시 사용할 실행 계획을 만듭니다. 쿼리 프로세서는 새 계획을 만들 필요가 없으므로 일반적으로 프로시저를 처리하는 데 시간이 덜 걸립니다.
프로시저에서 참조하는 테이블 또는 데이터가 크게 변경된 경우 미리 컴파일된 계획으로 인해 실제로 프로시저의 성능이 저하될 수 있습니다. 이 경우 프로시저를 다시 컴파일하고 새 실행 계획을 강제로 적용하면 성능이 향상될 수 있습니다.
저장 프로시저 유형
사용자 정의
사용자 정의 프로시저는 사용자 정의 데이터베이스 또는 리소스 데이터베이스를 제외한 모든 시스템 데이터베이스에서 만들 수 있습니다. 이 프로시저는 Transact-SQL 또는 Microsoft .NET Framework CLR(공용 런타임 언어) 메서드에 대한 참조로 개발할 수 있습니다.
일시적인
임시 프로시저는 사용자 정의 프로시저의 한 형태입니다. 임시 프로시저는 임시 프로시저가 tempdb에 저장된다는 점을 제외하고 영구 프로시저와 같습니다. 임시 프로시저에는 로컬 프로시저와 전역 프로시저의 두 가지 유형이 있습니다. 이 두 유형은 이름, 표시 여부 및 가용성 면에서 서로 다릅니다. 로컬 임시 프로시저에는 이름의 첫 번째 문자로 단일 숫자 기호(#)가 있습니다. 현재 사용자 연결에만 표시되며 연결이 닫혀 있으면 삭제됩니다. 전역 임시 프로시저에는 이름의 처음 두 문자로 두 개의 숫자 기호(##)가 있습니다. 사용자가 만든 후에는 사용자에게 표시되며, 프로시저를 사용하여 마지막 세션이 끝날 때 삭제됩니다.
시스템
시스템 프로시저는 SQL Server에 포함됩니다. 내부 숨겨진 리소스 데이터베이스에 물리적으로 저장되며 모든 시스템 및 사용자 정의 데이터베이스 의 sys 스키마에 논리적으로 표시됩니다. 또한 msdb 데이터베이스에는 경고 및 작업 예약에 사용되는 dbo 스키마의 시스템 저장 프로시저도 포함됩니다. 시스템 프로시저는 접두사 sp_ 시작하므로 사용자 정의 프로시저의 이름을 지정할 때 이 접두사를 사용하지 않는 것이 좋습니다. 시스템 프로시저의 전체 목록은 시스템 저장 프로시저(Transact-SQL)를 참조하세요.
SQL Server는 다양한 유지 관리 작업을 위해 SQL Server에서 외부 프로그램으로 인터페이스를 제공하는 시스템 프로시저를 지원합니다. 이러한 확장 프로시저는 xp_ 접두사를 사용합니다. 확장 프로시저의 전체 목록은 일반 확장 저장 프로시저(Transact-SQL)를 참조하세요.
확장 User-Defined
확장 프로시저를 사용하면 C와 같은 프로그래밍 언어로 외부 루틴을 만들 수 있습니다. 이러한 절차는 SQL Server 인스턴스가 동적으로 로드하고 실행할 수 있는 DLL입니다.
비고
확장 저장 프로시저는 이후 버전의 SQL Server에서 제거됩니다. 새 개발 작업에서는 이 기능을 사용하지 말고, 현재 이 기능을 사용하는 애플리케이션은 가능한 한 빨리 수정하세요. 대신 CLR 프로시저를 만듭니다. 이 메서드는 확장 프로시저 작성에 대한 보다 강력하고 안전한 대안을 제공합니다.
관련 작업
| 작업 설명 | 항목 |
| 저장 프로시저를 만드는 방법을 설명합니다. | 저장 프로시저 만들기 |
| 저장 프로시저를 수정하는 방법을 설명합니다. | 저장 프로시저 수정 |
| 저장 프로시저를 삭제하는 방법을 설명합니다. | 저장 프로시저 삭제 |
| 저장 프로시저를 실행하는 방법을 설명합니다. | 저장 프로시저 실행 |
| 저장 프로시저에 대한 권한을 부여하는 방법을 설명합니다. | 저장 프로시저에 대한 권한 부여 |
| 저장 프로시저에서 애플리케이션으로 데이터를 반환하는 방법을 설명합니다. | 저장 프로시저에서 데이터 반환 |
| 저장 프로시저를 다시 컴파일하는 방법을 설명합니다. | 저장 프로시저 다시 컴파일 |
| 저장 프로시저의 이름을 바꾸는 방법을 설명합니다. | 저장 프로시저 이름 바꾸기 |
| 저장 프로시저의 정의를 보는 방법을 설명합니다. | 저장 프로시저의 정의 보기 |
| 저장 프로시저에 대한 종속성을 보는 방법을 설명합니다. | 저장 프로시저의 종속성 보기 |