데이터 정렬 설정

MSSQL을 설치하다보면 중간단계중에 데이터 정렬 설정을 하는 부분이 나옵니다.

물론 서버, DB단과 테이블을 생성할때 각각의 필드에도 설정할 수 있습니다.

SELECT * FROM ::fn_helpcollations(); -- SQL Server에서 사용 가능한 데이터 정렬 목록을 반환 (Description 포함)

정렬 순서(접미사)
설명
_BIN
(이진) 이진 정렬, 대/소문자와 악센트를 구분, 가장 빠른 정렬 순서
이 옵션을 선택하지 않으면 SQL Server는 관련된 언어 또는 알파벳에 대해 사전에 정의된 정렬 및 비교 규칙을 따릅니다.
이 옵션을 선택하면 대/소문자 구분, 악센트 구분, 일본어 가나 구분 및 전자/반자 구분 옵션을 사용할 수 없습니다.
_BIN2
(이진 코드 포인트) 유니코드 데이터에 대한 유니코드 코드 포인트를 사용하여 SQL Server 테이블의 데이터를 정렬하고 비교합니다.
비유니코드 데이터의 경우 이진 코드 포인트에서는 이진 정렬과 동일한 비교를 사용합니다.
이진 코드 포인트 정렬 순서 사용 시의 이점은 정렬된 SQL Server 데이터를 비교하는 응용 프로그램에서 데이터를 재정렬할 필요가 없다는 점입니다. 결과적으로 이진 코드 포인트 정렬 순서를 사용하면 응용 프로그램을 더 간단하게 개발할 수 있으며 성능이 향상될 수 있습니다. (2005 이상)
이 옵션을 선택하면 대/소문자 구분, 악센트 구분, 일본어 가나 구분 및 전자/반자 구분 옵션을 사용할 수 없습니다.
_CS
(대/소문자 구분) 대/소문자를 구분합니다. 이 정렬 순서를 선택하면 소문자가 대문자보다 먼저 정렬됩니다.
_AS
(악센트 구분) 악센트가 있는 문자와 악센트가 없는 문자를 구분합니다. 예를 들어 'a'는 'ấ'와 같지 않습니다.
이 옵션을 선택하지 않으면 SQL Server는 정렬할 때 악센트가 있는 문자와 악센트가 없는 문자가 동일한 것으로 간주.
_KS
(가나 구분) 일본어 가나 문자의 두 가지 유형인 히라가나와 가타가나를 구분하도록 지정합니다.
이 옵션을 선택하지 않으면 SQL Server는 정렬할 때 히라가나와 가타가나가 동일한 것으로 간주합니다.
_WS
(전자/반자 구분) 같은 문자라도 싱글바이트 문자와 더블바이트 문자를 구분합니다.
이 옵션을 선택하지 않으면 SQL Server는 정렬할 때 싱글바이트와 더블바이트로 표시된 같은 문자를 동일한 것으로 간주


악센트 구분 쿼리 예
SELECT 1 WHERE N'a' COLLATE Korean_Wansung_CS_AI = N'ấ' COLLATE Korean_Wansung_CS_AI
SELECT 1 WHERE N'a' COLLATE Korean_Wansung_CS_AS = N'ấ' COLLATE Korean_Wansung_CS_AS



Windows 데이터 정렬 예

Windows 데이터 정렬 접미사
설명
_BIN 이진 정렬
_BIN2 이진 코드 포인트 정렬
_CI_AI 대/소문자 구분 안 함, 악센트 구분 안 함, 일본어 가나 구분 안 함, 전자/반자 구분 안 함
_CI_AI_KS 대/소문자 구분 안 함, 악센트 구분 안 함, 일본어 가나 구분, 전자/반자 구분 안 함
_CI_AI_KS_WS 대/소문자 구분 안 함, 악센트 구분 안 함, 일본어 가나 구분, 전자/반자 구분
_CI_AI_WS 대/소문자 구분 안 함, 악센트 구분 안 함, 일본어 가나 구분 안 함, 전자/반자 구분

