나는 DBA다.. DBA라서 ........

그녀에게 '올인'하지 마라…"놔주는 사랑을 해봐"

JeFFreY — Sat, 27 Dec 2008 15:21:16 GMT

애인과 교제한지 2년 되는 K씨. 모처럼 친구가 저녁이나 하자고 전화를 했지만, 선약이 있다고 거절했다.

딱히 약속이 있는 건 아니었지만, 애인과 새로 개봉한 영화를 같이 볼까, 하던 차였다. 연애를 시작한 후 K씨의 생활에는 애인 단 한사람뿐이다. 백화점을 가면 남성 용품만 눈에 보이고, 좋은 게 있으면 애인한테 해주고 싶어 안달이다.

문제는 애인에게도 자신처럼 하기를 강요한다는 것이다. 회식이나 중요한 약속이 있어 데이트를 미루면 난리가 난다. 애인이 자기 마음에 안드는 말이나 행동을 하면 무척 서운해한다. ‘내가 너한테 얼마나 잘하는데, 그럴 수 있느냐?’는 식이다.

K씨에게 사랑은 올인하는 것이다. 그렇다면 그런 사랑을 받는 그녀의 애인은 과연 행복할까? 그녀는 사랑하는 것이 아니라 잘해주는 것이다. 사랑하는 것과 잘해주는 것은 반드시 일치하지는 않는다. 사랑하면 잘해줄 수도 있지만, 잘해주는 것이 사랑은 아니다.

진정한 사랑은 강요하기보다는 놓아주는 것
많은 남녀들은 뭐든 아낌없이 줘야 하고, 부르면 언제든 달려가야 하고, 다소 과하다는 생각이 들어도 비싼 물건을 살 수 있어야 하고, 사랑하면 이런 것쯤은 당연하다고 생각한다. 하지만 그것은 사랑하는 것이 아니라 잘해주는 것이다.

사랑은 이런 것이다. 함께 행복할 수 있는 방법을 찾아 노력하는 것, 상대에게 완벽한 사랑을 주려고 자신을 버리는 것이 아니라 불완전한 두 사람이 함께 사랑을 완성해가는 것, 내 방식을 상대에게 강요하기보다는 서로의 방식을 인정하는 것, 구속하거나 집착하지 말고, 때로는 그냥 놓아주는 것, 사랑하면 이런 마음이 들게 된다.

잘해주는 것은 본전심리가 작용한다. 잘해주는 것은 분명 끝이 있다. 내가 잘하는 만큼 상대도 잘해주기를 원하게 된다. 잘해준다는 생각이 들면 상대에게 당당해진다.

하지만 사랑하는 것은 그 자체로 이미 충만한 마음이 든다. 상대가 아니라 내 사랑에 당당해진다. 물론 사랑하는 것 역시도 상대의 사랑을 갈구하게 되지만, 그것은 준만큼 받으려는 본전심리라기보다는 사랑받고 싶은 마음의 발로이다.

댓가 없이 하는 사랑을 즐기라
레바논의 작가 칼릴 지브란의 유명한 저서 <예언자> 중에는 결혼에 대한 이런 대목이 있다. 「...서로 사랑하라. 그러나 사랑에 구속되지는 말라...그대들의 마음을 주라. 그러나 서로가 지니지는 말라...함께 서라. 그러나 너무 가까이 함께 하지 말라...」
구속하고 강요하면 더 원하게 되고, 너무 가까이 있으면 상대의 그늘에 덮여 자기 자신을 잃게 된다. 지브란의 말처럼 사랑하는 두 사람은 서로 떨어져 서있는 사원의 기둥들이고, 함께 울리되, 따로 있는 기타줄이다.

이제부터는 이렇게 사랑해보라. 애인을 내 생활에 끌어들이려고만 하지 말고, 내가 애인의 생활에 끼어들려고만 하지 말고, 두 사람은 서로 떨어져서 각자 생활하는 개개인이라는 것을 인정하고, 혼자만의 시간을 존중해주는 것이다. ‘내가 얼마나 잘하는데..’하며 티내지 말고, 말없이, 댓가 없이 하는 사랑을 즐기는 것이다.

