Bora.Choi

1. 인스톨에 관한 팁

SQL Server를 인스톨 할 때 선택한 정렬 순서(sort order)가 성능에 영향을 끼칠 수 있다. 정렬 순서 가운데에
는 비록 그 결과가 클라이언트 프로그램에서 문제를 일으키긴 하지만 이진 정렬이 가장 속도가 빠르다. 디폴
트로 선택되는 "사전 순서(dictionary order), 대소문자 구분 안함(case-insensitive)"이 그 다음으로 빠르며 아
마 여러분은 보통 이것을 사용할 것이다. "사전 순서, 대소문자 구분 안함, 액센트 구분 안함(accent-
insensitive), 대문자 선호(uppercase preference)"와 "사전 순서, 대소문자 구분함(case-sensitive)"는 속도면
에서 뒤쳐진다. 프로그램의 성능과 요구사항에 가장 적합한 정렬 순서를 선택하도록 한다. [6.5, 7.0, 2000]
(마이크로소프트의 보다 자세한 정보 : http://msdn.microsoft.com/library/default.asp?
URL=/library/psdk/sql/8_ar_da_10.htm)

*****

SQL Server를 인스톨 할 때 선택하는 네트워크 라이브러리도 서버와 클라이언트 간의 통신 속도에 영향을 준
다. 사용 가능한 세 개의 네트워크 라이브러리 중에서 TCP/IP가 가장 빠르며 멀티 프로토콜이 가장 느리다.
TCP/IP의 속도가 빠르므로 서버와 클라이언트 모두 TCP/IP를 사용하는 것이 좋으며 사용하지 않는 라이브러
리는 불필요한 오버헤드만 가중시키므로 인스톨 하지 않는 편이 바람직하다. [6.5, 7.0, 2000]
(마이크로소프트의 보다 자세한 정보 : http://msdn.microsoft.com/library/default.asp?
URL=/library/psdk/sql/1_server_6.htm)

*****

일반적으로 여러분은 가장 최신의 SQL Server 서비스 팩을 인스톨 하고 싶을 것이다.
사실상 SQL Server 6.5와 7.0의 서비스 팩에서 성능에 영향을 줄 수 있는 버그는 모두 해결된 상태이다. 그러
나 잘 아는 바와 같이 새로운 서비스 팩이 나오자 마자 성급하게 인스톨 하는 것은 좋지 않으며 최소한 2~4주
정도 SQL Server 뉴스그룹 등을 관찰하면서 새로운 서비스 팩이 중대한 문제를 안고 있지는 않은지 확인하는
것이 좋다. [6.5, 7.0, 2000]




2. 파일 위치에 관한 팁

master, msdb 그리고 model 데이터베이스는 운영 환경에서 그다지 많이 사용되지는 않기 때문에 이들 데이터
베이스의 물리적인 위치는 별로 중요하지 않다. [6.5, 7.0, 2000]

*****

데이터베이스 파일(.mdf)과 로그 파일(.ldf)을 별도의 디스크 어레이에 위치시켜서 읽기와 쓰기 작업이 충돌하
는 경우가 감소하도록 서로 분리시킨다. [6.5, 7.0, 2000]

데이터베이스 파일(.mdf)을 저장할 때에는 RAID 10 어레이에서 가장 뛰어난 성능을 보여준다. RAID 10 어레이
가 너무 비싸다면 RAID 5 가 그 다음으로 좋은 선택이 될 수 있다. 각 RAID 어레이는(5 또는 10) 컨트롤러가 지
원하는 한 여러 개의 물리적인 디스크를 어레이 안에 가질 수 있다. 이런 점으로 해서 어레이의 각 물리적 드
라이브에 읽기와 쓰기 작업이 동시에 진행될 수 있으며 디스크 I/O 처리 능력이 크게 늘어나게 된다.

*****