2008에서 달라진 점(한글관련 데이터 정렬관련)
Korean_Wansung_Unicode : SQL Server 2008의 서버 수준에서 더 이상 사용할 수 없음
Korean_90_, Korean_Wansung_ : Korean_100_

참고 URL : http://msdn.microsoft.com/ko-kr/library/ms143515.aspx
http://msdn.microsoft.com/ko-kr/library/ms188046.aspx
http://msdn.microsoft.com/ko-kr/library/ms180175.aspx

DBCC SqlPerf Command

Monitoring SQL 2005 Performance Statistics With The DBCC SqlPerf Command

The SqlPerf Database Consistency Check (DBCC) command most of which is undocumented with the exception of the LogSpace option in the SQL Books On Line (BOL) can be used to monitor the performance statistics of your SQL 2005 database.

Here you will find brief descriptions and examples of each of the DBCC SqlPerf Commands to use on your SQL 2005 server.

DBCC SqlPerf (LogSpace)

The LogSpace option retrieves information about the transaction logs for all of the databases on the server and it writes the following: Database Name, Log Size (MB), Log Space Used (%) and Status.

Example: Exec ('DBCC SqlPerf (logspace)')

DBCC SqlPerf (UmsStats)

The UmsStats option retrieves information for your threads and it writes the following: Statistic and Value which includes statistic information on the following: Scheduler ID, Num users, Num runnable, Num workers, Idle workers, Work queued, Cntxt switches, Cntxt switches(idle), cheduler ID, Num users, Num runnable, Num workers, Idle workers, Work queued, Cntxt switches, Cntxt switches(idle), Scheduler Switches

and Total Work

Example: Exec ('DBCC SqlPerf (UmsStats)')

DBCC SqlPerf (WaitStats)

The WaitStats option retrieves information for the servers resources wait types and it writes the following: Wait Type, Requests, Wait Time and Signal Wait Time

Example: Exec ('DBCC SqlPerf (WaitStats)')

DBCC SqlPerf (IoStats)

The IoStats option retrieves information about your server’s outstanding reads and writes and it writes the following: Statistic and Value which includes statistic information on the following: Reads Outstanding and Writes Outstanding.

Example: Exec ('DBCC SqlPerf (IoStats)')

DBCC SqlPerf (RaStats)

The RaStats option retrieves information about your servers read-ahead statistics and it writes the following: Statistic and Value which includes information on the following: RA Pages Found in Cache, RA Pages Placed in Cache, RA Physical IO and Used Slots

Example: Exec ('DBCC SqlPerf (RaStats)')

DBCC SqlPerf (Threads)

The Treads option retrieves information for the server’s currently running threads and writes and it writes the following: Spid, Thread ID, Status, LoginName, IO, CPU and MemUsage

Example: Exec ('DBCC SqlPerf (Threads)')

ETC : DBCC SqlPerf(spinlockstats)

DBCC SqlPerf(netstats)

DBA가 주기적으로 수행해야 하는 작업

DBA가 주기적으로 수행해야 하는 작업
시스템에 따라 차이가 있을 수 있지만, DBA는 시스템 유지를 위하여 일반적으로 수행해야 하는 작업들에 대하여 이해하고 있어야 하며, 다음과 같은 작업들을 주기적으로 수행해야 합니다.

■ 일 단위로 수행해야 하는 작업
표준화는 관리에 있어서 매우 중요한 요소입니다. 자신의 시스템에 가장 적합한 표준화체계를 수립하고, 전체 시스템에 대하여 표준화된 관리 체계를 적용하여 관리해야 합니다.
다중의 DB 서버를 관리하는 경우에는 표준화가 특히 중요합니다.

