database.sarang.net
UserID
Passwd
Database
DBMS
MySQL
PostgreSQL
Firebird
ㆍOracle
Informix
Sybase
MS-SQL
DB2
Cache
CUBRID
LDAP
ALTIBASE
Tibero
DB 문서들
스터디
Community
공지사항
자유게시판
구인|구직
DSN 갤러리
도움주신분들
Admin
운영게시판
최근게시물
Oracle Tutorials 9266 게시물 읽기
 News | Q&A | Columns | Tutorials | Devel | Files | Links
No. 9266
Cost based optimizer에서 histogram의 적용
작성자
정재익(advance)
작성일
2002-01-05 16:40
조회수
6,620

Cost based optimizer에서 histogram의 적용

 

목적

저장된 Histogram 정보를 어떻게 해석할 것인가에 대한 이해를 제공

 

SCOPE & APPLICATION

Code-based optimizer 와 친숙해 지는 것이 유용하다.

 

관련된 문서

[NOTE:50750.1]

[NOTE:1031826.6]

 

컬럼의 분포가 고도로 산만해 져 있을때, 자료를 non-uniform distribution 이라고 부르며, histogram 은 좀더 나은 선택성을 제공해 준다. 이것으로 좀더 적절한 plan 을 생성할 수 있다.

 

이 histogram approach 는 자료의 분산을 표현하는데 좀더 효율적이고, 간결한 방법을 제공한다. Histogram 을 생성할때, 저장된 정보는 요구되는 buckets 의 수가 distinct value 의 수보다 더 작느냐 또는 같느냐에 따라 다르게 해석된다.

특히, dba/user/all_histograms 에 있는 ENDPOINT_NUMBER 와 ENDPOINT_VALUE 는 다른 의미를 가진다.

 

예제

-------

 

Table TAB1

SQL> desc tab1 
    Name Null? Type 
    ------------------------------- -------- ---- 
    A                NUMBER(6) 
    B                NUMBER(6) 

Column A 는 1 부터 10000 까지의 unique value 를 가진다.

 

Column B 는 10 가지의 distinct values 를 가진다. '5' 라는 값은 9991 번 등장한다.

'1, 2, 3, 4, 9996, 9997, 9998, 9999, 10000' 등의 값은 오로지 한번만 등장한다.

 

Test queries:

 

(1) select * from tab1 where b=5;

(2) select * from tab1 where b=3;

 

이 두 query 는 다른 접근 방법을 이용할수 없는 한 FULL TABLE SCAN 을 사용한다.

 

그러면 우리는 column B 에 대해 index 를 생성해 보자.

select lpad(INDEX_NAME,10), lpad(TABLE_NAME,10),
                 lpad(COLUMN_NAME,10), COLUMN_POSITION, 
                 COLUMN_LENGTH 
from user_ind_columns 
where table_name='TAB1' 

SQL> / 