그렇게 하면 두 사람이 받치고 있는 사랑이라는 사원은 흔들림 없이 서있을 것이고, 두 개의 기타줄은 아름다운 선율을 만들어낼 것이다.
이웅진 대표는 결혼정보회사 선우의 CEO로 우송정보대학 웨딩이벤트학과 겸임교수를 지냈으며, 현재 한국결혼문화연구소 소장을 겸임하고 있습니다.

DeadLock Test

JeFFreY — Wed, 17 Dec 2008 01:23:35 GMT

-- Session #1

BEGIN TRAN

UPDATE pubs.dbo.sales SET qty=0
UPDATE pubs.dbo.titles SET price=0

ROLLBACK TRAN

-- Session #2

BEGIN TRAN

UPDATE pubs.dbo.titles SET price=0
UPDATE pubs.dbo.sales SET qty=0

ROLLBACK TRAN

성능 모니터링 툴의 권장 수치

JeFFreY — Tue, 16 Dec 2008 10:10:22 GMT

성능 모니터링 툴의 권장 수치 [출처:http://databaser.net/]

-----------
디스크 튜닝
-----------
[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의 증가, 잘림을 볼 수 있다.

tag : SQL, 모니터링, 성능

영원하리라 상상했던 영원을 잃었다.

JeFFreY — Tue, 16 Dec 2008 08:14:33 GMT

영원하리라 상상했던 영원을 잃었다.

한 가닥 끈나플을 잡고 아슬아슬 한발 한발 내딛던 시간이 끝났다.

돌아갈 수도 없겠거니와 돌아 갈 맘이 들지 않는다.

그렇게도 되뇌여 고뇌했던 기억이 사실이 되었다.

무엇을 얻었고 또 잃었는가...

이제는 두려워질때도 됐으련만 무엇이 붙들고 있는걸까

불꺼진 어둔 방이 싫었던 그리고 찬바람 가득차있는 내 방이 싫어서

붙들었던것만은 아니었다.

의심과 오해로 그리고 상충으로 ... 눈물과 상처로 얼룩진 원망과 미움의 결실

그것이 우리의 사랑이었나 보다.

좋았던 기억은 지워진지 오래요 그 기억을 끄집어 내려 노력해도

너역시 나역시 변함을 기대하기란 너무도 많은 상처속에 파묻혔나 보다

Bye~ 영선

힘듦의 안부

JeFFreY — Mon, 15 Dec 2008 10:51:54 GMT

힘듦은 언제나 안부를 묻지 않는다.

적어도 내게는 찾아올 때에는 아무 기척없이 찾아오곤 하더라.

나의 힘듦이 너의 행복인것이냐 묻고 싶다.

날 이렇게 힘들게 하면 너는 힘들지 않더냐 뭐가 그리도 부족해 더 무엇을 네게

내어주어야 넌 나를 힘듦으로 부터 자유롭게 해줄 것이냐

정말 묻고싶다. 하지만 넌 들으려 하지 않고 시선주려 하지 않는다.

그래 세상의 모든 잘못이 내가 원인이고 보잘것 없는 내 인생이라 할 지언정

너에 대한 사랑앞에 무릎꿇고 흐느껴 우는 모습이 안스럽지도 않더냐

난 너의 모든 힘듦을 내가 감싸 안으려는데 그것조차도 네게 사치로 보이더냐

진정 너의 정신을 알 수 없고 알아낼 수 없어 답을 모르겠기에 난 또 이리 좌절 하였다.

거리에서

JeFFreY — Mon, 15 Dec 2008 10:50:59 GMT

거리에서

너와난 얼마나 가까이 있을까

다가가는 나와 멀어지는 너와

다가옴이 겨운 나와 멀어짐에 익숙한 너와

좁히려 좁히려 둘 중 하나는 애를 쓰는듯

느껴지지 않는 너와 부족한 나와

너와난 얼마의 거리를 두고 있는 것일까.

힘듦의 안부 처럼

처음에서의 나처럼 그리도 우리도

여느 평범한 그들과 그이들 처럼

함께하기엔 너무도 먼 거리를 두고 있는 것일까

너의 힘듦과 내가 감싸안으려 함이

언제나 초라함이 느껴지지 않을 만큼만

너의 생각에 서고 너의 가슴을 누리고자

또다시 거리가 먼 내 눈을 따뜻히 하고 있구나...

SQL Compilation

JeFFreY — Thu, 11 Dec 2008 05:25:09 GMT

During compilation, the compiler expands the statements by including the relevant
constraints, triggers, and cascading actions that have to be carried out during the
statement execution.

If the compiled batch contains invocations of other stored procedures or functions
and their plans are not in the cache, the stored procedures and functions are recursively
compiled as well.

처리순서
Execution Plan이캐쉬에있으면쿼리를곧바로수행한다
실행계획이없으면, Batch를Compile하여Query plan을만든다.

Compile 단계는Parsing과Binding 과정을거치게된다.

Parsing : 구문분석
Binding : Schema 정보 확인

Parsing is the process of checking the syntax and transforming your SQL batch into
a parse tree.

Parsing 단계에서는 테이블 이름이나 컬럼 이름에 사용할 수 없는 문자가 있는지 등을 체크 한다.
Where절에 사용된 컬럼이 FROM에있는 테이블에 있는지를 체크 하지는 않는다.
이 작업은 Binding 단계에서 수행 한다.

Binding 단계에서는 요청한 작업이 수행 가능한지 체크 한다.
For example, while a query including FROM A JOIN B may be parsed successfully,
binding will fail if A is a table and B is a stored procedure.

Optimization이 컴파일의 마지막 단계이며, 집합 기반의 비절차적인 쿼리(Nonprocedural)를
절차 적인 문장(Procedure)으로만든다.

Algebrizer

JeFFreY — Thu, 11 Dec 2008 05:10:39 GMT

  Parse tree를 입력으로 받아 처리하여 query processor tree라는 결과를 만들냄

SQL Server 2005의새로운컴포넌트

Binding is its most important function

The algebrizer replaces the normalizer in SQL Server 2000

Operator Flattening
    Stack over-flow 방지

Name Resolution
    catalog information에서Name resolution 작업

Type Derivation

SQL Reference Site

JeFFreY — Wed, 10 Dec 2008 08:37:34 GMT

SQL Magazine                                    Database Journal

Kalen Delaney                                   SQL Server Performance

필라넷 김정선님 블로그                          한국MS 한기환님 블로그

SQL Server Best Practices                    SQL Server Developer Center

MS SQL Svr. Community World Wide      SQL Leader

What Query Plans are in SQL Server's Memory?

JeFFreY — Tue, 09 Dec 2008 07:44:52 GMT

Written by Bill Graziano on 25 July 2007 Tagged with Memory Tuning

SQL Server memory is primarily used to store data(buffer) and query plans(procedure cache).
In this article I'll show how much memory is allocated to the procedure cache (RAM).
I'll explain how to determine what plans are in the cache and how often they're used.

SQL Server stores the procedure cache in 8KB data pages.
You can use the dynamic management view sys.dm_os_memory_cache_counters
to provide a summary of how the cache is allocated using this query:

SELECT TOP 6
        LEFT([name], 20) as [name],
        LEFT([type], 20) as [type],
        [single_pages_kb] + [multi_pages_kb] AS cache_kb,
        [entries_count]
FROM sys.dm_os_memory_cache_counters
order by single_pages_kb + multi_pages_kb DESC

name                 type                  cache_kb             entries_count
-------------------- -------------------- -------------------- --------------------
SQLPlans             CACHESTORE_SQLCP     669880               9613
Object Plans         CACHESTORE_OBJCP      14120                97
Bound Trees          CACHESTORE_PHDR       3288                 63
SchemaMgr Store      USERSTORE_SCHEMAMGR   2544                 0
mssqlsystemresource  USERSTORE_DBMETADATA 2080                 241
sqlteam              USERSTORE_DBMETADATA 728                  302
. . . . .

On the server that hosts SQLTeam.com this query actually returns 75 rows.
The server has 2GB of RAM with 1GB allocated to SQL Server 2005 Express Edition.
This article will focus on the first three rows in this query. These are:

CACHESTORE_OBJCP. These are compiled plans for stored procedures,
functions and triggers.
CACHESTORE_SQLCP. These are cached SQL statements or batches
                                    that aren't in stored procedures, functions and triggers.
                                    This includes any dynamic SQL or raw SELECT statements
                                    sent to the server.
CACHESTORE_PHDR. These are algebrizer trees for views, constraints and defaults.
                                   An algebrizer tree is the parsed SQL text that resolves the table
                                   and column names.

Algebrizer trees. The query optimizer does not directly act on raw query text;
it needs a more structured input. The Algebrizer's job is to produce an algebrizer tree,
which represents the logical structure of a query. As part of this process, the Algebrizer
performs tasks like resolving table, column, and variable names to particular objects in the
database.
It also determines the data types of any expressions in the query. In SQL Server 2000,
what I call an algebrizer tree may also be referred to as a normalized tree or a parse tree.
Because algebrizer trees are used only during query compilation,
they are usually not cached.
After all, what's the point of caching an algebrizer tree once you have a compiled plan
that you can reuse for any subsequent executions? Algebrizer trees for views, defaults,
and constraints, however, are an exception to this rule.
They are cached because a view may be referenced by many different queries.
Caching the view's algebrizer tree prevents SQL Server from repeatedly having to parse
and algebrize the view every time another query is compiled that references the view.

Notice that there are very few compiled plans for stored procedures (CACHESTORE_OBJCP).
This should work out to about one plan per active stored procedure on the server.
Also notice that there are lots and lots of plans for dynamic SQL on the server (CACHESTORE_SQLCP).
The forum software on the site doesn't use stored procedures.
The SQL statements it generates go into the SQL plan cache.

You can monitor the number of data pages in the plan cache using Performance Monitor
(PerfMon) using SQLServer:Plan Cache object with the Cache Pages counter.

There are instances for SQL Plans (CACHESTORE_SQLCP), Object Plans (CACHESTORE_OBJCP) and Bound Trees (CACHESTORE_PHDR).

We can see individual cache entries by using the sys.dm_exec_cached_plans
dynamic management view.

SELECT usecounts, cacheobjtype, objtype, plan_handle
FROM sys.dm_exec_cached_plans

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

usecounts cacheobjtype   objtype  plan_handle
--------- -------------- ------- ---------------------------------------------------
23133     Compiled Plan  Proc     0x05000600E969C702B861712D000000000000000000000000
6193      Compiled Plan  Adhoc    0x060005009D7DB935B841F141000000000000000000000000
6192      Compiled Plan  Trigger  0x05000500E9DB0F6BB8E13359000000000000000000000000
6192      Compiled Plan  Proc     0x0500050047E57235B8C1560F000000000000000000000000
6097      Compiled Plan  Adhoc    0x06000500992FE330B8C16E59000000000000000000000000
6082      Compiled Plan  Adhoc    0x06000500EFE7B508B861CD0D000000000000000000000000
5818      Compiled Plan  Trigger  0x050005003FB5C870B8614559000000000000000000000000
4864      Compiled Plan  Prepared 0x06000500F264B12FB8412F2B000000000000000000000000
4850      Compiled Plan  Prepared 0x0600050017A8CC01B8812B48000000000000000000000000
3385      Compiled Plan  Proc     0x05000500099CB87DB801A449000000000000000000000000
884       Parse Tree     View     0x0500FF7FC1010000C800130D000000000000000000000000
. . . . .

This query lists the most used query plans.
In includes plans for stored procedures, adhoc or dynamic SQL, triggers, prepared SQL and views.
If we want to see the SQL associates with these plans like need to use
the sys.dm_exec_sql_text dynamic management function like this:

select TOP 100
        objtype,
        p.size_in_bytes,
        LEFT([sql].[text], 100) as [text]
from sys.dm_exec_cached_plans p
outer apply sys.dm_exec_sql_text (p.plan_handle) sql
ORDER BY usecounts DESC

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

objtype size_in_bytes  text
------- -------------  ---------------------------------------------------------Proc    172032         CREATE PROC [dbo].[subtext_GetSingleEntry]....
Adhoc   24576          SELECT F_PRIVATEFORUMS, F_SUBJECT, F_PASSWORD_NEW ....
View    73728          CREATE VIEW [dbo].[sqlteam_Article_View] AS...
Proc    4251648        CREATE PROCEDURE [BMP_proc_RetrieveBannerFromZoneSite]...
Proc    425984         CREATE PROC [dbo].[sqlteam_Article_Read_ByPageName]...

I manually pulled a few rows from the result set to highlight the type of results this
query generates.

Notice that the compile query plans are BIG. One listed in over 4MB.
There many of them that are roughly 400KB.
If you do a little math on the first result set in this article you'll see the average SQL plan
is just under 70KB and the average stored procedure plan is 145KB.
SP. tend to encapsulate more complex statements so that doesn't surprise me.

This should give you enough information to go through your query plans and see what's
being used, what's rarely used and how much space they take up.