• 시작되어야 할 서비스들이 제대로 시작되어 있는지 확인합니다.
• Windows NT 또는 Windows 2000의 이벤트 뷰어를 사용하여 오류 발생 여부를 점검
합니다.
• SQL Server 오류 로그에 오류 메시지가 기록되어 있는지 점검합니다. 자세한 내용은
[SQL Server 오류 로그 보기]를 참조하십시오.
• 데이터베이스 파일과 로그 파일의 확장에 대비하여 디스크에 충분한 여유 공간이 있
는지 확인합니다.
• 데이터베이스 파일과 로그 파일의 크기와 실제로 사용되는 공간을 모니터링하며, 공
간 부족으로 자동 확장이 예상되는 경우에는 미리 파일을 확장하여 충분한 공간을 확
보합니다.
• SQL Server 작업(Job)의 성공/실패 여부를 점검합니다.
• 매일 데이터베이스 전체 백업 또는 차등 백업을 수행하기로 되어 있는 경우라면, 데이
터베이스 전체 백업을 수행합니다. 자동화되어 있는 경우에는 백업이 성공적으로 수
행되었는지 점검합니다. 데이터베이스 전체/차등 백업 주기는 시스템 여건과 복원 전
략에 따라 달라집니다.
• SQL Server 트랜잭션 로그를 백업 받습니다. 자동화되어 있는 경우에는 백업이 성공
적으로 수행되었는지 점검합니다. 백업 주기는 시스템 여건에 따라 분 단위, 시간 단
위, 일 단위로 달라질 수 있으며, 트랜잭션 백업 주기에 따라 트랜잭션 로그 파일의 적
정 크기가 달라집니다. 참고로 복원이 불필요한 테스트 DB에 대해서는 복구 모델을
단순으로 설정하면 트랜잭션 로그에 대한 주기적인 관리를 줄일 수 있습니다.
• Master, model, msdb, 배포(distribution) 데이터베이스도 변경 사항이 있으면 주기적
으로 백업해야 합니다. 시스템 카탈로그의 변경이 이루어진 후에는 master 데이터베
이스의 전체 백업을 수행합니다. 경고, 작업(Job), 운영자, 로그 전달(log-shipping),
복제, DTS 패키지 등에 변경이 발생한 다음에는 msdb를 백업해야 합니다. Model 데이
터베이스에 변경작업을 수행한 다음에는 model을 백업해야 합니다.
• 시스템 모니터를 사용하여 성능 카운터를 모니터링함으로써, 적절한 성능이 유지되고
있는지 점검합니다. 최소한 시스템 모니터에서 프로세서, 메모리, 디스크(I/O), 네트워
크에 대한 카운터들은 필수로 점검해야 합니다. 문제 발생 시 또는 추가적인 분석이
필요한 경우에는 관련 성능 카운터들을 추가로 분석합니다.
• 복구 모델이 전체 복구가 아니라면, 최소 로깅 작업(Minimal-logged operation)을 수행
한 다음에는 차등 백업을 수행합니다.
블로킹, 교착상태(Deadlock)의 발생 여부를 점검합니다.
• 오래 수행되는 쿼리 또는 리소스를 과다하게 사용하는 쿼리가 있는지 점검합니다.
문제가 발생하면 문제 해결을 위한 활동을 수행하며, 문제 분석 및 해결 과정에 대한
내용을 가능한 한 상세하게 문서화합니다.
• 통계 자동 갱신(Auto update statistics) 옵션이 비활성화되어 있는 데이터베이스의 테
이블들에 대해서는 주기적으로 (예:매일, 매주) UPDATE STATISTICS 작업을 수행합니다.


■ 주간 단위로 수행해야 하는 작업

• 모든 시스템 데이터베이스와 운영중인 사용자 데이터베이스에 대한 전체/차등 데이
터베이스 백업을 수행합니다.
• 통계 자동 갱신(Auto update statistics) 옵션이 비활성화되어 있는 데이터베이스의
테이블들에 대해서 UPDATE STATISTICS를 매일 또는 매주 수행합니다.
• 인덱스의 조각화를 제거합니다. CREATE INDEX WITH DROP_EXISTING 또는 DBCC
DBREINDEX를 수행하여 인덱스를 재구성함으로써 물리적, 논리적 조각화를 제거할 수
있으며, DBCC INDEXDEFRAG를 사용하면 논리적인 조각화를 제거할 수 있습니다. 자세한
내용은 온라인 설명서를 참조하십시오.
• 대형 일괄 처리의 작업 등으로 인하여 로그 파일이 과다하게 확장된 경우에는 로그
파일의 사용되지 않는 여분의 공간을 제거합니다.