LPAD(INDEX LPAD(TABLE LPAD(COLUM COLUMN_POSITION COLUMN_LENGTH 
----------    ----------     ----------       ---------------          ------------- 
TAB1_B        TAB1             B                    1                               22 

이제,

 

(1) select * from tab1 where b=5;

(2) select * from tab1 where b=3;

 

이 두 query 는 table 을 검사해서 ROWID 를 얻기 위해서 INDEX RANGE SCAN 을 하게 된다.

INDEX 가 존재하는 상황에서는, query (2) 에 대해서는 INDEX RANGE SCAN 을 사용하지만, query (1) 은 FULL TABLE SCAN 를 사용할 것이다.

 

TABLE의 분석

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

 

다음으로, 통계를 계산해서 테이블을 분석해 보자:

 

SQL> analyze table tab1 compute statistics;

 

From dba_tables:

NUM_ROWS BLOCKS EMPTY_BLOCKS AVG_SPACE CHAIN_CNT AVG_ROW_LEN 
----------   -------- ------------         ----------    ----------    ----------- 
10000            64          0                        86                 0                     10 

 

From dba_tab_columns:

NUM_DISTINCT LOW HIGH DENSITY NUM_NULLS NUM_BUCKETS LAST_ANALYZ SAMPLE_SIZE 
------------     ----   ----   --------- ----------  -----------        ----------- ----------- 
10000                Full   Full    .0001       0                 1              30-JUN-1999               10000 
10                    Full   Full     .1           0                 1              30-JUN-1999               10000 

For Oracle7, from user_histograms:

SQL> select lpad(TABLE_NAME,10), lpad(COLUMN_NAME, 10), 
        2 bucket_number, endpoint_value 
        3 from user_histograms 
        4 where table_name='TAB1'; 

TABLE_NAME COLUMN_NAME BUCKET_NUMBER ENDPOINT_VALUE 
----------      -----------         -------------        -------------- 
TAB1              A                        0                          1 
TAB1              A                        1                          10000 
TAB1              B                        0                          1 
TAB1              B                        1                          10000 

For Oracle8, from user_tab_histograms: 

SQL> select lpad(TABLE_NAME,10), lpad(COLUMN_NAME, 10), 
        2 bucket_number, endpoint_value 
        3 from user_tab_histograms 
        4 where table_name='TAB1'; 

Analyze 는 각각의 column 에 대해서 1 BUCKET 을 생성했다. 그래서 column 의 모든 값들이 같은 bucket 내에 있게 된다. BUCKET_NUMBER 는 BUCKET NUMBER 를 나타내고, ENDPOINT_VALUE 는 bucket 내에서 마지막 column 값을 나타낸다.

 

이제 query (1) 과 (2) 둘다 FULL TABLE SCAN 을 하게 된다.

 

그래서, 여러분들이 테이블과 컬럼에 대해서 통계를 가졌다는 사실 자체는 우리들이 얼마나 많은 value 의 종류를 가졌는지를 optimizer 가 구분하는데 전혀 도움이 되질 않는다.

FULL TABLE SCAN 을 하게 되는 원인은 because 1 BUCKET histogram 이 있고, select 되는 어떤 값이 그 bucket 내에 있기 때문이다.

 

 

HISTOGRAMS 생성

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

 

이제 여러분들이 해야 할일은 histogram 을 생성해서 Optimizer 가 각각의 column 에서 얼마나 많은 값들이 등장하는지 알도록 하는 일이다.

Query (1): select * from tab1 where b=5; 
                should do a FULL TABLE SCAN and 

Query (2): select * from tab1 where b=3; 
                should do an INDEX RANGE SCAN 

SQL> analyze table tab1 compute statistics for columns b size 10; 

select lpad(TABLE_NAME,10), lpad(COLUMN_NAME, 5), 
                            endpoint_number, endpoint_value 
from user_histograms; 

TABLE_NAME   COLUMN_NAME   ENDPOINT_NUMBER ENDPOINT_VALUE 
TAB1                B                         1                               1 
TAB1                B                         2                               2 
TAB1                B                         3                               3 
TAB1                B                         4                               4 
TAB1                B                         9995                           5 
TAB1                B                         9996                           9996 
TAB1                B                         9997                           9997 
TAB1                B                         9998                           9998 
TAB1                B                         9999                           9999 
TAB1                B                         10000                          10000 

 

이렇게 하면, 이제는 테이블과 컬럼들에 대한 통계를 알수 있다.

 

여러분들은 10 buckets (size 10) 을 요구했고 10 distinct values 가 존재한다.

 

ENDPOINT_VALUE 는 column 값을 보여주고, ENDPOINT_NUMBER 는 row 들을 축적하여 합한 수를 보여 준다.

 

예를 들면, ENDPOINT_VALUE 가 2이고, ENDPOINT_NUMBER 가 2 라면, 그리고 이전의 ENDPOINT_NUMBER 가 1 라면, 그러면 2 라는 값(value) 를 가진 row 의 수가 1 이라는 것이다.

 

또 다른 예제로 ENDPOINT_VALUE 가 5 라고 하자. 그것의 ENDPOINT_NUMBER 가 9995 라고 하자. 이전의 bucket 의 ENDPOINT_NUMBER 가 4 라고 하면, 그러면 9995 - 4 = 9991 rows 가 value 5 를 포함하고 있는 것이된다.

 

그래서, 이제 QUERY (1) 는 실제적으로 Full Table Scan 을 하게 된다.

 

SQL> select * from tab1 where b=5

SQL> /

 

Execution Plan

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

0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=10 Card=9991 Bytes=99910)

 

1 0 TABLE ACCESS (FULL) OF 'TAB1' (Cost=10 Card=9991 Bytes=99910)

 

And, QUERY (2) does do an Index Range Scan.

 

SQL> select * from tab1 where b=3

SQL> /

 

Execution Plan

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

0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=6 Card=500 Bytes=5000)

1 0 TABLE ACCESS (BY ROWID) OF 'TAB1' (Cost=6 Card=500 Bytes=5000)

2 1 INDEX (RANGE SCAN) OF 'TAB1_B' (NON-UNIQUE)

 

이러 한 것은 만약에 여러분들이 distinct value 를 적게 가진다면 좋다. 그러나 distinct value 를 수도 없이 많이 가질 수도 있다. 여러분들은 각각의 value 에 대해서 한개씩의 bucket 을 생성하길 원하지는 않을 것이다. 그러면 너무나 많은 overhead 가 걸린다. 이러한 경우라면 여러분들은 distinct vlaue 보다는 적은 buckets 을 요구할 것이다.

 

DISTINCT VALUE 보다 적은 수의 BUCKET 을 가지는 HISTOGRAMS 생성하기

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

SQL> analyze table tab1 compute statistics for columns b size 8; 

SQL> select lpad(TABLE_NAME,10), lpad(COLUMN_NAME, 5), 
        2> endpoint_number, endpoint_value 
        3> from user_histograms; 

LPAD(TABLE LPAD( ENDPOINT_NUMBER ENDPOINT_VALUE 
---------- ----- --------------- -------------- 
TAB1 B 0 1 
TAB1 B 7 5 
TAB1 B 8 10000 

여기서, 오라클은 요구하는 수의 buckets 을 생성한다. 그러나 각각의 bucket 내에 같은 수의 value 를 넣게 된다. 여기서 자주 등장하는 value 에 대해서는 동일한 좀더 많은 endpoint value 가 있게 된다.

ENDPOINT_NUMBER 는 실제적인 bucket 수이며, ENDPOINT_VALUE 는 column vlaue 에 의해 결정된 bucket 의 endpoint value 이다.

 

위에서 부터, bucket 0 는 column 에 대해서 low value 를 가지고 있게 된다. 여러분들은 공간을 절약하기 위해서 bucket 1 부터 6 까지는 볼수가 없다.

 

But we have bucket 1 with an endpoint of 5, 
                    bucket 2 with an endpoint of 5, 
                        bucket 3 with an endpoint of 5, 
                    bucket 4 with an endpoint of 5, 
                    bucket 5 with an endpoint of 5, 
                    bucket 6 with an endpoint of 5, 
                    bucket 7 with an endpoint of 5 AND 
                    bucket 8 with an endpoint of 10000 

그래서 bucket 8 는 5 와 10000사이의 value 를 가지게 된다.

모든 buckets 은 같은 수의 value를 포함하게 된다. (이것이 그들이 height-balanced histogram 이라고 불리는 이유이다), 마지막 bucket 을 제외하고, 마지막 bucket 는 다른 bucket 보다 적은 수의 value 들을 가지게 될 것이다.

만약 data 가 uniform 하다면, 여러분들은 histogram 을 사용할 필요가 없다. 그러나 만약 여러분들이 distinct value 와 같은 수의 bucket 을 요구하게 된다면, 오라클은 1 bucket 만을 생성하게 된다. 만약 여러분들이 distinct value 보다 less bucket 을 요구하게 된다면, 오라클은 각각의 bucket 에 balance value algorithm 을 사용하게 되며, 남아 있는 각각의 value (이것은 각각의 height-balanced bucket 에 저장된 수 보다는 적게 가지게 될것이다) 는 마지막 bucket 로 가게 된다.

 

STORING CHARACTER VALUES IN HISTOGRAMS

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

 

문자 (Character) columns 은 우리가 어떤 string 의 처음 5 byte 만을 histogram data 에 저장 할 때 처럼, 몇가지 예외 동작을 가진다. 5 character 를 넘어가는 string 은 histogram 정보를 사용할 수 없을것이라고 예측할 수 있으며, selectivity 는 1 / DISTINCT 이다.

 

--> 8i 부터는 해결 되었습니다.

 

Histogram endpoints 에 있는 data 는 배정도의 부동소수점 산술식으로 정규화 된다.

 

예제

-------

 

SQL> select * from morgan;

 

A

----------

a

b

c

d

e

e

e

e

 

 

테이블에는 5 개의 distinct values 를 포함하고 있다. 'a', 'b', 'c' and 'd' 는 한번만 등장하며,'e' 는 4번 등장한다.

 

5 buckets 을 가지는 histogram 을 생성하라.

 

SQL> analyze table morgan compute statistics for columns a size 5;

 

user_histograms 을 보면:

LPAD(TABLE LPAD( ENDPOINT_NUMBER ENDPOINT_VALUE 
----------     -----   ---------------        -------------- 
MORGAN       A        1                             5.0365E+35 
MORGAN       A        2                             5.0885E+35 
MORGAN       A        3                             5.1404E+35 
MORGAN       A        4                             5.1923E+35 
MORGAN       A        8                             5.2442E+35 

그래서, ENDPOINT_VALUE 5.0365E+35 는 a 를 나타내며
            5.0885E+35 는 b 를 나타나며 
            5.1404E+35 는 c 를 나타내며
            5.1923E+35 는 d 를 나타내며
            5.2442E+35 는 e 를 나타낸다.

그러면 만약 여러분들이 ENDPOINT_NUMBER 의 집적 값 (cumulative value) 를 볼때, 해당되는 ENDPOINT_VALUE 는 옳바르다.

 

 

 

영문원본

====================================

PURPOSE 
To provide an understanding of how histogram information is stored and 
can be interpreted. 

SCOPE & APPLICATION 
Familiarity of the Cost Based Optimizer is useful. 
       
RELATED DOCUMENTS 
@[NOTE:50750.1] 
[NOTE:1031826.6] 

Where there is a high degree of skew in the column distribution, called a 
non-uniform distribution of data, histograms should lead to a better 
estimation of selectivity. This should produce plans that are more likely 
to be optimal. 

The histogram approach provides an efficient and compact way to represent 
data distributions. 

When building histograms the information it stores is interpreted differently 
depending on whether the number of buckets requested is less than the number 
distinct values or if it is the same. Specifically, ENDPOINT_NUMBER and 
ENDPOINT_VALUE in dba/user/all_histograms would have different meanings. 


EXAMPLE 
------- 

Table TAB1 

SQL> desc tab1 
    Name Null? Type 
    ------------------------------- -------- ---- 
    A NUMBER(6) 
    B NUMBER(6) 

Column A contains unique values from 1 to 10000. 

Column B contains 10 distinct values. The value '5' occurs 9991 times. Values 
'1, 2, 3, 4, 9996, 9997, 9998, 9999, 10000' occur only once. 

Test queries: 

(1) select * from tab1 where b=5; 
(2) select * from tab1 where b=3; 

Both the above queries would use a FULL TABLE SCAN as there is no other 
access method available. 

Then we create an index on column B. 

select lpad(INDEX_NAME,10), lpad(TABLE_NAME,10), 
                            lpad(COLUMN_NAME,10), COLUMN_POSITION, COLUMN_LENGTH 
from user_ind_columns 
where table_name='TAB1' 

SQL> / 

LPAD(INDEX LPAD(TABLE LPAD(COLUM COLUMN_POSITION COLUMN_LENGTH 
---------- ---------- ---------- --------------- ------------- 
                TAB1_B TAB1 B 1 22 

Now, 

(1) select * from tab1 where b=5; 
(2) select * from tab1 where b=3; 

Both do an INDEX RANGE SCAN to get the ROWID to do a lookup in the table. 

With an INDEX present, it would preferrable to do an INDEX RANGE SCAN for 
query (2), but a FULL TABLE SCAN for query (1). 


ANALYZING THE TABLE 
------------------- 

Next, analyze the table using compute statistics: 

SQL> analyze table tab1 compute statistics; 

From dba_tables: 

        NUM_ROWS BLOCKS EMPTY_BLOCKS AVG_SPACE CHAIN_CNT AVG_ROW_LEN 
---------- ---------- ------------ ---------- ---------- ----------- 
                    10000 64 0 86 0 10 

From dba_tab_columns: 

NUM_DISTINCT LOW HIGH DENSITY NUM_NULLS NUM_BUCKETS LAST_ANALYZ SAMPLE_SIZE 
------------ ---- ---- --------- ---------- ----------- ----------- ----------- 
                            10000 Full Full .0001 0 1 30-JUN-1999 10000 
                                        10 Full Full .1 0 1 30-JUN-1999 10000 

For Oracle7, from user_histograms: 

SQL> select lpad(TABLE_NAME,10), lpad(COLUMN_NAME, 10), 
        2 bucket_number, endpoint_value 
        3 from user_histograms 
        4 where table_name='TAB1'; 

TABLE_NAME COLUMN_NAME BUCKET_NUMBER ENDPOINT_VALUE 
---------- ----------- ------------- -------------- 
                        TAB1 A 0 1 
                        TAB1 A 1 10000 
                        TAB1 B 0 1 
                        TAB1 B 1 10000 

For Oracle8, from user_tab_histograms: 

SQL> select lpad(TABLE_NAME,10), lpad(COLUMN_NAME, 10), 
        2 bucket_number, endpoint_value 
        3 from user_tab_histograms 
        4 where table_name='TAB1'; 

Analyze has created 1 BUCKET for each column. So all values for the column 
are in the same bucket. The BUCKET_NUMBER represents the BUCKET NUMBER and 
ENDPOINT_VALUE represents the last column value in that bucket. 

Now query (1) and (2) ; both do a FULL TABLE SCAN. 

So, the fact that you have statistics about the table and columns does not 
help the optimizer to distinguish between how many of each value we have. 
The reason it does a FULL TABLE SCAN is because there is a 1 BUCKET histogram 
and any value selected for should be in that bucket. 


CREATING HISTOGRAMS 
------------------- 

What you need now is to create histograms so the Optimizer knows how many 
values occur for each column. 

Query (1): select * from tab1 where b=5; 
                                            should do a FULL TABLE SCAN and 

Query (2): select * from tab1 where b=3; 
                                            should do an INDEX RANGE SCAN 

SQL> analyze table tab1 compute statistics for columns b size 10; 

select lpad(TABLE_NAME,10), lpad(COLUMN_NAME, 5), 
                            endpoint_number, endpoint_value 
from user_histograms; 

TABLE_NAME COLUMN_NAME ENDPOINT_NUMBER ENDPOINT_VALUE 
                        TAB1 B 1 1 
                        TAB1 B 2 2 
                        TAB1 B 3 3 
                        TAB1 B 4 4 
                        TAB1 B 9995 5 
                        TAB1 B 9996 9996 
                        TAB1 B 9997 9997 
                        TAB1 B 9998 9998 
                        TAB1 B 9999 9999 
                        TAB1 B 10000 10000 

So, now there are statistics on the table and on the columns. 

You requested 10 buckets (size 10) and there are 10 distinct values. 

The ENDPOINT_VALUE shows the column value and the ENDPOINT_NUMBER 
shows the cumulative number of rows. 

For example, for ENDPOINT_VALUE 2, it has an ENDPOINT_NUMBER 2, the previous 
ENDPOINT_NUMBER is 1, hence the number of rows with value 2 is 1. 

Another example is ENDPOINT_VALUE 5. Its ENDPOINT_NUMBER is 9995. The previous 
bucket ENDPOINT_NUMBER is 4, so 9995 - 4 = 9991 rows containing the value 5. 

So, now QUERY (1) does in fact do a Full Table Scan. 

SQL> select * from tab1 where b=5 
SQL> / 

Execution Plan 
---------------------------------------------------------- 
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=10 Card=9991 Bytes=99910) 

1 0 TABLE ACCESS (FULL) OF 'TAB1' (Cost=10 Card=9991 Bytes=99910) 


And, QUERY (2) does do an Index Range Scan. 

SQL> select * from tab1 where b=3 
SQL> / 

Execution Plan 
---------------------------------------------------------- 
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=6 Card=500 Bytes=5000) 
1 0 TABLE ACCESS (BY ROWID) OF 'TAB1' (Cost=6 Card=500 Bytes=5000) 
2 1 INDEX (RANGE SCAN) OF 'TAB1_B' (NON-UNIQUE) 

This is fine if you have a low number of distinct values, but there can 
be tables with a huge number of distinct values. You don't want to 
create a bucket for each value. There would be too much overhead. 
In this case you would request less buckets than distinct values. 


CREATING HISTOGRAMS WITH LESS BUCKETS THAN DISTINCT VALUES 
---------------------------------------------------------- 

SQL> analyze table tab1 compute statistics for columns b size 8; 

SQL> select lpad(TABLE_NAME,10), lpad(COLUMN_NAME, 5), 
        2> endpoint_number, endpoint_value 
        3> from user_histograms; 

LPAD(TABLE LPAD( ENDPOINT_NUMBER ENDPOINT_VALUE 
---------- ----- --------------- -------------- 
TAB1 B 0 1 
TAB1 B 7 5 
TAB1 B 8 10000 

Here, Oracle creates the requested number of buckets but puts the same 
number of values into each bucket, where there are more endpoint values 
that are the same for the frequently occurring value. 

The ENDPOINT_NUMBER is the actual bucket number and ENDPOINT_VALUE is 
the endpoint value of the bucket determined by the column value. 

From above, bucket 0 holds the low value for the column. You cannot see 
buckets 1 to 6 so as to save space. 

But we have bucket 1 with an endpoint of 5, 
                    bucket 2 with an endpoint of 5, 
                        bucket 3 with an endpoint of 5, 
                    bucket 4 with an endpoint of 5, 
                    bucket 5 with an endpoint of 5, 
                    bucket 6 with an endpoint of 5, 
                    bucket 7 with an endpoint of 5 AND 
                    bucket 8 with an endpoint of 10000 

So bucket 8 contains values between 5 and 10000. 
All buckets contain the same number of values (which is why they are called 
height-balanced histograms), except the last bucket may have less values 
then the other buckets. 

If the data is uniform, you would not use histograms. However, if you request 
the same number of buckets as distinct values, Oracle creates 1 bucket. If 
you request less buckets, Oracle uses an algorithm to balance values into each 
bucket and any values that remain (which have to be less then the number 
stored in each height-balanced bucket) go into the last bucket. 


STORING CHARACTER VALUES IN HISTOGRAMS 
-------------------------------------- 

Character columns have some exceptional behaviour, in as much as we store 
histogram data for the first 5 bytes of any string. Any predicates that 
contain strings greater than 5 characters will not use histogram information 
and the selectivity will be 1 / DISTINCT. 

    --> 8i 부터는 해결 되었습니다(laalaal~) 

Data in histogram endpoints is normalized to double precision floating point 
arithmetic. 

EXAMPLE 
------- 

SQL> select * from morgan; 

A 
---------- 
a 
b 
c 
d 
e 
e 
e 
e 


The table contains 5 distinct values. There is one occurance of 'a', 'b', 'c' 
and 'd' and 4 of 'e'. 

Create a histogram with 5 buckets. 

SQL> analyze table morgan compute statistics for columns a size 5; 

Looking in user_histograms: 

LPAD(TABLE LPAD( ENDPOINT_NUMBER ENDPOINT_VALUE 
---------- ----- --------------- -------------- 
                MORGAN A 1 5.0365E+35 
                MORGAN A 2 5.0885E+35 
                MORGAN A 3 5.1404E+35 
                MORGAN A 4 5.1923E+35 
                MORGAN A 8 5.2442E+35 

So, ENDPOINT_VALUE 5.0365E+35 represents a 
            5.0885E+35 represents b 
            5.1404E+35 represents c 
            5.1923E+35 represents d 
            5.2442E+35 represents e 

Then if you look at the cumulative values for ENDPOINT_NUMBER, 
the corresponding ENDPOINT_VALUE's are correct. 


from oracle 
[Top]
No.
제목
작성자
작성일
조회
9269WEB상에서 PLSQL로 EXCEL FILE만드는 예제
정재익
2002-01-05
5044
9268Listener패스워드 설정 방법
정재익
2002-01-05
5410
9267익스텐트 및 테이블 스페이스 설정시 고려사항
정재익
2002-01-05
5387
9266Cost based optimizer에서 histogram의 적용
정재익
2002-01-05
6620
9265IP ADDRESS CHANGE IN SQL*NET
정재익
2002-01-05
4683
9264OPS : PCM Lock과 Non-PCM Lock에 대한 정리
정재익
2002-01-05
5326
9263Alter session kill에 대하여
정재익
2002-01-05
9125
Valid XHTML 1.0!
All about the DATABASE... Copyleft 1999-2023 DSN, All rights reserved.
작업시간: 0.052초, 이곳 서비스는
	PostgreSQL v16.1로 자료를 관리합니다