버젼별로 상이 한데요~~

우선

sybase는

'total memory' 또는 'max memory'로 지정된 범위내에서만 사용을 합니다~~


그리고 data를 읽어와서 메모리에 저장하는 것은 data cache 부분입니다~~


select시 메모리가 이렇게 늘어 나는 것은 뭔가 비정상을 것 같다는 ...


우선 max memory,
allocate max shared memory,
dynamic allocation on demand,
data cache

이 부분 세팅값을 봐야 정확히 알수 있을것 같습니다

일단 확인 해 보셔야 할것이
max memory 의 설정값입니다.
max memory는 단위가 Page이므로
DB Page의 사이즈 또한 확인 해 보시구요...
그 담에 SQL 자체가 소팅을 필요로 하는 건지
확인할 필요가 있구요 : order by group by...등등...
그 담에 질의의 결과를 받는 클라이언트 프로그램은
DB서버와 같은 머신이지 확인 할 필요가 있구요...
그렇다면 그 프로그램이 혹시 페이징을 유발하는지도...
정확한 진단은 질의 후 sp_configure memory 결과를 올려주심이 정확할 듯 합니다. 그라구 작업관리자의 프로세스 탭의 각 프로세스가 차지하는 메모리 사이즈도 첵크해 보세요...
마지막으로 그냥 테이블 풀스캔하는 테이블이면 MRU 케쉬를 쓰도록 힌트 주는것도 방법이겠네요... 

답변 하여 주셔서 감사 합니다 .. 꾸벅..^^
의문좀이 있어서요..

답변1에 대한 답글...

아...어렵네요.. 버젼은 11.9 이에요...

data cashe 부분도 따로 메모리 셋팅이 가능한가요? 가능 하면 방법좀...갈켜주세요..

allocate max shared memory,
dynamic allocation on demand,
 ...각각  어떤역할을 하는 건가요?
------------------------------------------------------------
답변2에 대한 답글..
혹시 메모리 관련하여 윈도우즈와 sybase 사용시 메모리 체크 사항이나..
메모리 사용 접근 방식이나 튜닝 같은거 알수 있는 문서가 있나요?? 자세한 설명좀 부탁드려도 될가요..??

 select 시에는 sql어드벤터지에서 단순 테이블 select만 했어요..
select * from 테이블명. 이렇게만요...
그리구...MRU 힌트가 뭐에요..?  이와 관련 하여 답변이 말로 힘들것 같으면... sybase 참고 문서중 어떤걸 보면 된다는 정도만이라도 ..부탁 드릴께요...꾸벅~

감사합니다..

아~ 어드밴티쥐가 DB서버하구 같은 기계에 설치 되어 질의를 실행하였는가가 포인트구요...만약 그렇다면
SQL 어드밴티쥐이면 이녀석도 메모리를 꽤 차지하겠군요... 조회된 데이터를 스크롤 해서 보여줘야 될테니...
지가 별 수 있겠습니까? 분명 에레이 변수에 결과를 담아
사용자의 스크롤에 대응을 했을테고 결국 많은 메모리를 차지 하겠지요...어드밴티쥐 개발자가 이런 경우에 대비했다면 모르겠지만...
메모리 튜닝 잘 해보실려면 일단 사이베이스 메모리 구조부터 아셔야 할거구...ASE 어드민메뉴얼 1권18장 부터 나오는...아래 그림부터 잘 이해 하셔야 하구
.

 그 담엔 "데이터 캐쉬" 부분이데 요건 어드민 19장과 튜닝 메뉴얼을 보셔야 합니다. Named Cache, Pool의 의미 그리고 각 Cache 의 replacement policy 등 도요.
MRU는 Most Recently Used의 약어로 님같이 조건없는 테이블 풀스캔 조회의 경우 한번 캐슁된 페이지을 한번 쓰고 버린다는 생각으로, 다른 기존의 캐싱된 페이지가 페이지 아웃되는 것을 방지하기 위한 데이터 캐쉬 체인 관리 기법입니다.  LRU와 대비되는 방법이지요.
님의 쿼리에 플랜을 떠 보세요. 그라믄 MRU 캐쉬체인을 사용 했는지 아닌지 보일겁니다.
Select SYNTAX를 보면 뒷분분에 MRU 냐 LRU냐를 지정하는
부분이 있습니다. 

The optimizer may choose the fetch-and-discard (MRU) strategy for:

• Any query that performs table scans

• A range query that uses a clustered index

• A covered query that scans the leaf level of a nonclustered index

• An inner table in a nested-loop join, if the inner table is larger than the cache

• The outer table of a nested-loop join, since it needs to be read only once

• Both tables in a merge join

You can affect the cache strategy for objects:

• By specifying lru or mru in a select, update, or delete statement

• By using sp_cachestrategy to disable or reenable mru strategy

If you specify MRU strategy, and a page is already in the data cache, the page is placed at the MRU end of the cache, rather than at the wash marker.

Specifying the cache strategy affects only data pages and the leaf pages of indexes. Root and intermediate pages always use the LRU strategy.

In select, delete, and update statements

You can use lru or mru (fetch-and-discard) in a select, delete, or update command to specify the I/O size for the query:

select select_list
      from table_name           (index index_name prefetch size [lru|mru])

sp_cacheconfig

The results of sp_cacheconfig look similar to:

Cache Name                Status    Type     Config Value  Run Value
------------------------- --------- -------- ------------ ------------
default data cache        Active    Default        0.00 Mb    59.44 Mb
                                             ------------ ------------
                                    Total          0.00 Mb    59.44 Mb
======================================================================
Cache: default data cache,   Status: Active,   Type: Default
     Config Size: 0.00 Mb,   Run Size: 59.44 Mb
     Config Replacement: strict LRU,   Run Replacement: strict LRU
     Config Partition:            1,   Run Partition:            1

IO Size  Wash Size Config Size  Run Size     APF Percent
-------- --------- ------------ ------------ -----------
    2 Kb   12174 Kb     0.00 Mb     59.44 Mb      10

아 ~ 11.9 면은

max memory는 없을 꺼구 total memory만 있겟네요...

구라구 어드민 책 18장은 12.5 메뉴얼 기준입니다.