■ 월간 단위로 수행해야 하는 작업

• 전체 운영 체제를 백업합니다.
• 최소 월 1회 모든 시스템 데이터베이스와 운영 데이터베이스에 대하여 전체 백업을
수행해야 합니다.
• DBCC CHECKDB를 수행하여 데이터베이스의 무결성을 점검합니다. DBCC
CHECKDB를 수행하면 서비스나 다른 작업에 영향을 미칠 수 있으므로, 테스트 장비
에 모든 시스템 데이터베이스와 운영 데이터베이스를 복원하고, 복원된 모든 시스템
데이터베이스와 운영 데이터베이스를 대상으로 DBCC CHECKDB를 수행하여 무결
성을 점검하는 것이 바람직합니다.
• Sqldiag.exe를 수행하고 결과를 저장합니다.
• 성능 데이터를 수집하여 시스템이 충족시켜야 하는 기준과 비교하여, 성능 향상 및 향
후의 용량 계획에 활용합니다.


[참고] 정확한 점검을 위해서는 모든 유지 관리 활동 작업에 대하여 로그를 저장하는 것 이 필요합니다. 데이터베이스 유지 관리 계획 마법사와 SQL Server 작업(Job)에서는 자동으로 작업 결과를 저장하도록 설정 가능합니다.

프로시져 캐쉬 증가 조회

Procedure cache in SQL Server 2005

Posted by decipherinfosys on September 19, 2007

In one of our previous post, we had covered the importance of using bind variables (parameterized queries). In response to that post, one of the readers asked whether it is possible to look at what is available in the memory for the RDBMS. Yes, it is pretty easy to get to that information. In this post, we will cover how to do that in the case of SQL Server 2005 and then will cover Oracle and DB2 LUW in future posts. In the case of SQL Server, memory is used for buffer cache (storing the data) and procedure cache (storing the query plans). The cache is stored as 8KB pages (Oracle has more options on this size). Let’s see how we can find out what is in the procedure cache and how often those plans are getting used.

In SQL Server 2005, there is a DMV that can be used to get this information – the SQL is shown below:

SELECT top 5
name,
type,
(single_pages_kb + multi_pages_kb) AS cache,
entries_count as cnt
FROM sys.dm_os_memory_cache_counters
ORDER BY cache desc

On our test system, this is the output:

name                     type                   cache                cnt

------------------------ ---------------------- -------------------- ------

Object Plans             CACHESTORE_OBJCP       24352                46

Bound Trees              CACHESTORE_PHDR        20648                252

SQL Plans                CACHESTORE_SQLCP       19432                292

TokenAndPermUserStore    USERSTORE_TOKENPERM    14488                31167

SchemaMgr Store          USERSTORE_SCHEMAMGR    10584                0

If you see the output from above, you will see CACHESTORE_OBJCP, CACHESTORE_PHDR and CACHESTORE_SQLCP as the top three cache related enteries. Each has it’s own importance. CACHESTORE_OBJCP represents the compiled plans for stored procedures, triggers and functions, CACHESTORE_SQLCP represents cached SQL statements and batches that are not part of stored procedures/triggers/functions and CACHESTORE_PHDR represents the parsed SQL text. On our test system, we have a few stored procedures that are used by the test harness and there are a lot of dynamic SQL queries that are fired off by the test application that uses an ORM layer. That is why the count for CACHESTORE_OBJCP is 46 and CACHESTORE_SQLCP count is 305.