데이터베이스 로그 파일(.ldf)을 저장할 때에는 RAID 1 어레이(미러링)에 저장하는 것이 가장 최적의 성능을
보이는 경우가 많다. 여기서는 RAID 1 어레이에 오직 하나의 로그 파일이 존재한다고 가정하였다. RAID 1 어레
이에 하나의 로그 파일만 존재하면 파일을 순차적으로 쓸 수 있기 때문에 로그 기록 작업이 빨라지게 된다.

그러나 만약 RAID 1 어레이를 공유하는 로그 파일이 여러 개 있다면(여러 개의 데이터베이스로부터) RAID 1
어레이를 사용하는 장점이 거의 사라진다. 로그 기록 작업은 여전히 순차적으로 이루어 지지만 동일한 어레이
에 여러 개의 로그 파일이 존재하면 이 어레이는 더 이상 순차적으로 기록할 수 없고 랜덤하게 쓰기 작업을 해
야 하므로 RAID 1 어레이의 이점을 상쇄해 버리기 때문이다.

그러나 RAID 1 어레이가 RAID 5 어레이보다 랜덤 쓰기를 더 많이 처리할 수 있다면 RAID 5 어레이 보다는
RAID 1 어레이가 아직도 더 좋다고 볼 수 있다. 확실하게 알기 위해서 여러분의 하드웨어를 확인해 보기 바란
다. 다른 방법으로는 데이터베이스들의 로그를 각각 별도의 RAID 1 어레이에 저장하는 것이다. 또는 RAID 1
과 RAID 5의 장점만을 모은 RAID 10 어레이에 로그 파일을 저장하는 것도 생각해 볼 수 있다. 많은 비용이 들
어가겠지만 최고의 성능을 제공한다. [6.5, 7.0, 2000]

*****

데이터베이스의 규모가 매우 크고 작업량도 많다면 성능을 향상 시키기 위해서 여러 개의 파일을 사용해 볼
수 있다. 예를 들어 조회 작업이 매우 많은 천만건의 레코드를 가진 테이블이 하나 있다고 하자. 이 테이블이
하나의 데이터베이스 파일에 존재하고 있다면 레코드를 순차적으로 읽기 위해서 SQL Server에서는 단지 하나
의 쓰레드만을 사용한다. 그러나 만약 이 테이블이 세 개의 물리적 파일로 분산되어 있다면 테이블을 순차적
으로 읽을 때 SQL Server는 세 개의 쓰레드(한 파일에 하나씩)를 사용하므로 작업 속도가 훨씬 빨라지게 된
다. 게다가 각 파일이 별도의 디스크나 디스크 어레이에 존재하고 있다면 성능은 한층 배가된다.

본질적으로 큰 테이블이 여러 개의 물리적인 파일로 나누어 질수록 성능이 높아질 가능성이 더 커진다. 물론
서버의 I/O가 한계 값에 도달하게 되면 더 이상 쓰레드가 추가되어도 성능 향상에는 별로 도움이 되지 못하게
된다. 하지만 서버의 I/O가 한계 값에 도달할 때 까지는 쓰레드(그리고 파일)가 늘어날수록 성능도 함께 증가
하게 된다. [7.0, 2000]




3. 서버 설정에 관한 팁

SQL Server 6.5를 사용하고 있다면 서버의 물리적인 RAM에 따라서 8MB 또는 16MB로 결정되는 디폴트 메모
리 세팅을 그대로 사용하는 것과 같이 DBA 들이 흔히 저지르는 실수를 반복하지 말기 바란다. 이 숫자는 NT
서버의 여유 메모리에서 얼마만큼의 RAM을 SQL Server가 사용할 수 있는가를 지정하는 것이다. 필자는 RAM
이 2GB인 시스템을 포함하여 디폴트 메모리로 설정된 SQL Server 6.5 시스템을 많이 보았다.