While I was writing this post, a colleague of mine also pointed out that all this information is also available through the performance monitor. Here is an image that shows you which counter you can use to get that information:

Once you get the counts, the next logical step is to look for the actual queries that are in the system cache. In order to do that, we will make use of two more DMV’s in SQL Server 2005 and will make use of the new “OUTER APPLY” functionality:

SELECT
cache_plan.objtype,
cache_plan.size_in_bytes,
cache_plan.cacheobjtype,
cache_plan.usecounts,
sql_text.text
FROM sys.dm_exec_cached_plans as cache_plan
outer apply sys.dm_exec_sql_text (cache_plan.plan_handle) as sql_text
ORDER BY cache_plan.usecounts DESC

One can look at the output and see how much space is being occupied by different plans. Since SQL Server does not provide a configuration option to put a cap on the procedure cache, if the application is not using parameterized queries, you will see this cache to be blotted. Hopefully, like Oracle, Microsoft can also provide a configuration option in the future to keep that in check – of course, there is no alternative to a well designed application however, as consultants brought in to tune the environment in production, re-design or fixing the fundamental building blocks of the application is rarely an option that we have.

Procedure Cache Bloating issues – I

Posted by decipherinfosys on December 4, 2008

We had covered in one of our posts before how the usage of non parameterized adhoc SQLs in an application can create performance issues by bloating the procedure cache and lamented the fact that in SQL Server there is no parameter setting to help take control of the cache (unlike Oracle which does provide you a lot of control). You can access those posts here:

• Procedure Cache in SQL Server 2005
• Bind Variables/Parameterized Queries in SQL Server
• 64 bit vs 32 bit – covers the memory advantages.

So, if you are new to a project and/or you do not know the current application well enough, how can you easily tell whether the applications hitting your production system are running into this issue of procedure cache bloating because of in-efficient code? Use this query to get that information:

SELECT
OBJTYPE AS PLAN_TYPE,
COUNT(*) AS PLAN_NUMBERS,
(SUM(CAST(SIZE_IN_BYTES AS BIGINT))/1024)/1024 AS SIZE_MB,
AVG(USECOUNTS) AS USE_COUNT
FROM SYS.DM_EXEC_CACHED_PLANS
GROUP BY OBJTYPE

PLAN_TYPE            PLAN_NUMBERS SIZE_MB              USE_COUNT
-------------------- --------------- -------------------- -------------
UsrTab               15              0                    20
Prepared             8319            891                  9
View                 694             60                   13
Adhoc                28794           1307                 6
Check                18              0                    17
Trigger              1               0                    8
Proc                 162             78                   134

(7 row(s) affected)

If you see above, you will see that in the PLAN_TYPE of “Adhoc”, the number of plans are huge and they also are taking up the most memory. Their use counts are very low as well. This is a clear indication of the issue that the system is facing. How to fix it? Besides fixing the application to write good parameterized code, you can also looking into the setting the “Forced Parameterization” option in SQL Server 2005. In SQL Server 2008, there is another instance level parameter “Optimize for Adhoc Workloads” which we will cover in Part II of this post.

So, is there any way to stop the bleeding without clearing up the entire cache? There is a way in SQL Server 2005. One can use the following command to clear out the adhoc and prepared plan types but still keep the Proc plan type intact in the cache.

DBCC FREESYSTEMCACHE(‘SQL Plans’)

PLAN_TYPE            PLAN_NUMBERS SIZE_MB              USE_COUNT
-------------------- --------------- -------------------- -------------
UsrTab               15              0                    20
View                 694             60                   13
Adhoc                1               0                    1
Check                18              0                    17
Trigger              1               0                    8
Proc                 162             78                   134

(6 row(s) affected)

Post the execution of the command, you can see from the output from above, the selective removal of the two enteries in the Procedure Cache. Procedure cache consists of different cache stores and it is possible to selectively remove some of those from the cache. You can read more about the different cache stores and the meta data queries to understand the plan cache behavior at this post on MSDN or this post on sqlteam.com.

Now, once the immediate bleeding has been stopped by running the command, what else can you do – we had mentioned the Forced Parameterization option above. You can set it at the database level by using the “ALTER DATABASE” command or via the GUI as well (search the BOL for Forced Parameterization and you will get the steps to do so). This forces the parameterization for the values in the adhoc SQL queries submitted by the applications. Only under certain scenarios like this one it is advisable not to use parameterization but otherwise in all the OLTP based applications, one should strive to have parameterized queries – the benefits are listed in one of the posts the link of which is given above. This is useful in those scenarios when you are asked to manage a vendor application and do not have much control over the application code – this option as well as plan guides are your best options in those scenarios.

In the next post, we will cover the new SQL Server 2008 parameter which kinda/sorta lets you have some more control on the procedure cache.

Procedure 내용으로 검색하기

SELECT routine_name, routine_definition
FROM information_schema.routines
where routine_definition like '%%'

SP_READERRORLOG

Problem
One of the issues I have is that the SQL Server Error Log is quite large and it is not always easy to view the contents with the Log File Viewer. In a previous tip "Simple way to find errors in SQL Server error log" you discussed a method of searching the error log using VBScript. Are there any other easy ways to search and find errors in the error log files?

Solution
SQL Server 2005 offers an undocumented system stored procedure sp_readerrorlog. This SP allows you to read the contents of the SQL Server error log files directly from a query window and also allows you to search for certain keywords when reading the error file. This is not new to SQL Server 2005, but this tip discusses how this works for SQL Server 2005.

This is a sample of the stored procedure for SQL Server 2005. You will see that when this gets called it calls an extended stored procedure xp_readerrorlog.

CREATE PROC [sys].[sp_readerrorlog]( @p1 INT = 0, @p2 INT = NULL, @p3 VARCHAR(255) = NULL, @p4 VARCHAR(255) = NULL) AS BEGIN IF (NOT IS_SRVROLEMEMBER(N'securityadmin') = 1) BEGIN RAISERROR(15003,-1,-1, N'securityadmin') RETURN (1) END IF (@p2 IS NULL) EXEC sys.xp_readerrorlog @p1 ELSE EXEC sys.xp_readerrorlog @p1,@p2,@p3,@p4 END

This procedure takes four parameters:

1. Value of error log file you want to read: 0 = current, 1 = Archive #1, 2 = Archive #2, etc...
2. Log file type: 1 or NULL = error log, 2 = SQL Agent log
3. Search string 1: String one you want to search for
4. Search string 2: String two you want to search for to further refine the results

If you do not pass any parameters this will return the contents of the current error log.

Here are a few examples:

Example 1

EXEC sp_readerrorlog 6

This statement returns all of the rows from the 6th archived error log.

Example 2

EXEC sp_readerrorlog 6, 1, '2005'

This returns just 8 rows wherever the value 2005 appears.

Example 3

EXEC sp_readerrorlog 6, 1, '2005', 'exec'

This returns only rows where the value '2005' and 'exec' exist.

---

xp_readerrrorlog

Even though sp_readerrolog accepts only 4 parameters, the extended stored procedure accepts at least 7 parameters.

If this extended stored procedure is called directly the parameters are as follows:

1. Value of error log file you want to read: 0 = current, 1 = Archive #1, 2 = Archive #2, etc...
2. Log file type: 1 or NULL = error log, 2 = SQL Agent log
3. Search string 1: String one you want to search for
4. Search string 2: String two you want to search for to further refine the results
5. Search from start time
6. Search to end time
7. Sort order for results: N'asc' = ascending, N'desc' = descending

EXEC master.dbo.xp_readerrorlog 6, 1, '2005', 'exec', NULL, NULL, N'desc' EXEC master.dbo.xp_readerrorlog 6, 1, '2005', 'exec', NULL, NULL, N'asc'

---

Next Steps

• As you can see this is a much easier way to read the error logs and to also look for a specific error message without having to use the Log File Viewer.
• Add this to your monitoring routine where this is run daily to search for errors or issues.