SQL Server 6.5는 7.0이나 2000 버전과는 달리 메모리를 동적으로 설정하는 기능을 가지고 있지 않기 때문에
DBA가 직접 늘려 주어야 한다. [6.5]
(마이크로소프트의 보다 자세한 정보 : http://www.microsoft.com/technet/SQL/Technote/sqliopt.asp)

*****

작업 내용을 확실히 이해하고 있고 지금 하고 있는 SQL Server 의 설정 변경 작업이 성능 향상에 도움이 된다
는 공정한 실험 결과를 가지고 있지 않는 한 함부로 서버의 성능에 영향을 줄 수 있는 SQL Server 의 설정 사
항을 변경하지 말기 바란다. 많은 경우에 있어서 문제를 해결하기 보다는 오히려 더 많은 문제를 일으킬 가능
성이 크다. [6.5, 7.0, 2000]

*****

SQL Server는 자동으로 튜닝이 되긴 하지만 SQL Server가 내부적인 세팅의 최적 값을 찾아내기 까지는 SQL
Server가 겪는 활동의 종류와 레벨에 따라서 대략 수 시간정도 소요된다. SQL Server 서비스가 처음 기동 되
면 SQL Server는 디폴트 환경 세팅으로부터 시작하게 된다. 데이터베이스에 대한 작업이 진행되고 쿼리가 실
행되면서 SQL Server는 자체적으로 정밀하게 튜닝을 하게 되고 시간이 흐를 수록 성능이 증가한다.
이런 점에서 보았을 때 SQL Server가 자체적으로 튜닝할 수 있을 때까지는 정확한 퍼포먼스 모니터 결과를 얻
는 것을 기대하지 않는 편이 좋다. SQL Server가 튜닝될 수 있도록 mssqlserver 서비스가 기동 된 후에 어느
정도의 시간 여유를 주도록 한다. [7.0, 2000]

*****

SQL Server의 옵션은 일반 옵션과 고급 옵션으로 구분된다. sp_configure를 사용해서 고급 옵션을 변경하려
면 고급 옵션을 사용 가능하게 하는 스토어드 프로시저를 먼저 실행해야 한다. 이 때 사용되는 명령은
sp_configure "show advanced options", 1 이다. [6.5, 7.0, 2000]

*****

여러 개의 CPU가 장착된 시스템이 100% 풀 가동중일 때 CPU 사용도를 줄일 수 있는 다른 방법이 없는 경우에
는 NT의 파이버(fibers)를 사용해서 성능을 향상 시킬 수 있다. 파이버는 쓰레드와 유사하게 동작하는 쓰레드
의 서브 컴포퍼넌트이다. 파이버를 사용하면 여러 개의 CPU를 사용하는 시스템에서 CPU간의 스위치 시에 오
버헤드가 적다는 장점이 있다.

CPU가 최대로 사용되는 상황이 아니라면 파이버를 사용해도 별 효과는 없으므로 이 옵션을 선택하지 않도록
한다. 또한 이렇게 설정하기 전과 후의 성능 변화도 자세하게 테스트 해야 한다. 이 옵션은 SQL Server
의 "Properties" 의 "Processor" 탭에서 찾을 수 있다. [7.0, 2000]
(마이크로소프트의 보다 자세한 정보 :
http://msdn.microsoft.com/library/techart/storageeng.htm#storageeng_procplan)

*****

고속의 디스크 컨트롤러가 장착된 서버에서는 SQL Server 환경 설정에서 "Max Async IO"를 변경함으로써
I/O 성능을 향상 시킬 수 있다. 디폴트는 32 이며 최대 값은 255 이다. 여러분의 서버에서 최적의 값을 찾기 위
해서는 여러 가지로 변경해 가면서 테스트 해봐야 한다.

적절한 "Max Async IO" 값은 대략 동시에 I/O가 가능한 물리적인 드라이브 개수에 2 또는 3을 곱한 값이다.

이 옵션을 변경한 다음에는 매번 SQL Server를 재기동 해야 하므로 운영중인 서버에서는 테스트하지 말기 바
란다. 이 값을 너무 높게 설정하면 디스크 작업의 적체가 발생하는데 퍼포먼스 모니터로 보면 Physical Disk
객체의 Disk Queue Length 가 물리적 드라이브마다 2를 넘어서게 되며 이것은 I/O에서 병목 현상이 발생함을
의미한다. [6.5, 7.0, 2000]
(마이크로소프트의 보다 자세한 정보 : http://support.microsoft.com/support/kb/articles/Q112/5/39.asp)

*****

삽입, 갱신, 삭제 작업을 많이 하는 OLTP 프로그램이 매우 활발하게 실행된다면 "recovery interval"의 디폴트
값인 0는 적절하지 않다(0은 SQL Server가 적절한 recovery interval을 결정한다는 것을 의미함). 퍼포먼스 모
니터로 관찰했을 때 규칙적으로 디스크 쓰기 작업이 100%까지 이르는 경우가 발생하면(체크포인트 시에 발생
되는 것으로 추정) "recovery interval"을 5 정도로 높게 설정해야 한다. [6.5, 7.0, 2000]
(마이크로소프트의 보다 자세한 정보 : http://msdn.microsoft.com/library/default.asp?
URL=/library/psdk/sql/8_tr_01_22.htm)

*****

데이터베이스의 모든 테이블이 SQL Server의 버퍼에 들어가지는 않고 다른 것에 비해서 매우 자주 사용되는
작은 테이블이 하나 이상 존재한다면 이 테이블들을 SP_TABLEOPTION PINTABLE 옵션을 사용하여 버퍼에 고
정시키는 것을 고려해 보도록 한다. 이렇게 하면 테이블이 일단 버퍼에 로드된 후에는 계속해서 강제적으로
버퍼에 머물게 된다.

그러면 이들 테이블이 사용될 때 필요한 디스크 I/O가 감소하게 된다. 큰 테이블을 메모리에 고정시키면 SQL
Server가 보다 유용하게 사용할 수 있는 중요한 버퍼 영역을 차지해 버리게 되므로 주의하여야 한다. [6.5,
7.0, 2000]
(마이크로소프트의 보다 자세한 정보 : http://msdn.microsoft.com/library/default.asp?
URL=/library/psdk/sql/sp_ta-tz_3.htm)

*****

SQL Server와 통신하는 클라이언트의 네트워크 패킷 크기는 디폴트로 4096 바이트이다. 대부분의 경우 이 값
은 최적의 값이지만 특별한 경우에는 이것을 변경할 필요가 있다. 만약 클라이언트가 규칙적으로 큰 텍스트
나 이미지 데이터를 SQL Server로 전송한다거나, 대규모의 BCP 또는 DTS 작업을 수행하는 경우 패킷 크기를
늘려주면 오고 가는 네트워크 패킷의 숫자가 줄어들므로 성능을 향상시킬 수 있다. 반대로 응용 프로그램이
작은 데이터만을 주고 받을 때에는 패킷 크기를 줄여줌으로써 응답성을 향상시킬 수 있다.

SQL Server에서 설정한 패킷 크기는 클라이언트 소프트웨어에 의해서 변경될 수 있음을 기억해야 한다. 여러
분이 네트워크 트래픽 분석에 매우 익숙하고 작업 후의 성능 변화를 테스트할 수 있는 능력이 있는 경우에만
이 값을 변경하는 것이 좋다. [6.5, 7.0, 2000]
(마이크로소프트의 보다 자세한 정보 : http://msdn.microsoft.com/library/psdk/sql/1_server_48.htm)

*****

서버에 물리적인 RAM이 충분한 상태에서 해쉬나 정렬 작업과 같이 메모리를 집중적으로 사용하는 쿼리와 동
시에 실행되는 쿼리가 많다면 SQL Server 옵션에서 "min memory per query" 옵션을 디폴트인 1024K 보다 늘려
보도록 한다. SQL Server가 자동으로 할당하는 최소한의 메모리를 지정하는 것으로 이 값을 늘려주면 메모리
를 많이 사용하는 쿼리의 성능이 향상된다.

반대로 이 옵션을 너무 크게 설정하면 쿼리가 오히려 느려지게 된다. SQL Server가 이 값에 지정한 만큼의 메
모리를 할당하거나 "query wait" 옵션에 지정한 값이 초과될 때까지는 쿼리가 실행되지 않기 때문이다. 여러분
의 환경에 맞는 적절한 값을 찾기 위해서는 여러 가지로 변경해 가면서 테스트 해야 한다. [7.0, 2000]
(마이크로소프트의 보다 자세한 정보 : http://msdn.microsoft.com/library/psdk/sql/1_server_46.htm)

*****

SQL Server가 OLTP 프로그램만을 수행하고 OLAP 프로그램은 전혀 사용하지 않는다면 "max degree of
parallelism"을 1로 설정하여 병렬 처리를 하지 않도록 해 본다. 디폴트는 "0"이며 모든 CPU에 걸쳐서 병렬 처
리를 하도록 되어 있다. CPU가 하나인 경우에는 "max degree of parallelism" 값은 무시된다.

여러 개의 CPU가 있는 경우 디폴트로 병렬 처리를 하게 되는데 쿼리 옵티마이저가 각 쿼리에 대해서 병렬 처
리가 가능한지 평가하는데 약간의 오버헤드가 발생한다. 대부분의 OLTP 서버에서는 실행되는 쿼리의 특성
상 병렬 처리가 불가능한 경우가 많다. 이렇기 때문에 쿼리 옵티마이저는 각 쿼리가 병렬 처리로부터 이득을
볼 수 있을지 평가하기 위해서 시간을 소비하게 된다. 만약 쿼리가 병렬로 실행될 필요가 없다는 것을 미리 알
고 있는 경우에는 이 기능을 OFF 시켜서 쿼리의 평가에 걸리는 시간을 줄임으로써 약간의 오버헤드를 감소시
킬 수 있다.

물론 SQL Server에서 실행되는 쿼리의 성격상 병렬 처리의 장점을 이용할 수 있는 것이라면 병렬 처리를 OFF
시킬 필요는 없다. 이 기능을 사용했을 때 여러분의 환경에서 SQL Server의 성능 향상에 도움이 될지 아니면
해가 될지를 알기 위해서는 직접 테스트를 해봐야 한다. [7.0, 2000]
(마이크로소프트의 보다 자세한 정보 : http://msdn.microsoft.com/library/psdk/sql/1_server_42.htm)

*****

서버를 SQL Server 전용으로 사용하고 있고 CPU가 여러 개 설치되어 있다면 SQL Server 옵션가운데 "priority
boost"를 디폴트인 0에서 1로 변경해 보도록 한다. 이렇게 하면 SQLServer의 sqlservr.exe 프로세스가 다른
프로세스보다 스케줄링 측면에서 높은 우선 순위(priority)를 부여 받게 된다. CPU가 여러 개인 시스템에서는
프로세스 우선 순위가 15에서 24로 변경되며 SQL Server의 성능이 약간 향상된다. 운영 환경에서 이 값을 사
용하기 전에 변경하기 전과 후의 성능 변화를 테스트하여 SQL Server에 도움이 되는지 확인해야 한다. [7.0,
2000]
(마이크로소프트의 보다 자세한 정보 : http://msdn.microsoft.com/library/psdk/sql/1_server_50.htm)

*****

서버를 SQL Server 전용으로 사용하고 있고 CPU가 여러 개 설치되어 있다면 SQL Server 옵션 가운데 "time
slice"를 변경해 보도록 한다. 이 값은 SQL Server에 의해서 중단되지 않고 사용자 프로세스가 실행될 수 있는
시간(milliseconds)을 의미한다. 일반적으로 사용자 프로세스는 CPU 시간을 얼마만큼 사용할지를 자체적으
로 결정하여 적절하게 스케줄링 한다. 그러나 사용자 프로세스가 실행되는 시간이 "time slice" 값을 넘어서게
되면 SQL Server는 이 프로세스가 멈추었다고 판단하여 강제로 종료시킨다.

"time slice"의 디폴트 값은 100 milliseconds이다. "time slice"를 너무 작게 설정하면 오랫동안 수행된다는 이유
만으로 강제적으로 종료된 프로세스를 다시 스케줄링해서 실행해야 하기 때문에 추가적인 오버헤드가 발생
하여 시스템의 성능이 저하된다. "time slice"가 너무 크면 비정상적으로 멈춰버린 프로세스가 CPU 시간을 허
비하는 문제가 발생한다.

이 값을 어떻게 설정해야 할까를 결정하는 기준이 되는 중요한 요소가운데 하나는 CPU 성능이다. 만약 CPU
가 400MHz 이하의 속도라면 디폴트 값을 바꾸지 않는 것이 좋다. CPU가 400~600MHz의 속도를 가지고 있다
면 "time slice"는 200 milliseconds가 적당하고 600MHz 이상이라면 300 milliseconds로 설정해 보기 바란다. 이
값을 실제로 사용하기 전에 변경 전과 후에 SQL Server의 성능이 어떻게 변하게 되는지 테스트 해 봐야 한다.
[7.0, 2000]
(마이크로소프트의 보다 자세한 정보 : http://msdn.microsoft.com/library/psdk/sql/1_server_64.htm)

*****

서버를 SQL Server 전용으로 사용한다면 SQL Server 옵션 가운데 "max worker threads"가 적절하게 설정되어
있는지 확인해 보기 바란다. 디폴트 값은 255이다. 이 옵션은 Windows NT 4.0에서 sqlservr.exe 프로세스에서
사용 가능한 작업 쓰레드(worker thread)의 수를 지정한다. 만약 동시 사용자가 255명 이하라면 각 사용자는
하나의 작업 쓰레드를 사용할 것이다. 그러나 동시 사용자가 255명을 넘어서면 SQL Server는 쓰레드 풀링을
사용하게 되는데 한명 이상의 사용자가 하나의 작업 쓰레드를 공유하게 된다. 쓰레드 풀링은 SQL Server에 의
해서 사용되는 시스템 리소스를 줄여주지만 대신 SQL Server를 사용하기 위한 사용자 커넥션의 경쟁이 증가
하게 된다.

최적의 성능을 위해서는 "max worker threads"를 서버를 사용하는 최대 사용자 수에 5를 더한 값으로 설정한
다. 이렇게 하면 동시 사용자 수가(더하기 5) 255 이하라면 SQL Server가 리소스를 다른 곳에 사용할 수 있도
록 해 주며 동시 사용자 수가(더하기 5) 255명을 넘어선다면 사용자 커넥션이 리소스를 차지하기 위해서 경쟁
할 것을 걱정할 필요가 없다. 하지만 추가적인 작업 쓰레드가 물리적인 RAM을 사용한다는 점을 잊
어서는 안된다. 따라서 이미 서버의 물리적인 RAM이 한계 치에 도달했다면 "max worker threads"를 디폴트인
255 이상으로 설정하지 말기 바란다. 그러나 물리적인 RAM에 여유가 있다면 위에서 설명한 것처럼 "max
worker threads"를 키워서 최대한 활용하도록 한다.

이 옵션을 운영 환경에서 사용하기 전에 변경 전과 후의 성능을 테스트하여 SQL Server가 이득을 볼 수 있는
지 확인해 보아야 한다. [7.0, 2000]
(마이크로소프트의 보다 자세한 정보 : http://msdn.microsoft.com/library/psdk/sql/1_server_44.htm)




4. Tempdb I/O에 관한 팁

SQL Server의 tempdb 데이터베이스가 응용 프로그램에 의해서 과도하게 사용된다면 tempdb를 별도의 디스
크 어레이에 위치시키도록 한다(RAID 1 또는 RAID 10 같은). [6.5, 7.0, 2000]

*****

SQL Server가 설치된 다음에 tempdb 데이터베이스를 옮기고자 한다면 아래의 스크립트를 사용하여 적절한
위치로 이동시키면 된다.

USE master
go
ALTER DATABASE tempdb MODIFY FILE (NAME = tempdev, FILENAME = E:    empdb.mdf)
go
ALTER DATABASE tempdb MODIFY FILE (NAME = templog, FILENAME = E:    emplog.ldf)
go

여기서 NAME은 tempdb 데이터베이스와 로그 파일의 논리적인 이름이며 FILENAME은 tempdb 파일의 새로운
위치를 가리킨다. [7.0, 2000]

*****

응용 프로그램에서 tempdb 데이터베이스를 많이 사용하여 디폴트로 설정된 크기보다 커진다면 tempdb의 디
폴트 크기를 응용 프로그램에서 실제로 사용되는 크기에 가깝게 늘리도록 한다. SQLServer 서비스
(mssqlserver)가 기동 될 때 마다 tempdb 파일이 디폴트 크기로 재생성 되기 때문이다. tempdb 파일이 사용 중
에 커질 수는 있지만 이 작업을 위해서 어느 정도의 리소스가 소비된다. SQL Server가 기동 될 때 tempdb 파일
의 크기를 적절하게 설정하면 운영 중에 tempdb가 확장되면서 발생하는 오버헤드를 걱정할 필요가 없다.
[7.0, 2000]




5. Cursor에 관한 팁

가능하다면 SQLServer의 커서를 사용하지 않는 것이 좋다. 일반적으로 커서는 SQL Server의 리소스를 많
이 잡아 먹을 뿐 아니라 프로그램의 성능과 확장성을 떨어뜨리게 된다. 만약 레코드 단위로 처리를 해야 하는
경우라면 커서 대신에 다른 방법을 찾아보기 바란다. 클라이언트에서 작업을 처리하거나, 서버에서 tempdb
데이터베이스의 테이블을 이용해도 되고 correlated sub-query를 사용하는 것도 좋은 대안이 될 수 있다. 때로
는 커서를 대신할 수 있는 방법이 전혀 없는 경우도 물론 있다. [6.5, 7.0, 2000]
(마이크로소프트의 추가 정보 : http://msdn.microsoft.com/library/default.asp?
URL=/library/psdk/sql/8_con_07.htm)

*****

각 레코드 별로 처리를 해야 하지만 가져오고자 하는 레코드의 개수가 많지 않다면 서버 쪽의 커서를 사용하
지 않도록 한다. 그 대신 전체 레코드를 클라이언트로 넘긴 다음 클라이언트에서 레코드 별로 필요한 작업을
수행한 후 결과를 다시 서버로 보내는 형식으로 처리한다. [6.5, 7.0, 2000]

*****

커서를 사용할 수 밖에 없는 상황이라면 forward-only 및 read_only 커서를 사용하는 것이 좋다. 이 커서는
SQL Server에 가장 적은 오버헤드를 발생시킨다. [6.5, 7.0, 2000]

*****

응용 프로그램에서 커서를 사용할 수 밖에 없는 형편이라면 최고의 성능을 내기 위해서는 SQL Server의
tempdb 데이터베이스를 별도의 물리적인 디바이스에 위치시키도록 한다. 커서는 커서 데이터를 임시로 저장
하기 위해서 tempdb를 사용하기 때문이다. 디스크 어레이의 성능이 좋을 수록 커서의 속도도 빨라지게 된다.
[6.5, 7.0, 2000]

*****

커서를 사용하면 병행성(concurrency)이 떨어지기 때문에 불필요한 락킹(locking)과 블로킹(blocking)이 발생
할 소지가 있다. 이 문제를 해결하려면 가능한 READ_ONLY 커서를 사용하도록 하고 만약 수정 작업도 해야 한
다면 락킹을 줄이기 위해서 OPTIMISTIC 커서 옵션을 사용한다. 병행성(concurrency)을 저하시키는
SCROLL_LOCKS 커서 옵션의 사용은 피해야 한다. [6.5, 7.0, 2000]
(마이크로소프트의 추가 정보 : http://msdn.microsoft.com/library/default.asp?
URL=/library/psdk/sql/8_con_07_20.htm)