Readers Who Read This Tip Also Read

• How to setup SQL Server alerts and email operator notifications
• Script to determine free space to support shrinking SQL Server database files
• Methods to determine the status of a SQL Server database
• Collecting SQL Server database usage information for free space and trending
• Listing SQL Server Object Dependencies
• More...

성능카운트 임계치 참고고

-----------
디스크 튜닝
-----------
[RAID 0]
Physical Disk: Disk Reads/sec + Disk Write/sec / Disk count < 100

[RAID 1]
Physical Disk: Disk Reads/sec + (2 * Disk Write/sec) / 2 < 100

[RAID 10]
Physical Disk: Disk Reads/sec + (2 * Disk Write/sec) / Disk count < 100

[RAID 5]
Physical Disk: Disk Reads/sec + (4 * Disk Write/sec) / Disk count < 100

Physical Disk: Avg. Disk Queue Length
:Avg. Disk Queue Length/Disk Count < 2

Physical Disk: Avg. Disk sec/Read < 15 msec
Physical Disk: Avg. Disk sec/Write < 12 msec

-----------
메모리 튜닝
-----------
Memory: Available MBytes(1MB 1048576Btye)
:프로세스가 실제 사용할 수 있는 메모리양

Memory: Pages/sec
:디스크에서 메모리로 Page in되는 초당 페이지수
이수치가 많다면 SQL Server에 많은 메모리가 할당된 것임.
다른 응용프로그램이 실행되기 위해 페이징발생 우려.
아래의 Stolen Pages와 같이 확인

SQL Server: Buffer Manager: Stolen Pages
:캐시로부터 제거된 페이지수

SQL Server: Memory Manager: Total Server Memory(KB)
:SQL Server가 할당한 전체 메모리양

SQL Server: Memory Manager: Procedure Cache Pages
:컴파일된 쿼리와 저장 프로시저를 저장한 Cache의 페이지수

SQL Server: Buffer Manager: Free Page
:SQL Server가 사용할 수 있는 페이지 수
5MB이상이어야 함. 5MB이하이면 메모리 부족.

SQL Server: Buffer Manager: Buffer Cache Hit Ratio
:90 이상이어야 함

Process: Working Set
:프로세스 내의 스레드가 최근에 사용한 적이 있는 메모리 바이트수
프로세스가 더이상 실행되지 않는데 워킹 셋이 줄지 않으면 프로세스가
메모리를 해제하지 않는 것임(메모리 추가)

Process: Page Faults/sec
:프로세스가 Cache Hit하지 않은 페이지수

-------------
프로세스 튜닝
-------------
Process: % Processor Time < 100

System: Process Queue Length
:프로세서를 얻기위해 프로세서 큐에서 대기한 스레드 수
2 * 프로세스수 < Process Queue Length

System: Context Switches/sec < 10000

----
기타
----
SQL Server: General Statistics: User Connections
:SQL Server의 현재 연결 수

SQL Server: Locks: Lock Timeouts/sec
:Lock Time out에 걸린 잠금 수

SQL Server: Locks: Lock Waits/sec
:잠금대기 요청수

SQL Server: Number of Deadlocks/sec
:데드락 잠금 수
SET DEADLOCK_PRIORITY LOW 설정으로 SQL Server가
데드락 에러(1205) 반환

SQL Server: Memory Manager: Memory Grants Pending
:메모리를 사용하기 위해 대기하고 있는 프로세스 수

SQL Server: Memory Manager: Target Server Memroy(KB)
:SQL Server가 사용할 수 있는 전체 메모리양

SQL Server: Memory Manager: Total Server Memory(KB)
:SQL Server가 사용하고 있는 전체 메모리양

SQL Server: Database: Log Flush Waits/sec
:Log Flush를 대기하는 데이터베이스 커밋수

SQL Server: Database: Percent Log Used
:Log File의 증가, 잘림을 볼 수 있다.