내맘대로긍정

오라클 Exadata cellcli list 명령에서 attributes 목록 확인

내맘대로긍정 — Sat, 8 Aug 2026 15:51:44 +0900

EXADATA Image : 22.1.33.0.0.250304

OS 환경 : Oracle Linux 7.9 (64bit)

DB 환경 : Oracle Database 19.31.0.0

방법 : 오라클 Exadata cellcli list 명령에서 attributes 목록 확인

exadata의 cellcli 명령에서 attributes를 입력해서 원하는 컬럼만 확인할 수 있음

1
2
3
4
5
6
7
8
9
10
11
12
13
14

CellCLI> list physicaldisk attributes name, diskType, status
list physicaldisk attributes name, diskType, status
         252:0           HardDisk        normal
         252:1           HardDisk        normal
         252:2           HardDisk        warning - predictive failure
         252:3           HardDisk        normal
         252:4           HardDisk        normal
         252:5           HardDisk        normal
         FLASH_10_1      FlashDisk       normal
         FLASH_10_2      FlashDisk       normal
         FLASH_5_1       FlashDisk       normal
         FLASH_5_2       FlashDisk       normal
         M2_SYS_0        M2Disk          normal
         M2_SYS_1        M2Disk          normal

하지만 어떤 컬럼이 있는지 모르는 경우 아래 명령처럼 detail 명령을 사용해서 보기도 함

1
2
3
4
5
6
7
8
9
10
11
12
13

CellCLI> LIST CELLDISK CD_00_GDX7CELADM01 DETAIL
LIST CELLDISK CD_00_GDX7CELADM01 DETAIL
         name:                   CD_00_exa7celadm01
         comment:
         creationTime:           2026-07-21T09:53:31+09:00
         deviceName:             /dev/sda
         devicePartition:        /dev/sda
         diskType:               HardDisk
         freeSpace:              0
         id:                     1ae1cafd-1655-4cc5-b0c8-7ad89f74996e
         physicalDisk:           RAMKKD
         size:                   8.9094085693359375T
         status:                 normal

하지만 list metrichistory 처럼 결과가 아주 많이 나오는 경우 나오는데 시간도 걸리고 읽기 어려울 수 있음

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

CellCLI> LIST METRICHISTORY CD_IO_ERRS_MIN DETAIL
LIST METRICHISTORY CD_IO_ERRS_MIN DETAIL
         name:                   CD_IO_ERRS_MIN
         alertState:             normal
         collectionTime:         2026-07-23T16:59:02+09:00
         metricObjectName:       CD_03_exa7celadm01
         metricType:             Rate
         metricValue:            0.0 /min
         objectType:             CELLDISK
 
         name:                   CD_IO_ERRS_MIN
         alertState:             normal
         collectionTime:         2026-07-23T16:59:02+09:00
         metricObjectName:       CD_04_exa7celadm01
         metricType:             Rate
         metricValue:            0.0 /min
         objectType:             CELLDISK
...

이때는 describe 명령을 사용하면 컬럼들만 바로 확인할 수 있음

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

CellCLI> DESCRIBE METRICHISTORY
DESCRIBE METRICHISTORY
        name
        alertState
        collectionTime
        metricObjectName
        metricType
        metricValue
        metricValueAvg
        metricValueMax
        metricValueMin
        objectType
 
CellCLI> DESCRIBE CELLDISK
DESCRIBE CELLDISK
        name                   modifiable
        comment                modifiable
        creationTime
        deviceName
        devicePartition
        diskType
        errorCount             hidden
        flushError             hidden
        flushStatus            hidden
        freeSpace
        id
        physicalDisk
        size                   modifiable
        status

만약 실제 데이터도 한건만 보고싶은경우 sql처럼 order by + limit 절을 사용할 수 있음

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

CellCLI> LIST CELLDISK DETAIL -
ORDER BY name DESC LIMIT 1
LIST CELLDISK DETAIL -
 
         name:                   FD_01_exa7celadm01
         comment:
         creationTime:           2026-07-21T09:53:31+09:00
         deviceName:             /dev/md305
         devicePartition:        /dev/md305
         diskType:               FlashDisk
         freeSpace:              0
         id:                     3f17888e-55de-4ae0-9fd6-9900b2aea5c8
         physicalDisk:           PHLE812000836P4BGN-2,PHLE812000836P4BGN-1
         size:                   5.8218994140625T
         status:                 normal

결론 :
cellcli에서 특정 목록의 컬럼만 보려면 describe 명령을 사용하면 편리하게 확인 가능함
만약 샘플로 1건만 보고 싶다면 order by + limit 절을 사용할 수도 있음

참조 :

https://docs.oracle.com/en/engineered-systems/exadata-database-machine/sagug/describe.html
https://docs.oracle.com/cd/F16836_01/sagug/system-software-users-guide-exadata-database-machine.pdf?utm_source=chatgpt.com

오라클 26ai select ai 로컬 llm 이용(로컬 gpu 서버) 방법

내맘대로긍정 — Wed, 5 Aug 2026 19:55:04 +0900

OS 환경 : Oracle Linux 9.6 (64bit)

DB 환경 : Oracle AI Database 23.26.2.0.0 ai

방법 : 오라클 26ai select ai 로컬 llm 이용(로컬 gpu 서버) 방법

본문에서는 select ai를 로컬 llm(gpu 서버)를 이용해 실행하는 방법을 설명함
select ai를 사용하기 위해선 먼저 dbms_cloud 패키지가 필요함
해당 패키지 설치는 아래 글을 참고하여 설치하면 됨
참고 : 오라클 23ai 신기능 dbms_cloud 설치(non-adb) ( https://positivemh.tistory.com/1203 )

참고로 로컬 llm(gpu 서버)가 아닌 openai의 api를 사용해서 select ai를 수행하는 방법은 아래 게시글을 참고하면 됨
참고 : 오라클 26ai 신기능 Select AI 사용 테스트(non-adb) ( https://positivemh.tistory.com/1205 )

테스트

LLM용 ACL 생성
*유저이름은 IMSI이고 OPENAI api를 사용함
*pdb에서 sys 유저로 수행

1
2
3
4
5
6
7
8
9
10
11
12

SQL>
BEGIN
  DBMS_NETWORK_ACL_ADMIN.APPEND_HOST_ACE(
    host => 'ai.localllm.com',
    ace  => xs$ace_type(privilege_list => xs$name_list('http'),
                        principal_name => 'IMSI',
                        principal_type => xs_acl.ptype_db)
  );
END;
/
 
PL/SQL procedure successfully completed.

imsi 유저에 DBMS_CLOUD_AI 권한 부여

1
2
3

SQL> grant execute on dbms_cloud_ai to imsi;
 
Grant succeeded.

참고로 오라클 text 미설치시 에러남

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

SQL> BEGIN
  DBMS_CLOUD.CREATE_CREDENTIAL (
    credential_name => 'LOCAL_SLM_CRED',
    username => 'IMSI',
    password => 'none' -- 실제 키가 없으므로 임의의 값 입력
  );
END;
/  2    3    4    5    6    7    8
BEGIN
*
ERROR at line 1:
ORA-20000: ORA-04063: package body "C##CLOUD$SERVICE.DBMS_CLOUD_INTERNAL" has errors
ORA-06508: PL/SQL: could not find program unit being called: "C##CLOUD$SERVICE.DBMS_CLOUD_INTERNAL"
ORA-06512: at "C##CLOUD$SERVICE.DBMS_CLOUD", line 2257
ORA-06512: at "C##CLOUD$SERVICE.DBMS_CLOUD", line 11216
ORA-06512: at line 2

참고 : 오라클 26ai CDB, PDB에 Oracle Text 컴포넌트 설치 ( https://positivemh.tistory.com/1369 )

LLM용 자격증명 생성(일반 유저에서 수행)
로컬 LLM은 실제 api 키가 없으므로 임의의 값 입력

1
2
3
4
5
6
7
8
9
10
11

SQL>
BEGIN
  DBMS_CLOUD.CREATE_CREDENTIAL (
    credential_name => 'LOCAL_SLM_CRED',
    username => 'IMSI',
    password => 'none' -- 실제 키가 없으므로 임의의 값 입력
  );
END;
/
 
PL/SQL procedure successfully completed.

imsi 유저에 샘플 테이블 생성

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

SQL>
drop table products purge;
CREATE TABLE products
(
    product_id       NUMBER          PRIMARY KEY,
    product_name     VARCHAR2(100)   NOT NULL,
    category         VARCHAR2(50)    NOT NULL,
    brand            VARCHAR2(50)    NOT NULL,
    price            NUMBER(10, 2)   NOT NULL,
    stock_quantity   NUMBER          DEFAULT 0 NOT NULL,
    rating           NUMBER(2, 1),
    launch_date      DATE,
    product_status   VARCHAR2(20)    DEFAULT 'ACTIVE');
 
INSERT INTO products
(
    product_id,
    product_name,
    category,
    brand,
    price,
    stock_quantity,
    rating,
    launch_date,
    product_status
)
VALUES
    (1,  'Galaxy Book Pro',       'Laptop',     'Samsung', 1890000, 15, 4.7, DATE '2026-01-15', 'ACTIVE'),
    (2,  'LG Gram Style',         'Laptop',     'LG',      1750000,  8, 4.5, DATE '2025-11-20', 'ACTIVE'),
    (3,  'MacBook Air',           'Laptop',     'Apple',   1590000, 20, 4.9, DATE '2026-03-10', 'ACTIVE'),
    (4,  'Galaxy S26',            'Smartphone', 'Samsung', 1350000, 35, 4.8, DATE '2026-02-05', 'ACTIVE'),
    (5,  'iPhone 17',             'Smartphone', 'Apple',   1490000,  0, 4.9, DATE '2025-09-20', 'SOLD_OUT'),
    (6,  'Pixel 10',              'Smartphone', 'Google',  1190000, 12, 4.4, DATE '2025-10-15', 'ACTIVE'),
    (7,  'AirPods Pro',           'Earphones',  'Apple',    349000, 42, 4.8, DATE '2025-08-30', 'ACTIVE'),
    (8,  'Galaxy Buds',           'Earphones',  'Samsung',  229000, 28, 4.3, DATE '2025-07-12', 'ACTIVE'),
    (9,  'OLED Gaming Monitor',   'Monitor',    'LG',       890000,  5, 4.6, DATE '2025-05-01', 'ACTIVE'),
    (10, 'Smart Monitor M8',      'Monitor',    'Samsung',  650000,  0, 4.2, DATE '2024-06-10', 'DISCONTINUED');
 
COMMIT;

데이터 확인

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

SQL> 
set lines 200 pages 1000
col product_name for a20
col category for a20
col brand for a10
select * from products;
 
PRODUCT_ID PRODUCT_NAME         CATEGORY             BRAND           PRICE STOCK_QUANTITY     RATING LAUNCH_DA PRODUCT_STATUS
---------- -------------------- -------------------- ---------- ---------- -------------- ---------- --------- --------------------
         1 Galaxy Book Pro      Laptop               Samsung       1890000             15        4.7 15-JAN-26 ACTIVE
         2 LG Gram Style        Laptop               LG            1750000              8        4.5 20-NOV-25 ACTIVE
         3 MacBook Air          Laptop               Apple         1590000             20        4.9 10-MAR-26 ACTIVE
         4 Galaxy S26           Smartphone           Samsung       1350000             35        4.8 05-FEB-26 ACTIVE
         5 iPhone 17            Smartphone           Apple         1490000              0        4.9 20-SEP-25 SOLD_OUT
         6 Pixel 10             Smartphone           Google        1190000             12        4.4 15-OCT-25 ACTIVE
         7 AirPods Pro          Earphones            Apple          349000             42        4.8 30-AUG-25 ACTIVE
         8 Galaxy Buds          Earphones            Samsung        229000             28        4.3 12-JUL-25 ACTIVE
         9 OLED Gaming Monitor  Monitor              LG             890000              5        4.6 01-MAY-25 ACTIVE
        10 Smart Monitor M8     Monitor              Samsung        650000              0        4.2 10-JUN-24 DISCONTINUED
 
10 rows selected.

Select AI 프로필 생성
*pdb의 imsi 유저에서 생성함, 하나는 openai 호환 모델을 사용했고(TEST_LOCAL_SLM1), 하나는 CLOVA 모델을 사용해서 생성했음(TEST_LOCAL_SLM2)
provider_endpoint는 llm 서버의 endpoint 주소로 설정함

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

SQL>
BEGIN
  DBMS_CLOUD_AI.CREATE_PROFILE(
    profile_name => 'TEST_LOCAL_SLM1',
    attributes => '{"provider": "openai",
                    "comments": "true",
                    "model": "gpt-oss-20b",
                    "provider_endpoint": "https://ai.localllm.com",
                    "case_sensitive_values" : "false",
                    "temperature": 0.2,
                    "max_tokens": 4096,
                    "conversation": "true",
                    "credential_name": "LOCAL_SLM_CRED",
                    "object_list": [{"owner": "IMSI", "name": "PRODUCTS"}]}'
  );
END;
/
 
PL/SQL procedure successfully completed.
 
SQL>
BEGIN
  DBMS_CLOUD_AI.CREATE_PROFILE(
    profile_name => 'TEST_LOCAL_SLM2',
    attributes => '{"provider": "openai",
                    "comments": "true",
                    "model": "hcx-dash-002",
                    "provider_endpoint": "https://ai.localllm.com",
                    "case_sensitive_values" : "false",
                    "temperature": 0.2,
                    "max_tokens": 4096,
                    "conversation": "true",
                    "credential_name": "LOCAL_SLM_CRED",
                    "object_list": [{"owner": "IMSI", "name": "PRODUCTS"}]}'
  );
END;
/
 
PL/SQL procedure successfully completed.

참고. profile 삭제

1
2
3

SQL> exec dbms_cloud_ai.drop_profile(profile_name => 'TEST_LOCAL_SLM1');
 
PL/SQL procedure successfully completed.

Open AI 호환모델을 사용하는 프로필을 설정(imsi 유저로 실행)

1
2
3

SQL> exec dbms_cloud_ai.set_profile (profile_name => 'TEST_LOCAL_SLM1');
 
PL/SQL procedure successfully completed.

이제 Select AI를 사용할수 있음

가장 높은 가격의 제품을 조회해봄
What is the most expensive product? 라는 질문으로 각 기능을 테스트해봄

Local LLM을 이용해 Select AI runsql 기능 테스트

1
2
3
4
5
6
7
8
9
10
11
12

SQL>
set timing on
select ai runsql 'What is the most expensive product?';
 
RESPONSE
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sorry, unfortunately a valid SELECT statement could not be generated for your natural language prompt. Here is some more information to help you further:
 
I?m not sure which set of products you?re referring to. Could you let me know the context or provide the list of products you?re comparing? That way I can tell you which one is the most expensive.
 
 
Elapsed: 00:00:08.40

에러가 발생함, 설명을 읽어보면 profile의 테이블 정보가 제대로 전달이 되지 않은것 처럼 보임

CLOVA 모델을 사용하는 프로필을 설정(imsi 유저로 실행)

1
2
3

SQL> exec dbms_cloud_ai.set_profile (profile_name => 'TEST_LOCAL_SLM2');
 
PL/SQL procedure successfully completed.

동일 질문 재수행

1
2
3
4
5
6
7
8
9

SQL>
set timing on
select ai runsql 'What is the most expensive product?';
 
RESPONSE
--------------------------------------------------------------------------------
Sorry, unfortunately a valid SELECT statement could not be generated for your na
 
Elapsed: 00:00:19.57

동일한 에러가 발생함, 이건 설명까지 끊겨 버림

open ai의 api키를 넣은 profile로 select ai 수행시에는 에러가 발생되지 않고 잘됨

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

SQL>
BEGIN
  DBMS_CLOUD_AI.create_profile(
      profile_name => 'TEST_OPENAI',
      attributes => '{"provider": "openai",
                      "comments": "true",
                      "model": "gpt-4o-mini",
                      "temperature": 0.2,
                      "max_tokens": 4096,
                      "conversation": "true",
                      "credential_name": "OPENAI_CRED",
                      "object_list": [{"owner": "IMSI", "name": "PRODUCTS"}]}');
END;
/
 
PL/SQL procedure successfully completed.
 
SQL> exec dbms_cloud_ai.set_profile (profile_name => 'TEST_OPENAI');
 
PL/SQL procedure successfully completed.
 
SQL>
set timing on
select ai runsql 'What is the most expensive product?';
 
Product Name            Price
------------------ ----------
Galaxy Book Pro       1890000
 
Elapsed: 00:00:01.93

에러가 발생하지 않고 잘됨

db 재기동 후 수행해봐도 동일했음

1
2
3
4
5
6
7
8
9
10
11

SQL> startup force
ORACLE instance started.
 
Total System Global Area 1574163776 bytes
Fixed Size                  5027136 bytes
Variable Size             402653184 bytes
Database Buffers         1040187392 bytes
Redo Buffers                8855552 bytes
Vector Memory Area        117440512 bytes
Database mounted.
Database opened.

어노테이션 추가 후 재진행

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77

SQL>
ALTER TABLE products ANNOTATIONS
(
    ADD "Display Label"    'Product Information',
    ADD "Description"      'Stores product details including price, inventory, rating, launch date, and sales status',
    ADD "Business Purpose" 'Product search and sales analysis',
    ADD "Data Language"    'English'
);
 
ALTER TABLE products MODIFY product_id ANNOTATIONS
(
    ADD "Display Label" 'Product ID',
    ADD "Description"   'Unique identifier for each product',
    ADD "Primary Key"   'Yes'
);
 
ALTER TABLE products MODIFY product_name ANNOTATIONS
(
    ADD "Display Label" 'Product Name',
    ADD "Description"   'Name of the product displayed to customers',
    ADD "Example"       'Galaxy Book Pro'
);
 
ALTER TABLE products MODIFY category ANNOTATIONS
(
    ADD "Display Label"  'Product Category',
    ADD "Description"    'Category used to classify products by type',
    ADD "Example Values" 'Laptop, Smartphone, Earphones, Monitor'
);
 
ALTER TABLE products MODIFY brand ANNOTATIONS
(
    ADD "Display Label"  'Brand',
    ADD "Description"    'Brand or manufacturer of the product',
    ADD "Example Values" 'Samsung, LG, Apple, Google'
);
 
ALTER TABLE products MODIFY price ANNOTATIONS
(
    ADD "Display Label" 'Product Price',
    ADD "Description"   'Selling price of one product',
    ADD "Currency"      'KRW',
    ADD "Unit"          'Korean Won'
);
 
ALTER TABLE products MODIFY stock_quantity ANNOTATIONS
(
    ADD "Display Label" 'Stock Quantity',
    ADD "Description"   'Current quantity of products available in inventory',
    ADD "Unit"          'Items',
    ADD "Business Rule" 'A value of zero means the product is out of stock'
);
 
ALTER TABLE products MODIFY rating ANNOTATIONS
(
    ADD "Display Label" 'Product Rating',
    ADD "Description"   'Average customer rating of the product',
    ADD "Minimum Value" '0',
    ADD "Maximum Value" '5'
);
 
ALTER TABLE products MODIFY launch_date ANNOTATIONS
(
    ADD "Display Label" 'Launch Date',
    ADD "Description"   'Date when the product was officially released',
    ADD "Date Format"   'YYYY-MM-DD'
);
 
ALTER TABLE products MODIFY product_status ANNOTATIONS
(
    ADD "Display Label"  'Product Status',
    ADD "Description"    'Current sales status of the product',
    ADD "Allowed Values" 'ACTIVE, SOLD_OUT, DISCONTINUED',
    ADD "ACTIVE"         'The product is currently available for sale',
    ADD "SOLD_OUT"       'The product is temporarily unavailable because inventory is zero',
    ADD "DISCONTINUED"   'The product is no longer available for sale'
);

Open AI 호환모델을 사용하는 프로필을 설정 후 쿼리 재수행(imsi 유저로 실행)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

SQL> exec dbms_cloud_ai.set_profile (profile_name => 'TEST_LOCAL_SLM1');
 
PL/SQL procedure successfully completed.
 
SQL>
set timing on
select ai runsql 'What is the most expensive product?';
 
RESPONSE
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sorry, unfortunately a valid SELECT statement could not be generated for your natural language prompt. Here is some more information to help you further:
 
I?m not sure which set of products you?re referring to. Could you let me know:
 
1. The list or category of products you have in mind (e.g., a specific store, brand, or product line)?
2. Any additional details that might help narrow it down (price range, type of product, etc.)?
 
That way I can give you the most accurate answer.
 
 
Elapsed: 00:00:07.85

여전히 테이블을 못찾는것 같음

질문에 products 테이블도 명시해봄

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

SQL> select ai runsql 'What is the most expensive product in the products table?';
 
RESPONSE
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sorry, unfortunately a valid SELECT statement could not be generated for your natural language prompt. Here is some more information to help you further:
 
**SQL to get the most expensive product**
 
```sql
-- Option 1: Return the single row with the highest price
SELECT *
FROM products
ORDER BY price DESC
LIMIT 1;          -- (use TOP 1 for SQL Server, FETCH FIRST 1 ROW ONLY for Oracle)
 
-- Option 2: Return all products that tie for the highest price
SELECT *
FROM products
WHERE price = (SELECT MAX(price) FROM products);
```
 
- **`ORDER BY price DESC LIMIT 1`** gives you the first row when sorted by price descending ? the most expensive product.
- **`WHERE price = (SELECT MAX(price) ?)`** returns every product that shares the maximum price, useful if you want to handle ties.
 
Pick the one that best fits your needs.
 
 
Elapsed: 00:00:25.77

output이 더 나오긴 하지만 초반에 Sorry~ 메세지가 나오고 마크다운 형식으로 나옴
select ai가 원하는대로 동작하지 않음

OpenAI 모델 사용 테스트2

1
2
3

SQL> exec dbms_cloud_ai.set_profile (profile_name => 'TEST_OPENAI');
 
PL/SQL procedure successfully completed.

OpenAI LLM을 이용해 Select AI runsql 기능 테스트

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

SQL>
set timing on
select ai showsql 'Find the most expensive product in each category. Return the category, product name, brand, price, rating, and the price difference compared with the average price of that category.';
 
RESPONSE
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
SELECT "P"."CATEGORY" AS "Category",
       "P"."PRODUCT_NAME" AS "Product Name",
       "P"."BRAND" AS "Brand",
       "P"."PRICE" AS "Price",
       "P"."RATING" AS "Rating",
       ("P"."PRICE" - AVG("P2"."PRICE")) AS "Price Difference"
FROM "IMSI"."PRODUCTS" "P"
JOIN "IMSI"."PRODUCTS" "P2" ON "P"."CATEGORY" = "P2"."CATEGORY"
GROUP BY "P"."CATEGORY", "P"."PRODUCT_NAME", "P"."BRAND", "P"."PRICE", "P"."RATING"
HAVING "P"."PRICE" = MAX("P2"."PRICE")
 
Elapsed: 00:00:03.78
 
SQL>
set timing on
select ai runsql 'Find the most expensive product in each category. Return the category, product name, brand, price, rating, and the price difference compared with the average price of that category.';
 
Category             Product Name                   Brand           Price     Rating Price Difference
-------------------- ------------------------------ ---------- ---------- ---------- ----------------
Laptop               Galaxy Book Pro                Samsung       1890000        4.7       146666.667
Smartphone           iPhone 17                      Apple         1490000        4.9       146666.667
Earphones            AirPods Pro                    Apple          349000        4.8            60000
Monitor              OLED Gaming Monitor            LG             890000        4.6           120000
 
Elapsed: 00:00:03.47

openai 모델 사용시 어려운 질문도 잘 표시됨

참고로 로컬 LLM 모델 profile 설정 후 아래 SQL들을 10번 정도 연속으로 수행시키면 1번 정도는 제대로된 결과값이 나오는걸 확인하였음

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

SQL>
ALTER SYSTEM FLUSH SHARED_POOL;
 
exec dbms_cloud_ai.drop_profile(profile_name => 'TEST_LOCAL_SLM1');
 
BEGIN
  DBMS_CLOUD_AI.CREATE_PROFILE(
    profile_name => 'TEST_LOCAL_SLM1',
    attributes => '{"provider": "openai",
                    "comments": "true",
                    "model": "gpt-oss-20b",
                    "provider_endpoint": "https://ai.localllm.com",
                    "case_sensitive_values" : "false",
                    "temperature": 0.2,
                    "max_tokens": 4096,
                    "conversation": "true",
                    "credential_name": "LOCAL_SLM_CRED",
                    "object_list": [{"owner": "IMSI", "name": "PRODUCTS"}]}'
  );
END;
/
 
exec dbms_cloud_ai.set_profile (profile_name => 'TEST_LOCAL_SLM1');
 
set timing on
select ai runsql 'What is the most expensive product?';

결론 :
OpenAI 모델로 select ai 수행시 결과가 잘나오는 반면
로컬 LLM으로 select ai 수행시 결과가 제대로 나오지 않음
테스트를 위해 annotation까지 넣어봤지만 제대로 안된것을 보면 내 로컬 서버의 LLM 설정에 문제가 있을수도 있는듯함
추후 다시 테스트해봐야 할것 같음

참조 :

오라클 26ai 신기능 Select AI 사용 테스트(non-adb) ( https://positivemh.tistory.com/1205 )
https://docs.oracle.com/en/database/oracle/oracle-database/26/refrn/V-MAPPED_SQL.html

오라클 26ai deadlock 자동 테스트 스크립트

내맘대로긍정 — Sat, 1 Aug 2026 14:03:56 +0900

OS 환경 : Oracle Linux 9.6 (64bit)

DB 환경 : Oracle AI Database 23.26.2.0.0 ai

방법 : 오라클 26ai deadlock 자동 테스트 스크립트

일반적으로 deadlock을 발생시키려면 아래 글처럼 테이블을 생성하고 세션1, 세션2에서 각각 교차 dml을 수행하여야함
참고 : deadlock 발생 테스트 ORA-00060 ( https://positivemh.tistory.com/317 )
본문에서는 이 테스트를 스크립트 하나로 할수 있게끔 만든 스크립트를 설명하고 실제 수행해봄

참고로 현재 db 환경은 싱글 db 환경임

테스트

쉘스크립트 생성

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282

$ vi deadlock_test.sh
#!/bin/bash
 
set -uo pipefail
 
DB_CONNECT="${DB_CONNECT:-${1:-}}"
TABLE_NAME="${TABLE_NAME:-TEST_DEADLOCK}"
RUN_TIME=$(date '+%Y%m%d_%H%M%S')
OUTPUT_DIR="./deadlock_test_${RUN_TIME}"
TEMP_DIR=$(mktemp -d)
 
PID1=""
PID2=""
 
usage()
{
    echo "사용법"
    echo " $0 '사용자/비밀번호@서비스명'"
    echo
    echo "예시"
    echo " $0 'testuser/testpass@ORCL'"
    echo
    echo "환경 변수 사용"
    echo " DB_CONNECT='testuser/testpass@ORCL' $0"
}
 
if [ -z "$DB_CONNECT" ]; then
    usage
    exit 1
fi
 
if ! command -v sqlplus >/dev/null 2>&1; then
    echo "sqlplus 명령을 찾을 수 없음"
    exit 1
fi
 
case "$TABLE_NAME" in
    ''|*[!A-Za-z0-9_]*)
        echo "테이블명에는 영문, 숫자, 밑줄만 사용할 수 있음"
        exit 1
        ;;
esac
 
mkdir -p "$OUTPUT_DIR"
 
cleanup()
{
    if [ -n "$PID1" ] && kill -0 "$PID1" 2>/dev/null; then
        kill "$PID1" 2>/dev/null || true
    fi
 
    if [ -n "$PID2" ] && kill -0 "$PID2" 2>/dev/null; then
        kill "$PID2" 2>/dev/null || true
    fi
 
    sqlplus -s "$DB_CONNECT" > "$OUTPUT_DIR/cleanup.log" 2>&1 <<EOF
set echo off
set feedback off
whenever sqlerror continue
 
begin
    execute immediate 'drop table ${TABLE_NAME} purge';
exception
    when others then
        if sqlcode != -942 then
            raise;
        end if;
end;
/
 
exit
EOF
 
    rm -rf "$TEMP_DIR"
}
 
trap cleanup EXIT INT TERM
 
cat > "$TEMP_DIR/setup.sql" <<EOF
set echo on
set feedback on
set serveroutput on
whenever sqlerror exit failure rollback
 
begin
    execute immediate 'drop table ${TABLE_NAME} purge';
exception
    when others then
        if sqlcode != -942 then
            raise;
        end if;
end;
/
 
create table ${TABLE_NAME}
(
    id  number primary key,
    val number
);
 
insert into ${TABLE_NAME} values (1, 0);
insert into ${TABLE_NAME} values (2, 0);
 
commit;
 
select *
from ${TABLE_NAME}
order by id;
 
exit
EOF
 
cat > "$TEMP_DIR/session1.sql" <<EOF
set echo on
set feedback on
set timing on
set serveroutput on
 
alter session set tracefile_identifier = 'DEADLOCK_TEST_S1';
 
begin
    dbms_application_info.set_module(
        module_name => 'DEADLOCK_TEST',
        action_name => 'SESSION_1'
    );
end;
/
 
prompt
prompt ==========================================
prompt SESSION 1 : ID 1 행 잠금
prompt ==========================================
 
update ${TABLE_NAME}
   set val = val + 1
 where id = 1;
 
prompt SESSION 1 : ID 1 행 잠금 완료
prompt SESSION 1 : 5초 대기
 
begin
    dbms_session.sleep(5);
end;
/
 
prompt
prompt SESSION 1 : ID 2 행 잠금 시도
prompt SESSION 1 : SESSION 2가 보유한 잠금을 대기함
prompt
 
update ${TABLE_NAME}
   set val = val + 1
 where id = 2;
 
prompt
prompt SESSION 1 : ROLLBACK 수행
prompt
 
rollback;
 
exit
EOF
 
cat > "$TEMP_DIR/session2.sql" <<EOF
set echo on
set feedback on
set timing on
set serveroutput on
 
alter session set tracefile_identifier = 'DEADLOCK_TEST_S2';
 
begin
    dbms_application_info.set_module(
        module_name => 'DEADLOCK_TEST',
        action_name => 'SESSION_2'
    );
end;
/
 
prompt SESSION 2 : SESSION 1이 먼저 행을 잠그도록 1초 대기
 
begin
    dbms_session.sleep(1);
end;
/
 
prompt
prompt ==========================================
prompt SESSION 2 : ID 2 행 잠금
prompt ==========================================
 
update ${TABLE_NAME}
   set val = val + 1
 where id = 2;
 
prompt SESSION 2 : ID 2 행 잠금 완료
prompt SESSION 2 : 5초 대기
 
begin
    dbms_session.sleep(5);
end;
/
 
prompt
prompt SESSION 2 : ID 1 행 잠금 시도
prompt SESSION 2 : 데드락 발생
prompt
 
update ${TABLE_NAME}
   set val = val + 1
 where id = 1;
 
prompt
prompt SESSION 2 : ROLLBACK 수행
prompt
 
rollback;
 
exit
EOF
 
echo "테스트 테이블 생성"
 
sqlplus -s "$DB_CONNECT" @"$TEMP_DIR/setup.sql" \
    > "$OUTPUT_DIR/setup.log" 2>&1
 
SETUP_RESULT=$?
 
if [ "$SETUP_RESULT" -ne 0 ]; then
    echo "테스트 테이블 생성 실패"
    echo "로그 확인 : $OUTPUT_DIR/setup.log"
    exit 1
fi
 
echo "SESSION 1 실행"
 
sqlplus -s "$DB_CONNECT" @"$TEMP_DIR/session1.sql" \
    > "$OUTPUT_DIR/session1.log" 2>&1 &
 
PID1=$!
 
echo "SESSION 2 실행"
 
sqlplus -s "$DB_CONNECT" @"$TEMP_DIR/session2.sql" \
    > "$OUTPUT_DIR/session2.log" 2>&1 &
 
PID2=$!
 
wait "$PID1"
SESSION1_RESULT=$?
 
wait "$PID2"
SESSION2_RESULT=$?
 
PID1=""
PID2=""
 
echo
echo "=========================================="
echo "데드락 테스트 결과"
echo "=========================================="
 
if grep -q "ORA-00060" "$OUTPUT_DIR/session1.log" "$OUTPUT_DIR/session2.log"; then
    echo "ORA-00060 발생 확인"
    echo
 
    grep -H -B 2 -A 3 "ORA-00060" \
        "$OUTPUT_DIR/session1.log" \
        "$OUTPUT_DIR/session2.log"
else
    echo "ORA-00060이 확인되지 않음"
    echo "세션 로그를 확인해야 함"
fi
 
echo
echo "로그 경로"
echo " $OUTPUT_DIR/setup.log"
echo " $OUTPUT_DIR/session1.log"
echo " $OUTPUT_DIR/session2.log"
echo " $OUTPUT_DIR/cleanup.log"
echo
echo "테스트 종료"

스크립트 설명 :
사용방법 : sh deadlock.sh 사용자/비밀번호@서비스명 방식으로 수행여야함
동작 원리 :
스크립트를 실행하면 접속 정보로 데이터베이스에 접속한 뒤 TEST_DEADLOCK 테이블을 생성함
테이블에는 아래와 같이 두 건의 테스트 데이터를 입력함(ID 1, ID 2)
이후 두 개의 SQL*Plus 세션을 백그라운드로 실행함
SESSION 1은 ID 1 행을 먼저 UPDATE하여 잠금을 획득함
SESSION 2는 ID 2 행을 UPDATE하여 잠금을 획득함
각 세션은 잠금을 유지한 상태에서 5초 동안 대기함
대기 이후 SESSION 1은 SESSION 2가 잠근 ID 2 행의 UPDATE를 시도함
SESSION 2는 SESSION 1이 잠근 ID 1 행의 UPDATE를 시도함
두 세션이 서로 상대방의 잠금 해제를 기다리는 상태가 되면서 Deadlock이 발생함
Oracle은 Deadlock을 감지한 뒤 두 세션 중 하나에 ORA-00060 오류를 반환함
오류가 발생하는 세션은 실행 상황에 따라 달라질 수 있으므로 스크립트에서는 session1.log와 session2.log를 모두 확인함

스크립트에 권한 부여

1

$ chmod +x deadlock_test.sh

스크립트 수행

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

$ sh deadlock.sh eric/eric@ORACLE26PDB1
테스트 테이블 생성
SESSION 1 실행
SESSION 2 실행
 
==========================================
데드락 테스트 결과
==========================================
ORA-00060 발생 확인
 
./deadlock_test_20260728_083720/session1.log-             *
./deadlock_test_20260728_083720/session1.log-ERROR at line 2:
./deadlock_test_20260728_083720/session1.log:ORA-00060: deadlock detected while waiting for resource
./deadlock_test_20260728_083720/session1.log-Help: https://docs.oracle.com/error-help/db/ora-00060/
./deadlock_test_20260728_083720/session1.log-
./deadlock_test_20260728_083720/session1.log-
 
로그 경로
  ./deadlock_test_20260728_083720/setup.log
  ./deadlock_test_20260728_083720/session1.log
  ./deadlock_test_20260728_083720/session2.log
  ./deadlock_test_20260728_083720/cleanup.log
 
테스트 종료

정상적으로 테스트가 완료됨

alert log 확인

1
2
3
4
5
6

$ tail -300f /app/oracle/diag/rdbms/oracle26/ORACLE26/trace/alert_ORACLE26.log
...
2026-07-28T07:30:48.315521+09:00
ORACLE26PDB1(3):Errors in file /app/oracle/diag/rdbms/oracle26/ORACLE26/trace/ORACLE26_ora_1501177_DEADLOCK_TEST_S1.trc:
2026-07-28T07:30:49.735931+09:00
ORACLE26PDB1(3):ORA-00060: Deadlock detected. See Note 60.1 at My Oracle Support for Troubleshooting ORA-60 Errors. More info in file /app/oracle/diag/rdbms/oracle26/ORACLE26/trace/ORACLE26_ora_1501177_DEADLOCK_TEST_S1.trc.

alert log에 deadlock 이벤트가 발생함
멀티테넌트 환경이라서 pdb이름과 함께 ORA 메세지가 나옴

논cdb 환경이면 아래와 같이 에러가 발생함

1
2
3
4
5

$ tail -300f /app/oracle/diag/rdbms/oracle19/ORACLE19/trace/alert_ORACLE19.log
2026-07-28T07:51:55.506764+09:00
Errors in file /app/oracle/diag/rdbms/ora19dbfs/ORA19DBFS/trace/ORA19DBFS_ora_2863810_DEADLOCK_TEST_S1.trc:
2026-07-28T07:51:55.861872+09:00
ORA-00060: Deadlock detected. See Note 60.1 at My Oracle Support for Troubleshooting ORA-60 Errors. More info in file /app/oracle/diag/rdbms/ora19dbfs/ORA19DBFS/trace/ORA19DBFS_ora_2863810_DEADLOCK_TEST_S1.trc.

결론 :
빠르게 deadlock 에러(ORA-00060)을 발생시키고 싶은 경우 본문 스크립트를 사용하면됨

참조 :

deadlock 발생 테스트 ORA-00060 ( https://positivemh.tistory.com/317 )
https://docs.oracle.com/en/database/oracle/oracle-database/19/cncpt/data-concurrency-and-consistency.html#GUID-C1971E9B-849A-4634-9575-4F8FAD697750

오라클 19c insert 시 undo 발생량 확인 및 감소 테스트

내맘대로긍정 — Wed, 29 Jul 2026 22:21:01 +0900

OS 환경 : Oracle Linux 9.4 (64bit)

DB 환경 : Oracle Database 19.31.0.0

방법 : 오라클 19c insert 시 undo 발생량 확인 및 감소 테스트

대량 insert 시 undo 에러가 발생할 수 있음(ORA-30036: unable to extend segment by 8 in undo tablespace 'UNDOTBS1')
이때의 일반적인 방안으로는 undo tablespace 크기를 늘리거나, insert 단위를 쪼개는 방법이 있음
참고 : ORA-30036: unable to extend segment by 8 in undo tablespace 'UNDOTBS1' ( https://positivemh.tistory.com/377 )
하지만 이 방법 외에도 경우에 따라 본문에서 테스트한 방식을 사용하면 undo 사용량을 줄일 수 있음
본문에서는 대량 INSERT 시 방법에 따라 UNDO 사용량이 얼마나 달라지는지 확인해봄
각각 일반 insert시, append insert시, 인덱스 유지, 미유지시, 테이블 logging, nologging 경우 여러가지를 조합해서 테스트 해봄

테스트
테스트1. 일반 INSERT + 인덱스 유지
테스트2. 일반 INSERT + 인덱스 UNUSABLE
테스트3. 일반 INSERT + 인덱스 제거
테스트4. NOLOGGING + 일반 INSERT
테스트5. NOLOGGING + APPEND + 인덱스 유지
테스트6. NOLOGGING + APPEND + 인덱스 UNUSABLE

참고로 UNDO 사용량은 현재 세션의 트랜잭션 정보를 V$TRANSACTION에서 조회함
USED_UBLK : 현재 트랜잭션이 사용하는 UNDO 블록 수
USED_UREC : 현재 트랜잭션에서 생성된 UNDO 레코드 수

UNDO 정보는 트랜잭션이 종료되기 전에 확인해야 함
따라서 각 INSERT 실행 후 COMMIT 또는 ROLLBACK을 수행하기 전에 UNDO 사용량을 조회함

테스트
더미 테이블 생성 및 더미 데이터 삽입(10만건)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

SQL>
drop table undo_insert_src purge;
create table undo_insert_src
nologging
as
select level as id,
       mod(level, 1000) as group_id,
       cast(
           'C1_' || lpad(level, 10, '0') ||
           rpad('A', 80, 'A')
           as varchar2(100)
       ) as c1,
       cast(
           'C2_' || lpad(level, 10, '0') ||
           rpad('B', 80, 'B')
           as varchar2(100)
       ) as c2,
       cast(
           'C3_' || lpad(level, 10, '0') ||
           rpad('C', 80, 'C')
           as varchar2(100)
       ) as c3,
       date '2026-01-01' + mod(level, 365) as created_at
from dual
connect by level <= 100000;
 
SQL> select count(*) from undo_insert_src;
 
  COUNT(*)
----------
    100000

100000건 생성됨

INSERT 대상 테이블 생성

1
2
3
4
5
6
7
8
9
10
11
12

SQL>
drop table undo_insert_test purge;
create table undo_insert_test
(
    id          number,
    group_id    number,
    c1          varchar2(100),
    c2          varchar2(100),
    c3          varchar2(100),
    created_at  date
)
logging;

인덱스 갱신에 따른 UNDO 사용량 차이를 확인하기 위해 인덱스 3개 생성

1
2
3
4

SQL>
create index undo_insert_test_ix1 on undo_insert_test(id);
create index undo_insert_test_ix2 on undo_insert_test(group_id, created_at);
create index undo_insert_test_ix3 on undo_insert_test(c1);

테이블, 인덱스 상태 확인

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

SQL>
select table_name, logging
from dba_tables
where table_name = 'UNDO_INSERT_TEST';
 
TABLE_NAME                LOGGING
------------------------- ----------
UNDO_INSERT_TEST          YES
 
SQL>
col index_name for a30
select index_name, status
from dba_indexes
where table_name = 'UNDO_INSERT_TEST'
order by index_name;
 
INDEX_NAME                     STATUS
------------------------------ ----------
UNDO_INSERT_TEST_IX1           VALID
UNDO_INSERT_TEST_IX2           VALID
UNDO_INSERT_TEST_IX3           VALID

테이블은 logging 상태, 인덱스는 valid 상태임

현재 세션 UNDO 사용량 조회

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

SQL>
set lines 200 pages 1000
col xid for a20
col undo_mb for 999,999,990.00
select s.sid,
       s.serial#,
       rawtohex(t.xid) as xid,
       t.used_ublk,
       t.used_urec,
       round(
           t.used_ublk * to_number(p.value) / 1024 / 1024,
           2
       ) as undo_mb
from v$session s,
     v$transaction t,
     v$parameter p
where s.taddr = t.addr
and s.sid = sys_context('USERENV', 'SID')
and p.name = 'db_block_size';
 
no rows selected

현재는 undo를 사용하지 않고 있음
USED_UBLK : 현재 트랜잭션이 사용하는 UNDO 블록 수
USED_UREC : 현재 트랜잭션에서 생성된 UNDO 레코드 수
UNDO_MB : USED_UBLK와 DB_BLOCK_SIZE를 이용해 계산한 대략적인 UNDO 사용량

테스트1. 일반 INSERT + 인덱스 유지
인덱스가 정상 상태인 테이블에 일반 INSERT를 수행

1
2
3
4
5
6

SQL> 
insert /*+ noappend */ into undo_insert_test
select *
from undo_insert_src;
 
100000 rows created.

insert 수행 후 commit이나 rollback을 실행하지 않은 상태에서 undo 사용량 확인

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

SQL>
select s.sid,
       s.serial#,
       rawtohex(t.xid) as xid,
       t.used_ublk,
       t.used_urec,
       round(
           t.used_ublk * to_number(p.value) / 1024 / 1024,
           2
       ) as undo_mb
from v$session s,
     v$transaction t,
     v$parameter p
where s.taddr = t.addr
and s.sid = sys_context('USERENV', 'SID')
and p.name = 'db_block_size';
 
       SID    SERIAL# XID                   USED_UBLK  USED_UREC         UNDO_MB
---------- ---------- -------------------- ---------- ---------- ---------------
       284      14279 08001400B5370000           2372      42748           18.53

rollback 수행

1
2
3

SQL> rollback;
 
Rollback complete.

테스트1. 결론 :
18.53mb의 undo를 사용함

테스트2. 인덱스 UNUSABLE + 일반 INSERT

인덱스 UNUSABLE 상태로 변경

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

SQL>
alter session set skip_unusable_indexes = true;
alter index undo_insert_test_ix1 unusable;
alter index undo_insert_test_ix2 unusable;
alter index undo_insert_test_ix3 unusable;
 
select index_name,
       status
from dba_indexes
where table_name = 'UNDO_INSERT_TEST'
order by index_name;
 
INDEX_NAME                     STATUS
------------------------------ ----------
UNDO_INSERT_TEST_IX1           UNUSABLE
UNDO_INSERT_TEST_IX2           UNUSABLE
UNDO_INSERT_TEST_IX3           UNUSABLE

인덱스를 UNUSABLE 상태로 변경한 후 일반 INSERT 수행

1
2
3
4
5
6

SQL>
insert /*+ noappend */ into undo_insert_test
select *
from undo_insert_src;
 
100000 rows created.

insert 수행 후 commit이나 rollback을 실행하지 않은 상태에서 undo 사용량 확인

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

SQL>
select s.sid,
       s.serial#,
       rawtohex(t.xid) as xid,
       t.used_ublk,
       t.used_urec,
       round(
           t.used_ublk * to_number(p.value) / 1024 / 1024,
           2
       ) as undo_mb
from v$session s,
     v$transaction t,
     v$parameter p
where s.taddr = t.addr
and s.sid = sys_context('USERENV', 'SID')
and p.name = 'db_block_size';
 
       SID    SERIAL# XID                   USED_UBLK  USED_UREC         UNDO_MB
---------- ---------- -------------------- ---------- ---------- ---------------
       284      14279 05000400DE370000             92       7891            0.72

rollback 수행

1
2
3

SQL> rollback;
 
Rollback complete.

테스트2. 결론 :
0.72mb의 undo를 사용함

다음 테스트를 위해 인덱스 REBUILD

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

SQL>
alter index undo_insert_test_ix1 rebuild;
alter index undo_insert_test_ix2 rebuild;
alter index undo_insert_test_ix3 rebuild;
 
select index_name,
       status
from dba_indexes
where table_name = 'UNDO_INSERT_TEST'
order by index_name;
 
INDEX_NAME                     STATUS
------------------------------ ----------
UNDO_INSERT_TEST_IX1           VALID
UNDO_INSERT_TEST_IX2           VALID
UNDO_INSERT_TEST_IX3           VALID

테스트 3 인덱스 제거 + 일반 INSERT
인덱스를 완전히 제거한 상태에서 일반 INSERT를 수행함

1
2
3
4
5
6
7
8
9
10
11
12

SQL>
truncate table undo_insert_test;
drop index undo_insert_test_ix1;
drop index undo_insert_test_ix2;
drop index undo_insert_test_ix3;
 
select index_name,
       status
from dba_indexes
where table_name = 'UNDO_INSERT_TEST';
 
no rows selected

일반 INSERT 수행

1
2
3
4
5
6

SQL>
insert /*+ noappend */ into undo_insert_test
select *
from undo_insert_src;
 
100000 rows created.

insert 수행 후 commit이나 rollback을 실행하지 않은 상태에서 undo 사용량 확인

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

SQL>
select s.sid,
       s.serial#,
       rawtohex(t.xid) as xid,
       t.used_ublk,
       t.used_urec,
       round(
           t.used_ublk * to_number(p.value) / 1024 / 1024,
           2
       ) as undo_mb
from v$session s,
     v$transaction t,
     v$parameter p
where s.taddr = t.addr
and s.sid = sys_context('USERENV', 'SID')
and p.name = 'db_block_size';
 
       SID    SERIAL# XID               USED_UBLK  USED_UREC    UNDO_MB
---------- ---------- ---------------- ---------- ---------- ----------
       285      39080 0A0014003F340000         92       7891        .72

rollback 수행

1
2
3

SQL> rollback;
 
Rollback complete.

테스트3. 결론 :
0.72mb의 undo를 사용함

다음 테스트를 위해 제거한 인덱스 재생성

1
2
3
4

SQL>
create index undo_insert_test_ix1 on undo_insert_test(id);
create index undo_insert_test_ix2 on undo_insert_test(group_id, created_at);
create index undo_insert_test_ix3 on undo_insert_test(c1);

테스트4. NOLOGGING + 일반 INSERT
테이블의 LOGGING 속성만 NOLOGGING으로 변경한 후 일반 INSERT를 수행
NOAPPEND 힌트를 사용해 Conventional Path INSERT로 실행함

1
2
3
4
5
6
7
8
9
10
11
12

SQL>
truncate table undo_insert_test;
alter table undo_insert_test nologging;
 
select table_name,
       logging
from dba_tables
where table_name = 'UNDO_INSERT_TEST';
 
TABLE_NAME           LOG
-------------------- ---
UNDO_INSERT_TEST     NO

일반 INSERT 수행

1
2
3
4
5
6

SQL>
insert /*+ noappend */ into undo_insert_test
select *
from undo_insert_src;
 
100000 rows created.

insert 수행 후 commit이나 rollback을 실행하지 않은 상태에서 undo 사용량 확인

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

SQL>
select s.sid,
       s.serial#,
       rawtohex(t.xid) as xid,
       t.used_ublk,
       t.used_urec,
       round(
           t.used_ublk * to_number(p.value) / 1024 / 1024,
           2
       ) as undo_mb
from v$session s,
     v$transaction t,
     v$parameter p
where s.taddr = t.addr
and s.sid = sys_context('USERENV', 'SID')
and p.name = 'db_block_size';
 
       SID    SERIAL# XID               USED_UBLK  USED_UREC    UNDO_MB
---------- ---------- ---------------- ---------- ---------- ----------
       285      39080 06001600DA390000       2372      42748      18.53

rollback 수행

1
2
3

SQL> rollback;
 
Rollback complete.

테스트4. 결론 :
18.53mb의 undo를 사용함
NOLOGGING은 주로 REDO 생성량을 줄이기 위한 속성임
일반 INSERT에서는 테이블을 NOLOGGING으로 변경해도 테이블 데이터와 인덱스 변경을 위한 UNDO가 생성됨
따라서 테스트 1과 비교했을 때 UNDO 사용량 차이가 나지 않음

테스트5. NOLOGGING + APPEND + 인덱스 유지
테이블을 NOLOGGING으로 변경하고 APPEND 힌트를 사용해 Direct Path INSERT를 수행함
인덱스는 정상 상태로 유지함

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

SQL>
truncate table undo_insert_test;
alter table undo_insert_test nologging;
 
select index_name,
       status
from dba_indexes
where table_name = 'UNDO_INSERT_TEST'
order by index_name;
 
INDEX_NAME                     STATUS
------------------------------ ----------
UNDO_INSERT_TEST_IX1           VALID
UNDO_INSERT_TEST_IX2           VALID
UNDO_INSERT_TEST_IX3           VALID

APPEND 힌트를 사용해 INSERT

1
2
3
4
5
6

SQL>
insert /*+ append */ into undo_insert_test
select *
from undo_insert_src;
 
100000 rows created.

insert 수행 후 commit이나 rollback을 실행하지 않은 상태에서 undo 사용량 확인

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

SQL>
select s.sid,
       s.serial#,
       rawtohex(t.xid) as xid,
       t.used_ublk,
       t.used_urec,
       round(
           t.used_ublk * to_number(p.value) / 1024 / 1024,
           2
       ) as undo_mb
from v$session s,
     v$transaction t,
     v$parameter p
where s.taddr = t.addr
and s.sid = sys_context('USERENV', 'SID')
and p.name = 'db_block_size';
 
       SID    SERIAL# XID               USED_UBLK  USED_UREC    UNDO_MB
---------- ---------- ---------------- ---------- ---------- ----------
       285      39080 0300060038370000       1803       4107      14.09

rollback 수행

1
2
3

SQL> rollback;
 
Rollback complete.

테스트5. 결론 :
14.09mb의 undo를 사용함
Direct Path INSERT는 기존 블록의 빈 공간을 찾아 데이터를 입력하지 않고 High Water Mark 이후의 새로운 블록에 데이터를 적재함
이 방식은 Conventional Path INSERT보다 테이블 데이터에 대한 UNDO 사용량을 줄일 수 있음
다만 사용 가능한 인덱스가 존재하면 인덱스 갱신 작업에 대한 UNDO는 계속 발생함

테스트6. NOLOGGING + APPEND + 인덱스 UNUSABLE
인덱스를 UNUSABLE 상태로 변경한 후 NOLOGGING과 APPEND를 적용함
테이블 데이터는 Direct Path 방식으로 적재하고 인덱스는 갱신하지 않음

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

SQL>
truncate table undo_insert_test;
alter table undo_insert_test nologging;
alter session set skip_unusable_indexes = true;
alter index undo_insert_test_ix1 unusable;
alter index undo_insert_test_ix2 unusable;
alter index undo_insert_test_ix3 unusable;
 
select index_name,
       status
from dba_indexes
where table_name = 'UNDO_INSERT_TEST'
order by index_name;
 
INDEX_NAME                     STATUS
------------------------------ --------
UNDO_INSERT_TEST_IX1           UNUSABLE
UNDO_INSERT_TEST_IX2           UNUSABLE
UNDO_INSERT_TEST_IX3           UNUSABLE

APPEND 힌트를 사용해 INSERT

1
2
3
4
5
6

SQL>
insert /*+ append */ into undo_insert_test
select *
from undo_insert_src;
 
100000 rows created.

insert 수행 후 commit이나 rollback을 실행하지 않은 상태에서 undo 사용량 확인

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

SQL>
select s.sid,
       s.serial#,
       rawtohex(t.xid) as xid,
       t.used_ublk,
       t.used_urec,
       round(
           t.used_ublk * to_number(p.value) / 1024 / 1024,
           2
       ) as undo_mb
from v$session s,
     v$transaction t,
     v$parameter p
where s.taddr = t.addr
and s.sid = sys_context('USERENV', 'SID')
and p.name = 'db_block_size';
 
       SID    SERIAL# XID               USED_UBLK  USED_UREC    UNDO_MB
---------- ---------- ---------------- ---------- ---------- ----------
       277      27133 03000700BC370000          1          1        .01

rollback 수행

1
2
3

SQL> rollback;
 
Rollback complete.

테스트6. 결론 :
0.01mb의 undo를 사용함
테이블 데이터 적재에 필요한 UNDO가 감소하고 인덱스 갱신도 수행하지 않으므로 이번 테스트 중 UNDO 사용량이 가장 적음
Direct Path INSERT는 기존 블록의 빈 공간을 찾아 데이터를 입력하지 않고 High Water Mark 이후의 새로운 블록에 데이터를 적재함
이 방식은 Conventional Path INSERT보다 테이블 데이터에 대한 UNDO 사용량을 줄일 수 있음

테스트 끝. 인덱스를 다시 REBUILD

1
2
3
4

SQL>
alter index undo_insert_test_ix1 rebuild;
alter index undo_insert_test_ix2 rebuild;
alter index undo_insert_test_ix3 rebuild;

테이블을 LOGGING으로 변경

1
2
3

SQL> alter table undo_insert_test logging;
 
Table altered.

테스트 결과 정리 :
10만 건 INSERT를 기준으로 일반 INSERT, 인덱스 상태, NOLOGGING, APPEND 적용 여부에 따른 UNDO 사용량을 비교함

테스트1. 일반 INSERT + 인덱스 유지
USED_UBLK : 2,372
USED_UREC : 42,748
UNDO 사용량 : 18.53MB
인덱스가 정상 상태인 테이블에 일반 INSERT를 수행한 결과 18.53MB의 UNDO를 사용함
테이블 데이터 입력과 인덱스 3개에 대한 갱신이 함께 수행되어 테스트 중 두 번째로 많은 UNDO를 사용함

테스트2. 인덱스 UNUSABLE + 일반 INSERT
USED_UBLK : 92
USED_UREC : 7,891
UNDO 사용량 : 0.72MB
인덱스를 UNUSABLE 상태로 변경한 후 일반 INSERT를 수행한 결과 0.72MB의 UNDO를 사용함
인덱스를 유지한 테스트1과 비교하면 UNDO 사용량이 약 96.1% 감소함
테이블 데이터에 대한 UNDO는 생성되지만 인덱스 갱신이 수행되지 않아 UNDO 사용량이 크게 감소함

테스트3. 인덱스 제거 + 일반 INSERT
USED_UBLK : 92
USED_UREC : 7,891
UNDO 사용량 : 0.72MB
인덱스를 제거한 후 일반 INSERT를 수행한 결과 0.72MB의 UNDO를 사용함
인덱스를 UNUSABLE 상태로 변경한 테스트2와 동일한 결과가 확인됨
인덱스를 제거하거나 UNUSABLE 상태로 변경하는 두 방식 모두 INSERT 과정에서 인덱스 갱신을 수행하지 않으므로 UNDO 사용량 측면에서는 동일한 효과가 나타남

테스트4. NOLOGGING + 일반 INSERT
USED_UBLK : 2,372
USED_UREC : 42,748
UNDO 사용량 : 18.53MB
테이블을 NOLOGGING으로 변경한 후 일반 INSERT를 수행한 결과 18.53MB의 UNDO를 사용함
LOGGING 상태에서 수행한 테스트1과 동일한 결과가 확인됨
NOLOGGING은 REDO 생성량을 줄이기 위한 설정이고 일반 INSERT에서 발생하는 테이블과 인덱스 변경에 대한 UNDO 사용량은 줄이지 못함

테스트5. NOLOGGING + APPEND + 인덱스 유지
USED_UBLK : 1,803
USED_UREC : 4,107
UNDO 사용량 : 14.09MB
NOLOGGING 상태에서 APPEND 힌트를 사용하고 인덱스를 유지한 결과 14.09MB의 UNDO를 사용함
일반 INSERT를 수행한 테스트1과 비교하면 UNDO 사용량이 약 24.0% 감소함
APPEND를 사용하면서 테이블 데이터 적재에 필요한 UNDO는 감소했지만 인덱스가 VALID 상태로 유지되어 인덱스 갱신에 대한 UNDO가 계속 발생함
APPEND만 적용해도 UNDO 사용량이 일부 감소하지만 인덱스가 존재하는 경우 감소 효과는 제한적임

테스트6. NOLOGGING + APPEND + 인덱스 UNUSABLE
USED_UBLK : 1
USED_UREC : 1
UNDO 사용량 : 0.01MB
인덱스를 UNUSABLE 상태로 변경하고 NOLOGGING과 APPEND를 적용한 결과 0.01MB의 UNDO를 사용함
일반 INSERT를 수행한 테스트1과 비교하면 UNDO 사용량이 약 99.9% 감소함
APPEND를 통해 테이블 데이터 적재에 대한 UNDO를 최소화하고 인덱스를 UNUSABLE 상태로 변경해 인덱스 갱신도 수행하지 않았기 때문에 가장 적은 UNDO를 사용함

테스트 결과 비교

테스트	조건	UNDO 사용량	기준 대비 감소율
테스트 1	일반 INSERT + 인덱스 유지	18.53MB	기준값
테스트 2	인덱스 UNUSABLE + 일반 INSERT	0.72MB	약 96.1%
테스트 3	인덱스 제거 + 일반 INSERT	0.72MB	약 96.1%
테스트 4	NOLOGGING + 일반 INSERT	18.53MB	0%
테스트 5	NOLOGGING + APPEND + 인덱스 유지	14.09MB	약 24.0%
테스트 6	NOLOGGING + APPEND + 인덱스 UNUSABLE	0.01MB	약 99.9%

결론 :
본문 테스트와 같이 대량 INSERT 시 UNDO 사용량을 줄이기 위해선 테이블 nologging과 append 힌트, 그리고 index의 unusable 상태로 해놓는것이 좋음(테이블 nologging은 undo 사용량을 줄일순 없지만 redo 발생량을 감소시켜 성능에 도움이 됨)
만약 이관시 초기테이터를 넣거나 초기이관등을 할때 undo 에러가 발생한다면(ORA-30036: unable to extend segment by 8 in undo tablespace 'UNDOTBS1') 본문 방식을 적용해보면 도움이 될 수 있음
이후 데이터 적재가 완료된 후 인덱스를 REBUILD하는 방법이 가장 효과적임
다만 NOLOGGING을 사용한 작업은 미디어 복구와 백업에 영향을 줄 수 있으므로 운영 환경에서는 FORCE LOGGING 설정과 백업 정책을 함께 확인해야 함

참조 :

오라클 19c insert append, append_values 힌트 속도 비교 테스트 ( https://positivemh.tistory.com/851 )
ORA-30036: unable to extend segment by 8 in undo tablespace 'UNDOTBS1' ( https://positivemh.tistory.com/377 )
https://docs.oracle.com/en/database/oracle/oracle-database/19/admin/managing-tables.html#GUID-E9EB5D85-49D8-4A29-9DF3-A7CBBA484EE3
https://docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf/logging_clause.html

AIX nmon 명령어를 이용한 시스템 자원 모니터링

내맘대로긍정 — Sun, 26 Jul 2026 10:28:08 +0900

OS 환경 : AIX 7.2 (64bit)

DB 환경 : Oracle Database 19.27.0.0

방법 : AIX nmon 명령어를 이용한 시스템 자원 모니터링

AIX에서 CPU와 메모리 사용률을 확인할 때 일반적으로 topas 명령어를 많이 사용함
topas는 별도의 옵션 없이 바로 실행할 수 있고 CPU, 메모리, 디스크, 네트워크, 프로세스 등의 정보를 한 화면에서 확인할 수 있어 간단한 상태 점검에 유용함
다만 topas는 화면에 표시되는 항목이 정해져 있어 CPU와 메모리 사용률을 그래프 형태로 확인하면서 CPU 사용률이 높은 프로세스를 함께 확인하려는 경우 다소 불편할 수 있음
이 경우 nmon 명령어를 사용하면 필요한 항목을 선택하여 한 화면에 표시할 수 있음
nmon을 이용하면 CPU, 메모리, Paging Space, 디스크 I/O, 네트워크, LPAR 정보, 상위 프로세스 등의 정보를 실시간으로 확인할 수 있고 일정 시간 동안 파일로 수집하여 사후 분석에도 사용할 수 있음

기본 사용법
nmon 실행

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

$ nmon
┌──────────────────────────────────────────────────────────────────────────────────────
│  ------------------------------                                                      
│  N    N  M    M   OOOO   N    N   For online help type: h                            
│  NN   N  MM  MM  O    O  NN   N   For command line option help:                      
│  N N  N  M MM M  O    O  N N  N      quick-hint  nmon -?                             
│  N  N N  M    M  O    O  N  N N    full-details  nmon -h                             
│  N   NN  M    M  O    O  N   NN   To start nmon the same way every time?             
│  N    N  M    M   OOOO   N    N    set NMON ksh variable, for example:               
│  ------------------------------    export NMON=cmt                                   
│    TOPAS_NMON                                                                        
│                              96 - CPUs currently                                     
│                              96 - CPUs configured                                    
│                            3525 - MHz CPU clock rate (press 'r' for current MHz)     
│                  PowerPC_POWER8 - Processor                                          
│                          64 bit - Hardware                                           
│                          64 bit - Kernel                                             
│                      1,68-7538X - Logical Partition                                  
│                  7.2.5.105 TL05 - AIX Kernel Version                                 
│                         aixdb01 - Hostname                                           
│                         aixdb01 - Node/WPAR Name                                     
│                         687538X - Serial Number                                      
│                    IBM,8286-42A - Machine Type                                       

nmon을 실행한 뒤 h 키를 누르면 사용할 수 있는 단축키와 옵션을 확인할 수 있음
각 항목은 해당 키를 누르면 화면에 표시되고 같은 키를 다시 누르면 화면에서 제거됨

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

(h 입력)
┌─HELP─────────most-keys-toggle-on/off───────────────────────────────────────────────────────
│h = Help information     q = Quit nmon             0 = reset peak counts                    
│+ = double refresh time  - = half refresh          r = ResourcesCPU/HW/MHz/AIX              
│c = CPU by processor     C = upto 1536 CPUs        p = LPAR Stats (if LPAR)                 
│l = CPU avg longer term  k = Kernel Internal                                                
│# = PhysicalCPU if SPLPAR --> Applicable only in c,C,v,l panels                             
│m = Memory & Paging      M = Multiple Page Sizes   P = Paging Space                         
│d = DiskI/O Graphs       D = DiskIO +Service times o = Disks %Busy Map                      
│a = Disk Adapter         e = ESS vpath stats       V = Volume Group stats                   
│^ = FC Adapter (fcstat)  O = VIOS SEA (entstat)    v = Verbose=OK/Warn/Danger               
│n = Network stats        N = NFS stats (NN for v4) j = JFS Usage stats                      
│A = Async I/O Servers    w = see AIX wait procs   "=" = Net/Disk KB<-->MB                   
│b = black&white mode     g = User-Defined-Disk-Groups (see cmdline -g)                      
│t = Top-Process --->     1=basic 2=CPU-Use 3=CPU(default) 4=Size 5=Disk-I/O                 
│u = Top+cmd arguments    U = Top+WLM Classes       . = only busy disks & procs              
│W = WLM Section          S = WLM SubClasses        @ = Workload Partition(WPAR)             
│[ = Start ODR            ] = Stop ODR              i = Top-Thread                           
│~ = Switch to topas screen                                                                  
│Need more details?  Then stop nmon and use: nmon -?                                         

help 창이 표시됨

대표적인 nmon 단축키
h : 도움말 화면을 표시함
c : CPU별 사용률을 표시함
C : CPU 개수가 많은 시스템에서 전체 CPU 사용률을 큰 화면으로 표시함
m : 메모리 사용률과 페이징 관련 정보를 표시함
P : Paging Space 사용 현황을 표시함
d : 디스크별 사용률과 처리량을 표시함
D : 디스크의 상세 I/O 정보를 표시함
n : 네트워크 인터페이스별 송수신량을 표시함
t : CPU와 메모리 사용량이 높은 프로세스를 표시함
p : LPAR, Entitled Capacity, Physical CPU 등의 정보를 표시함
j : 파일시스템 사용률을 표시함
r : 서버명, AIX 버전, CPU, 메모리 등의 시스템 정보를 표시함
q : nmon을 종료함

Top Process 화면 모드
nmon 실행 후 t 키를 누르면 CPU와 메모리를 많이 사용하는 프로세스 목록을 확인할 수 있음

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

(t 입력)
┌─topas_nmon──r=Resources────────Host=aixdb01────────Refresh=2 secs───17:08.14──────────────────────────────────────────────────────────────────────────────────────┐
│ Top-Processes-(1115) ────Mode=3  [1=Basic 2=CPU 3=Perf 4=Size 5=I/O 6=Cmds]───────────────────────────────────────────────────────────────────────────────────────│
│  PID       %CPU     Size      Res     Res      Res     Char    RAM      Paging         Command                                                                    │
│            Used       KB      Set     Text     Data     I/O     Use   io   other repage                                                                           │
│ 9765130    44.9    14308    14240      564    13676       46    0%      0  75662      0 topas_nmon                                                                │
│ 2425330     0.0      512      512        0      512        0    0%      0      0      0 wlmsched                                                                  │
│ 2490632     0.0        0        0        0        0        0    0%      0      0      0 <defunct Zombie>                                                          │
│ 2556188     0.0     1236      976      116      860        0    0%      0      0      0 errdemon                                                                  │
│ 2621710     0.0      448      448        0      448        0    0%      0      0      0 memp_rbd                                                                  │
│ 2687362     0.0      448      448        0      448        0    0%      0      0      0 j2gt                                                                      │
│ 2752810     0.0      448      448        0      448        0    0%      0      0      0 lvmbb                                                                     │
│ 2818356     0.0      448      448        0      448        0    0%      0      0      0 j2gt                                                                      │
│ 2883896     0.0    12736    12736        0    12736        0    0%      0      0      0 dog                                                                       │
│ 2949546     0.0     1976      972      248      724        0    0%      0      0      0 clcomd                                                                    │
│ 3014974     0.0      448      448        0      448        0    0%      0      0      0 MUSENT Kproc                                                              │
│ 3146054     0.0      448      448        0      448        0    0%      0      0      0 MUSENT Kproc                                                              │
│ 3211640     0.0     1636     1104      256      848        0    0%      0      0      0 snmpmibd                                                                  │
│ 3342790     0.0      636      596      252      344        0    0%      0      0      0 xntpd                                                                     │
│ 3408282     0.0      820      676       52      624        0    0%      0      0      0 syslogd                                                                   │
│ 3539384     0.0     1196      668       56      612        0    0%      0      0      0 pfcdaemon                                                                 │
│ 3604960     0.0     6268     6716      960     5756        0    0%      0      0      0 IBM.MgmtDomainRMd                                                         │
│ 3670302     0.0   397560   212740   200576    12164        0    1%      0      0      0 oracle                                                                    │
│ 3801524     0.0      448      448        0      448        0    0%      0      0      0 local_sa                                                                  │
│ 3866946     0.0   412376   285064   273280    11784        0    1%      0      0      0 oracle                                                                    │
│ 3932630     0.0      448      448        0      448        0    0%      0      0      0 smcr_mmc_wq                                                               │
│ 4063708     0.0     1216     1216        0     1216        0    0%      0      0      0 rpc.lockd                                                                 │
│ 4129266     0.0   404664   219844   200576    19268        0    1%      0      0      0 oracle                                                                    │
│ 4260330     0.0      448      448        0      448        0    0%      0      0      0 URH-END-IO-Handler                                                        │
│ 4325868     0.0      448      448        0      448        0    0%      0      0      0 URH-END-IO-Handler                                                        │
│ 4391406     0.0      448      448        0      448        0    0%      0      0      0 URH-END-IO-Handler                                                        │
│ 4456946     0.0      448      448        0      448        0    0%      0      0      0 URH-END-IO-Handler                                                        │
│ 4522490     0.0      448      448        0      448        0    0%      0      0      0 URH-END-IO-Handler                                                        │
│ 4588030     0.0      448      448        0      448        0    0%      0      0      0 URH-END-IO-Handler                                                        │
│ 4653318     0.0      448      448        0      448        0    0%      0      0      0 URH-END-IO-Handler                                                        │
│ 4718856     0.0      448      448        0      448        0    0%      0      0      0 URH-END-IO-Handler                                                        │
│ 4784396     0.0      448      448        0      448        0    0%      0      0      0 URH-END-IO-Handler                                                        │
│ 4849936     0.0      448      448        0      448        0    0%      0      0      0 URH-END-IO-Handler                                                        │
│ 4915492     0.0      448      448        0      448        0    0%      0      0      0 URH-END-IO-Handler                                                        │
│ 4981032     0.0      448      448        0      448        0    0%      0      0      0 URH-END-IO-Handler                                                        │
│ 5046570     0.0      448      448        0      448        0    0%      0      0      0 URH-END-IO-Handler                                                        │
│ 5112108     0.0      448      448        0      448        0    0%      0      0      0 URH-END-IO-Handler                                                        │
│ 5177646     0.0      448      448        0      448        0    0%      0      0      0 URH-END-IO-Handler                                                        │
│ 5243184     0.0      448      448        0      448        0    0%      0      0      0 URH-END-IO-Handler                                                        │
│ 5308722     0.0      448      448        0      448        0    0%      0      0      0 URH-END-IO-Handler                                                        │
└───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
 

Top Process 화면에서는 숫자 키를 이용하여 표시 방식을 변경할 수 있음
1 : 기본 프로세스 정보를 표시함
2 : CPU 사용률 중심으로 표시함
3 : CPU, 메모리, I/O 정보를 포함한 성능 정보를 표시함
4 : 프로세스의 메모리 크기 정보를 표시함
5 : 프로세스별 I/O 정보를 표시함
6 : 프로세스의 실행 명령어를 표시함
CPU 사용률이 높은 프로세스를 확인하려면 t 키를 누른 뒤 2 또는 3 키를 사용하면 됨

CPU, 메모리, 프로세스를 한 화면에서 확인

1

$ nmon -B -s 2

nmon -B -s 2 옵션 설명
nmon : nmon을 실시간 화면 모드로 실행함
-B : 각 모니터링 항목에 표시되는 박스 테두리를 제거함
-s 2 : 시스템 자원 정보를 2초마다 갱신함
-B 옵션을 사용하면 화면의 테두리가 줄어들기 때문에 CPU, 메모리, 프로세스 정보를 한 화면에 더 많이 표시할 수 있음
터미널 창의 세로 크기가 작으면 하단의 프로세스 목록이 잘릴 수 있기 때문에 터미널 창의 크기를 크게 조정해야 함

위 명령 실행 후 아래 키를 차례대로 천천히 입력함(참고로 CPU 개수가 많지 않은 시스템에서는 C 대신 c를 사용해도 됨)

1
2
3
4

(C 입력)
(m 입력)
(t 입력)
(3 입력)

옵션 설명 :
c 또는 C : CPU 사용률을 표시함
m : 메모리 정보를 표시함
t : Top Process 정보를 표시함
3 : Top Process 화면을 성능 정보 모드로 변경함

실행 결과 창

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

--topas_nmon--2=Top-Child-CPU----Host=aixdb01--------Refresh=2 secs---17:13.20--
  CPU-Utilisation-Large-View ---------------------------------------------------------------------------------------------------------------------------------------
 100%+---------+---------+---------+---------+---------+---------+----+100%
 90%-|                                                                |-90%
 80%-|                                                                |-80%
 70%-|                                                                |-70%
 60%-|                                                                |-60%
 50%-|                                                                |-50%
 40%-|                                                                |-40%
 30%-|                                                                |-30%
 20%-|                                                                |-20%
 10%-|    .   .                                   .       .   .   .   |-10% ..
 CPU +1--------+10-------+20-------+30-------+40-------+50-------+60--+-Avg=LP
 100%+---------+---------+---------+---------+---------+---------+----+100%
 90%-|                                                                |-90%
 80%-|                                                                |-80%
 70%-|                                                                |-70%
 60%-|                                                                |-60%
 50%-|                                                                |-50%
 40%-|                                                                |-40%
 30%-|                            s                                   |-30%
 20%-|        s           s   s   s                                   |-20%
 10%-|.       U   .   .   U   U   U                                   |-10%
 CPU +65---+70-------+80-------+90-------+100------+110------+120-----
  Memory -----------------------------------------------------------------------------------------------------------------------------------------------------------
           Physical  PageSpace |        pages/sec  In     Out | FileSystemCache
 % Used       96.2%      1.1%  | to Paging Space   0.0    0.0 | (numperm) 18.6%
 % Free        3.8%     98.9%  | to File System    0.0  137.0 | Process   60.0%
 MB Used   28811.4MB   209.9MB | Page Scans        0.0        | System    17.6%
 MB Free    1140.6MB 19758.1MB | Page Cycles       0.0        | Free       3.8%
 Total(MB) 29952.0MB 19968.0MB | Page Steals       0.0        |           ------
                               | Page Faults    7847.2 .1     | Total    100.0%
 ------------------------------------------------------------ | numclient 18.6%
 Min/Maxperm     862MB(  3%)  25862MB( 90%) <--% of RAM       | maxclient 90.0%
 Min/Maxfree     960   1088       Total Virtual   48.8GB      | User      74.8%
 Min/Maxpgahead    2      8    Accessed Virtual   21.5GB 44.1%| Pinned    26.0%
                                                              | lruable pages   7356320.0
  Top-Processes-(1127) ----Mode=3  [1=Basic 2=CPU 3=Perf 4=Size 5=I/O 6=Cmds]---------------------------------------------------------------------------------------
   PID       %CPU     Size      Res     Res      Res     Char    RAM      Paging         Command
             Used       KB      Set     Text     Data     I/O     Use   io   other repage
 11797542    57.3      868      904      308      596      143    0%      0      0      0 ksh
  8389610     7.3   177396   271036   196212    74824        0    1%      0    972      0 orarootagent.bin
 11601082     2.2   424280   296968   273280    23688        0    1%      0      0      0 oracle
 13763102     1.8   141396   141404        8   141396     1133    0%      0      2      0 osysmond.bin
 -------------------------------------------------------------------------------------------------------------------------------------------------------------------

화면 상단에는 CPU 사용률 그래프가 표시되고 중간에는 메모리 사용 현황, 하단에는 CPU 사용률이 높은 프로세스 목록이 표시됨

출력 화면은 CPU, Memory, Top Processes 영역으로 구분됨
CPU-Utilisation-Large-View 영역에서는 CPU별 User, System, Wait, Idle 사용률을 그래프 형태로 확인할 수 있음
Memory 영역에서는 Physical Memory, Paging Space, Page In, Page Out, File System Cache 등의 정보를 확인할 수 있음
Top-Processes 영역에서는 현재 CPU와 메모리를 많이 사용하는 프로세스를 확인할 수 있음

아래와 같이 Mode=3으로 표시되는 경우 CPU, 메모리, I/O 관련 정보를 함께 보여주는 성능 모드임
Top-Processes-(1127) ----Mode=3 [1=Basic 2=CPU 3=Perf 4=Size 5=I/O 6=Cmds]
프로세스의 전체 실행 명령어를 확인하려면 6 키를 누르면 되고 다시 CPU 중심 화면으로 돌아가려면 2 또는 3 키를 누르면 됨

1
2
3
4
5
6
7
8
9

(6 입력)
  Top-Processes-(1128) ----Mode=6  [1=Basic 2=CPU 3=Perf 4=Size 5=I/O 6=Cmds]---------------------------------------------------------------------------------------
 Procs    %usr      %sys     Res      Res      Char Paging Command
 Total=137                Text-KB  Data-KB   I/O-KB
    96    9.4571 2373.2297       0   43008        0      0 wait
     2    5.8057    0.5188  392424  164596        0    840 orarootagent.bin
   369    5.4957    0.8017 97859456 5999972       56      1 oracle
     1    0.5631    1.3007       8  141396     1135      1 osysmond.bin
 -------------------------------------------------------------------------------------------------------------------------------------------------------------------

참고1. 참고로 nmon에서 현재 표시 중인 항목을 제거하려면 해당 항목의 단축키를 다시 누르면 됨
CPU 화면 제거 : c 또는 C
메모리 화면 제거 : m
Top Process 화면 제거 : t

참고2. 본문에서 사용하지 않은 nmon 단축키 결과
대표적인 nmon 단축키
P : Paging Space 사용 현황을 표시함
d : 디스크별 사용률과 처리량을 표시함
D : 디스크의 상세 I/O 정보를 표시함
n : 네트워크 인터페이스별 송수신량을 표시함
p : LPAR, Entitled Capacity, Physical CPU 등의 정보를 표시함
j : 파일시스템 사용률을 표시함
r : 서버명, AIX 버전, CPU, 메모리 등의 시스템 정보를 표시함
q : nmon을 종료함

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110

(P 입력)
┌─topas_nmon──h=Help─────────────Host=aixdb01────────Refresh=2 secs───17:32.48──────────────────────────────────────────────────────────────────────────────────────┐
│ Paging-Space ─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────│
│    Volume-Group PagingSpace-Name Type LPs  MB    Used IOpending                                                                                                   │
│          rootvg              hd6  LV   39 19968   1%    0    Active    Auto                                                                                       │
│───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────│
│                                                                                                                                                                   │
 
(d 입력)
┌─topas_nmon──r=Resources────────Host=aixdb01────────Refresh=2 secs───17:33.19──────────────────────────────────────────────────────────────────────────────────────┐
│ Disk-KBytes/second-(K=1024,M=1024*1024) ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────│
│Disk     Busy  Read  Write 0----------25-----------50------------75--------100                                                                                     │
│ Name          KB/s   KB/s |           |            |             |          |                                                                                     │
│cd0        0%      0      0|                                                 |                                                                                     │
│hdisk4     0%      1      0|                                                 |                                                                                     │
│hdisk3     0%    136      8|                                                 |                                                                                     │
│hdisk7     0%      0      2|                                                 |                                                                                     │
│hdisk6     0%      1      0|                                                 |                                                                                     │
│hdisk5     0%      1      0|                                                 |                                                                                     │
│hdisk2     0%      0      8|                                                 |                                                                                     │
│hdisk1    10%      0    562|WWWWWW                                           |                                                                                     │
│hdisk0    13%      0    626|WWWWWWW                                          |                                                                                     │
│Totals           139   1207+-----------|------------|-------------|----------+                                                                                     │
│───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────│
 
(D 입력)
┌─topas_nmon──S=WLMsubclasses────Host=aixdb01────────Refresh=2 secs───17:33.29──────────────────────────────────────────────────────────────────────────────────────┐
│ Disk-KBytes/second-(K=1024,M=1024*1024) ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────│
│Disk     Busy    Read    Write Transfers   Size  Peak%   Peak KB/s qDepth                                                                                          │
│ Name            KB/s    KB/s      /sec   KB           Read+Write or N/A                                                                                           │
│cd0        0%     0.0     0.0       0.0    0.0      0%       0.0       --                                                                                          │
│hdisk4     0%     1.0     0.5       3.0    0.5      1%       4.5       --                                                                                          │
│hdisk3     0%     0.0     0.0       0.0    0.0      1%     352.0       --                                                                                          │
│hdisk7     0%     0.0     0.0       0.0    0.0      0%       4.0       --                                                                                          │
│hdisk6     0%     1.0     0.5       3.0    0.5      0%       4.5       --                                                                                          │
│hdisk5     0%     1.0     0.5       3.0    0.5      0%       4.5       --                                                                                          │
│hdisk2     0%     4.0     0.0       1.0    4.0      3%    1427.9       --                                                                                          │
│hdisk1     4%     0.0    48.0      12.0    4.0     35%     562.0       --                                                                                          │
│hdisk0     8%     0.0    48.0      12.0    4.0     33%     626.0       --                                                                                          │
│Totals(MB/s) Read=0.0   Write=0.1   Size(GB)=0     Free(GB)=0                                                                                                      │
│───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────│
 
(n 입력)
┌─topas_nmon──2=Top-Child-CPU────Host=aixdb01────────Refresh=2 secs───17:33.43──────────────────────────────────────────────────────────────────────────────────────┐
│ Network ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────│
│I/F Name Recv=KB/s Trans=KB/s packin packout insize outsize Peak->Recv TransKB                                                                                     │
│    en0       0.4       1.3      7.0     11.5   52.6  114.2        0.5     1.4                                                                                     │
│    en3    1226.6    1047.2    896.0    772.0 1401.8 1389.1     1226.6  1047.2                                                                                     │
│    lo0       1.6       1.6     13.5     13.5  123.1  123.1        1.6     1.6                                                                                     │
│  Total       1.2       1.0 in Mbytes/second   Overflow=0                                                                                                          │
│I/F Name  MTU  ierror oerror collision Mbits/s Description                                                                                                         │
│    en0   1500      0      0      0   1024 Standard Ethernet Network Interface                                                                                     │
│    en3   1500      0      0      0   1024 Standard Ethernet Network Interface                                                                                     │
│    lo0  16896      0      0      0      0 Loopback Network Interface                                                                                              │
 
(p 입력)
┌─topas_nmon──r=Resources────────Host=aixdb01────────Refresh=2 secs───17:34.24──────────────────────────────────────────────────────────────────────────────────────┐
│ Dedicated-CPU-Logical-Partition ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────│
│Partition:Number=1 "68-7538X"                                                                                                                                      │
│Flags:LPARed DRable SMT Dedicated Sharable Migratable Not-Donating.                                                                                                │
│Summary: Entitled=24.00  Used    23.98 ( 99.9%) 99.9% of CPUs in System                                                                                            │
│                                                                                                                                                                   │
│CPU-Stats---------   Capacity----------------  ID-Memory--------------------                                                                                       │
│max Phys in sys  24  Cap. Processor Min  1.00  SPLPAR Group:Pool  32769:65535                                                                                      │
│Phys CPU in sys  24  Cap. Processor Max 24.00  Memory(MB) Min:Max  256:32768                                                                                       │
│Virtual Online   24  Cap. Increment      1.00  Memory(MB) Online   29952                                                                                           │
│Logical Online   96  Cap. Unallocated    0.00  Memory Region LMB   128MB min                                                                                       │
│Physical pool     0  Cap. Entitled      24.00  Time------------------Seconds                                                                                       │
│SMT threads/CPU   4   -MinReqVirtualCPU  1.00  Time Dispatch Wheel    0.0000                                                                                       │
│CPU---------Min-Max  Weight------------------  MaxDispatch Latency    0.0000                                                                                       │
│Virtual       1  24  Weight Variable        0  Time Pool Idle         0.0000                                                                                       │
│Logical       1 192  Weight Unallocated     0  Time Total Dispatch   23.9803                                                                                       │
│---------------------------------------------------------------------------                                                                                        │
│Event= 0 ---    ---     SerialNo Old=---    Current=FB7538 When=---                                                                                                │
│---------------------------------------------------------------------------                                                                                        │
│Shared_Pools   MaxPoolCapacity= 0.00     No Shared CPU Pool Authority                                                                                              │
│SharedCPU=0    EntPoolCapacity= 0.00     No Shared CPU Pool Authority                                                                                              │
│───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────│
 
(j 입력)
┌─topas_nmon──h=Help─────────────Host=aixdb01────────Refresh=2 secs───17:34.45──────────────────────────────────────────────────────────────────────────────────────┐
│ File-System ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────│
│Filesystem (    11)  Size MB     Free MB  %Used %Inodes   MountPoint                                                                                               │
│/dev/hd4          102400.0     45538.7  55.5%   0.6% /                                                                                                             │
│/dev/hd1             512.0       185.8  63.7%   2.0% /home                                                                                                         │
│/dev/hd2           20480.0     11710.3  42.8%   5.9% /usr                                                                                                          │
│/dev/hd9var         5120.0      4984.4   2.6%   0.1% /var                                                                                                          │
│/dev/hd3           10240.0      9378.6   8.4%   0.1% /tmp                                                                                                          │
│/dev/LV_oraDB     204288.0     76876.9  62.4%   0.9% /u01                                                                                                          │
│/dev/hd11admin       512.0       511.6   0.1%   0.0% /admin                                                                                                        │
│/proc                  0.0         0.0 100.0% 100.0% /proc                                                                                                         │
│/dev/hd10opt       10240.0      8172.4  20.2%   1.1% /opt                                                                                                          │
│/dev/fwdump         1536.0      1535.4   0.0%   0.0% /var/adm/ras/platform                                                                                         │
│/dev/livedump        512.0       511.6   0.1%   0.0% /var/adm/ras/livedump                                                                                         │
│───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────│
 
(r 입력)
┌─topas_nmon──p=Partitions───────Host=aixdb01────────Refresh=2 secs───17:35.13──────────────────────────────────────────────────────────────────────────────────────┐
│ Resources ────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────│
│OS has 96 PowerPC_POWER8 (64 bit) CPUs with 96 CPUs active SMT=4                                                                                                   │
│CPU Speed 3525.0 MHz         SerialNumber=687538X MachineType=IBM,8286-42A                                                                                         │
│Logical partition=Dynamic    HMC-LPAR-Number&Name=1,68-7538X                                                                                                       │
│AIX Version=7.2.5.105 TL05 Kernel=64 bit Multi-Processor                                                                                                           │
│Power Saving=Disabled             CPU-Current-Speed 3525.0 MHz                                                                                                     │
│Hardware-Type(NIM)=CHRP=Common H/W Reference Platform Bus-Type=PCI                                                                                                 │
│CPU Architecture  =PowerPC Implementation=POWER8 SubProcessor Mode=Unknown                                                                                         │
│CPU Level 1 Cache is Combined Instruction=32768 bytes & Data=65536 bytes                                                                                           │
│    Level 2 Cache size=524288          Node=aixdb01                                                                                                                │
│Event= 0 ---    ---     SerialNo Old=---    Current=FB7538 When=---                                                                                                │
│───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────│

결론 :
AIX에서 간단한 시스템 상태를 확인할 때는 topas 명령어를 사용할 수 있지만 여러 자원 정보를 원하는 형태로 구성하여 확인하려면 nmon 명령어가 더 유용함
특히 CPU 사용률 그래프와 메모리 상태를 확인하면서 CPU 사용률이 높은 프로세스를 한 화면에서 함께 확인할 수 있어 시스템 부하나 성능 문제를 분석할 때 편리함
nmon -B -s 2 명령어를 실행한 뒤 C, m, t 키를 조합하면 CPU, 메모리, Top Process 정보를 실시간으로 한 화면에서 확인할 수 있음
필요한 항목만 선택하여 표시할 수 있고 화면 갱신 주기도 조정할 수 있어 AIX 시스템 모니터링 시 유용하게 활용할 수 있음

참조 :

https://www.ibm.com/docs/ko/aix/7.2.0?topic=n-nmon-command
https://blog.innern.net/106

ORA-12162: TNS:net service name is incorrectly specified

내맘대로긍정 — Sat, 25 Jul 2026 14:27:01 +0900

OS 환경 : Oracle Linux 8.7 (64bit)

DB 환경 : Oracle Database 19.27.0.0

에러 : ORA-12162: TNS:net service name is incorrectly specified

sqlplus / as sysdba 접속시 발생하는 에러

1
2
3
4
5
6
7
8
9
10
11
12

$ sqlplus / as sysdba
 
SQL*Plus: Release 19.0.0.0.0 - Production on Sun May 17 13:35:09 2026
Version 19.27.0.0.0
 
Copyright (c) 1982, 2024, Oracle.  All rights reserved.
 
ERROR:
ORA-12162: TNS:net service name is incorrectly specified
 
 
Enter user-name: ^C

해결 방법 : ORACLE_SID 환경 변수 설정

현재 실행중인 오라클 smon 프로세스 확인

1
2
3
4

$ ps -ef | grep smon
oracle   2610578       1  0 May16 ?        00:00:01 ora_smon_ORA19DBFS
oracle   3203504 3202653  0 13:35 pts/0    00:00:00 grep --color=auto smon
root     3549577       1  0 May11 ?        00:37:02 /opt/oracle.ahf/shm/ahf-sysmon/bin/ahf-sysmon

ora_smon_ORA19DBFS으로 되어 있음

현재 ORACLE_SID 환경 설정 확인

1
2

$ env | grep ORACLE_SID
ORACLE_SID=

현재 ORACLE_SID가 공백으로 되어있음

ORACLE_SID를 ORA19DBFS로 설정 후 sqlplus 재접속

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

$ export ORACLE_SID=ORA19DBFS
$ sqlplus / as sysdba
 
SQL*Plus: Release 19.0.0.0.0 - Production on Sun May 17 13:36:24 2026
Version 19.27.0.0.0
 
Copyright (c) 1982, 2024, Oracle.  All rights reserved.
 
 
Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.27.0.0.0
 
SQL> select instance_name, version, status from v$instance;
 
INSTANCE_NAME    VERSION           STATUS
---------------- ----------------- ------------
ORA19DBFS        19.0.0.0.0        OPEN

정상적으로 접속됨

추후에도 정상적인 접속을 위해 .bash_profile에도 ORACLE_SID 설정 및 저장

1
2
3

$ cd /home/oracle
$ vi .bash_profile
export ORACLE_SID=ORA19DBFS

저장

1

$ . ./.bash_profile

재확인

1
2

$ env | grep ORACLE_SID
ORACLE_SID=ORA19DBFS

정상적으로 등록됨

원인 : OS 환경변수(ORACLE_SID)가 제대로 설정되어 있지 않아 발생한 문제

OS 환경변수(ORACLE_SID)가 제대로 설정되어 있지 않아 발생한 문제
ORACLE_SID를 설정하여 해결

참조 :

처음 만나는 오라클 AI 데이터베이스 실습 스크립트

내맘대로긍정 — Tue, 21 Jul 2026 14:16:07 +0900

안녕하세요. 『처음 만나는 오라클 AI 데이터베이스』 저자 박영민입니다.

책에 수록된 실습 스크립트를 업로드 드립니다.

실습 스크립트를 별도로 제공하지만, 마지막 Chapter 8을 제외한 대부분의 내용은 책을 보면서 직접 입력하고 실행해 보시는 것을 추천드립니다. 실습 과정을 하나씩 따라가면 각 기능의 동작 방식과 실행 결과를 조금 더 쉽게 이해하실 수 있습니다.

Chapter 8은 구성에 필요한 스크립트가 길기 때문에 직접 입력하기보다 제공된 스크립트를 환경에 맞게 수정해 사용하시는 것을 추천드립니다.

제공해 드리는 스크립트가 책의 실습을 진행하는 데 도움이 되었으면 좋겠습니다.

감사합니다.

내맘대로긍정 박영민 드림

스크립트 다운로드 :

처음_만나는_오라클_AI_데이터베이스_스크립트_v1.0.zip

0.07MB

참고 :

처음 만나는 오라클 AI 데이터베이스 출간 안내

안녕하세요. 기술 블로그 내맘대로긍정을 운영하고 있는 박영민입니다. 이번에 제가 집필한 『처음 만나는 오라클 AI 데이터베이스 - 내맘대로긍정이 알려주는 26ai 신기능 가이드』가 출간되었

positivemh.tistory.com

『처음 만나는 오라클 AI 데이터베이스』 실습 스크립트 안내

안녕하세요. 『처음 만나는 오라클 AI 데이터베이스』 저자 박영민입니다. 책에 수록된 실습 스크립트를 업로드 드립니다. 실습 스크립트를 별도로 제공하지만, 마지막 Chapte...

cafe.naver.com

처음 만나는 오라클 AI 데이터베이스 출간 안내

내맘대로긍정 — Thu, 16 Jul 2026 18:00:40 +0900

안녕하세요. 기술 블로그 내맘대로긍정을 운영하고 있는 박영민입니다.

이번에 제가 집필한 『처음 만나는 오라클 AI 데이터베이스 - 내맘대로긍정이 알려주는 26ai 신기능 가이드』가 출간되었습니다.

그동안 블로그를 통해 오라클 데이터베이스의 새로운 기능과 직접 테스트한 내용을 꾸준히 정리해 왔습니다. 새로운 기능이 발표될 때마다 실제 환경에서 동작을 확인해 보고, 공식 문서만으로는 알기 어려운 부분이나 테스트 과정에서 발견한 주의사항을 기록해 왔는데, 이번에는 그 내용을 조금 더 체계적으로 정리해 한 권의 책으로 담게 되었습니다.

Oracle AI Database 26ai에는 간결해진 SQL 문법부터 멀티테넌트 운영 기능, 성능 진단과 최적화 기능, AI Vector Search, Select AI, SQLcl MCP와 Select AI Agent까지 다양한 변화가 포함되어 있습니다. 기능의 범위가 넓고 기존 버전과 달라진 부분도 많아, 처음 접했을 때 어디서부터 확인해야 할지 막막하게 느껴질 수 있습니다.

이 책에서는 기능을 단순히 소개하는 데 그치지 않고 기존 방식과 비교해 무엇이 달라졌는지, 실제로 어떻게 사용하는지, 테스트 과정에서 어떤 오류가 발생할 수 있는지, 실무에 적용할 때 무엇을 주의해야 하는지를 SQL과 실행 결과를 중심으로 정리했습니다.

책을 쓰는 과정에서도 모든 스크립트를 직접 실행해 보면서 내용을 확인했습니다. 모든 기능을 한 번에 완벽하게 이해하기보다는 책의 실습을 하나씩 따라 하면서 Oracle AI Database 26ai의 변화와 방향을 자연스럽게 익힐 수 있도록 구성했습니다.

블로그에 업로드 해온 글을 봐주신 분들과 함께 공부하고 의견을 나눠주신 분들 덕분에 여기까지 올 수 있었습니다. 평소 블로그를 찾아주셨던 분들께 감사드리고, 오라클 26ai의 새로운 기능을 살펴보려는 개발자와 DBA, 업그레이드와 마이그레이션을 준비하는 엔지니어분들께 이 책이 조금이나마 도움이 되었으면 합니다.

많은 관심 부탁드립니다.

내맘대로긍정 박영민 드림

서적 명 : 처음 만나는 오라클 AI 데이터베이스 - 내맘대로긍정이 알려주는 26ai 신기능 가이드

ISBN : 979-11-91941-14-2 (93000)

https://www.nl.go.kr/seoji/contents/S80100000000.do?schM=intgr_detail_view_isbn&page=1&pageUnit=10&schType=simple&schStr=%EC%98%A4%EB%9D%BC%ED%81%B4&isbn=9791191941142&cipId=230577039%2C#open

구매처 : 인터넷 온라인 서점 등

교보문고 : https://product.kyobobook.co.kr/detail/S000220647959

Yes24 : https://www.yes24.com/product/goods/194368478

알라딘 : https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=399068706

책소개

< 책 소개 >

오라클 데이터베이스는 다시 한 번 큰 전환점 앞에 서 있습니다.
오랫동안 익숙하게 사용해 온 19c 중심의 운영 방식과 개발 방식은 Oracle AI Database 26ai에 이르러 적지 않은 변화를 맞이했습니다. 멀티테넌트 아키텍처는 이제 선택이 아닌 기본 구조가 되었고, SQL 문법은 더 간결해졌습니다. 여기에 벡터 검색과 생성형 AI 연동까지 더해지면서 데이터베이스의 역할도 단순한 저장소를 넘어 새로운 방향으로 확장되고 있습니다.
이 책은 Oracle AI Database 26ai의 신기능을 단순히 소개하는 데서 그치지 않습니다. 기존 방식에서는 무엇이 불편했는지, 26ai에서는 그 문제가 어떻게 개선되었는지, 실제 업무에 적용할 때 어떤 점을 조심해야 하는지를 실습 흐름에 맞춰 차근차근 설명합니다. 저자가 직접 테스트한 SQL과 실행 결과를 바탕으로 구성했기 때문에 문서만 읽었을 때 놓치기 쉬운 차이도 함께 확인할 수 있습니다.
새로운 SQL 문법, 멀티테넌트 운영 기능, 성능 진단과 최적화 기능, AI Vector Search와 Select AI 같은 AI 기능까지 폭넓게 다루지만, 단순히 기능을 나열하는 방식은 지양했습니다. 각 장은 기능의 필요성을 먼저 짚고, 실습을 통해 동작을 확인한 뒤, 내부 동작과 주의사항을 정리하는 흐름으로 구성되어 있습니다. 독자는 책의 순서를 따라가며 26ai의 변화를 자연스럽게 이해할 수 있습니다.
오라클의 신기능은 설명만 읽어서는 실무 감각이 잘 잡히지 않습니다. 직접 실행해 보고, 에러를 만나 보고, 실행 계획과 데이터 딕셔너리를 확인해야 실제 환경에서 어떻게 써야 할지 판단할 수 있습니다. 이 책은 그 과정을 실무자의 시선으로 정리한 Oracle AI Database 26ai 실습형 안내서입니다.
오라클 26ai를 처음 접하는 개발자와 DBA, 19c 이후의 업그레이드와 마이그레이션을 준비하는 엔지니어, 데이터베이스 안에서 AI 기능이 어떻게 구현되는지 궁금한 독자에게 이 책은 실무적인 기준을 잡는 데 도움이 될 것입니다. 새로운 문법을 익히는 것을 넘어, 달라진 오라클 데이터베이스의 방향을 실무 관점에서 이해할 수 있도록 돕습니다.

< 대상 독자 >

이 책은 오라클 데이터베이스를 운영하거나 이를 기반으로 애플리케이션을 개발하는 모든 분을 위해 쓰였습니다.

• 오라클 데이터베이스 입문자 및 주니어 개발자: 과거의 복잡하고 우회적인 레거시(Legacy) 문법이 아닌, 직관적이고 코드가 짧은 최신 표준 SQL을 통해 가장 현대적인 방식의 오라클 데이터베이스를 배울 수 있습니다.

• 데이터베이스 관리자(DBA) 및 아키텍트: 11g나 19c 환경에서 26ai로의 업그레이드 및 마이그레이션을 준비하거나, 새로운 자동화 및 메모리 관리 아키텍처를 시스템에 적용하려는 분들에게 실질적인 지침서가 됩니다.

• 백엔드 개발자 및 데이터 엔지니어: JSON, Boolean, Vector 데이터 등 새로운 데이터 타입을 활용해 애플리케이션의 비즈니스 로직을 단순화하고, AI 애플리케이션의 기반을 다지고 싶은 분들에게 적합합니다.

< 구성 >

이 책은 총 4개의 파트로 구성되어 있으며, 파트 1, 2는 초급, 파트 3, 4는 중급 정도의 난이도로 단계별 학습이 가능하게끔 배치했습니다. 각 장은 ‘기능 소개 → 실습 준비 → 실습 가이드 → 심화 분석 → 주의사항’의 흐름으로 전개됩니다.

• Part 1. 현대적 SQL 문법과 개발 편의성 개선: 복잡했던 기존 SQL 작성 방식을 직관적으로 바꿔주는 문법적 변화를 다룹니다. IF NOT EXISTS를 통한 에러 없는 DDL 실행, 서브쿼리 없는 조인(Join) 기반의 데이터 갱신, GROUP BY ALL 등 타이핑과 코드를 크게 줄여주는 기능들을 통해 개발 생산성을 높이는 방법을 배웁니다.

• Part 2. DBA를 위한 관리와 운영의 진화: 멀티테넌트 환경에서의 효율적인 인프라 관리를 다룹니다. PDB 기동 순서 제어, 런타임에 유연하게 공간을 확보하는 테이블스페이스 Shrink 기능을 비롯해, 실무에서 번거로웠던 스키마 레벨의 권한 부여 및 관리 방식을 어떻게 간소화할 수 있는지 상세히 살펴봅니다.

• Part 3. 고성능 DB를 위한 진단과 최적화: 눈에 보이지 않던 성능 이슈를 시각화하고 동시성 처리를 극대화하는 방법을 알아봅니다. 복잡한 힌트 분석을 자동화하는 Xplan의 새로운 기능들과 더불어, 외부 Redis 캐시를 대체하여 초고속 인메모리 읽기를 지원하는 Oracle True Cache의 구성 및 활용법을 다룹니다.

• Part 4. Oracle AI Vector Search와 차세대 아키텍처: 생성형 AI 시대에 발맞춘 데이터베이스의 변화를 다룹니다. 신규 벡터 데이터 타입과 초고속 HNSW 인덱스 구성법을 먼저 알아보고, Select AI를 통해 자연어로 SQL 쿼리를 자동 생성하는 방법을 실습합니다. 나아가 차세대 접속 도구인 SQLcl의 MCP(Model Context Protocol)를 활용해 LLM과 데이터베이스를 직접 연결하는 통합 환경까지 구축해 봅니다.

< 출판사 서평 >

오라클 에이스 프로(Oracle ACE Pro)가 직접 테스트하고 검증한 Oracle AI Database 26ai 실습형 안내서

생성형 AI 시대, 오라클 데이터베이스는 어디로 가고 있는가

Oracle AI Database 26ai는 단순한 버전 업그레이드가 아닙니다. 멀티테넌트 아키텍처의 기본화, 더 간결해진 SQL 문법, AI Vector Search와 Select AI의 도입은 오라클 데이터베이스의 사용 방식을 새롭게 바꾸고 있습니다.

이 책은 이러한 변화를 실무자의 눈높이에서 정리한 Oracle AI Database 26ai 실습서입니다. 신기능을 단순히 나열하는 대신, 기존 방식에서 무엇이 불편했는지, 26ai에서는 어떻게 개선되었는지, 실제 업무에 적용할 때 어떤 점을 주의해야 하는지를 SQL과 실행 결과를 바탕으로 설명합니다.

새로운 버전의 기능은 문서만 읽어서는 감이 잘 잡히지 않습니다. 직접 실행해 보고, 실행 결과를 확인하고, 에러와 주의사항까지 살펴봐야 실무에서 사용할 수 있는 지식이 됩니다. 이 책은 그 과정을 따라갈 수 있도록 기능 소개, 실습 준비, 실습 가이드, 심화 분석, 주의사항의 흐름으로 구성했습니다.

오라클 26ai를 처음 접하는 개발자와 DBA, 19c 이후의 업그레이드와 마이그레이션을 준비하는 엔지니어, 데이터베이스와 생성형 AI의 연결 방식을 이해하고 싶은 실무자에게 이 책은 달라진 오라클 데이터베이스의 방향을 보여주는 실질적인 안내서가 될 것입니다.

실습 스크립트

처음 만나는 오라클 AI 데이터베이스 실습 스크립트 ( https://positivemh.tistory.com/1422 )

오라클 26ai autoupgrade시 block checking 이벤트로 인한 hang 현상

내맘대로긍정 — Thu, 16 Jul 2026 08:09:19 +0900

OS 환경 : Oracle Linux 9.6 (64bit)

DB 환경 : Oracle AI Database 23.26.2.0.0 ai, 19.31

방법 : 오라클 26ai autoupgrade시 block checking 이벤트로 인한 hang 현상

26ai 업그레이드 시 Block Checking 관련 문제가 발생한다고함(~23.26.2)
이 문제는 AutoUpgrade를 사용하여 업그레이드할 때 발생할 수 있는 문제로
23ai부터 Index Block의 최대 INITRANS 값이 255에서 169로 변경되었는데 업그레이드 과정 중 Block Checking 단계에서 기존 최대값을 가진 블록을 검사할 경우 업그레이드 시 Hang이 발생할 수 있다고 함

이 문제의 조치 방안은 아래와 같음
- Bug 38946554 패치 적용
- Oracle AI Database 26ai RU 23.26.3 이상 적용(곧출시)
- 아래 파라미터를 이용한 임시 우회
- db_block_checking=FALSE
- "_db_always_check_system_ts"=FALSE
- 문제가 발생한 인덱스 Rebuild

참고용 공식문서 :
MAXTRANS 매개변수
이전 버전에서는 해당 MAXTRANS매개변수가 세그먼트 내 각 데이터 블록에 허용되는 최대 동시 업데이트 트랜잭션 수를 결정했습니다.
이 매개변수는 더 이상 사용되지 않습니다. 이제 Oracle은 블록의 사용 가능한 공간에 따라 모든 데이터 블록에 대해 최대 255개의 동시 업데이트 트랜잭션을 자동으로 허용합니다.
최대 동시 업데이트 트랜잭션 수는 블록 크기에 따라 결정됩니다.
이미 값이 MAXTRANS설정된 기존 객체는 해당 설정을 유지합니다. 그러나 MAXTRANS 값을 변경하려고 하면 Oracle은 새 값을 무시하고 오류를 반환하지 않고 255라는 값으로 대체합니다.
참고 : https://docs.oracle.com/en/database/oracle/oracle-database/26/sqlrf/physical_attributes_clause.html

실제 확인 테스트(19c, 26ai)
샘플 테이블 및 인덱스 생성

1
2
3
4
5
6
7

SQL> create table t1 (col1 number);
 
Table created.
 
SQL> create index t1_ix1 on t1(col1) initrans 255;
 
Index created.

인덱스의 initrans 값 확인

1
2
3
4
5
6
7
8
9

SQL> 
set lines 200 pages 1000
col index_name for a10
select index_name, ini_trans from dba_indexes
where index_name = 'T1_IX1';
 
INDEX_NAME  INI_TRANS
---------- ----------
T1_IX1            255

19c, 26ai 모두 initrans 값이 255로 잘 설정되어 있음
하지만 MOS 노트처럼 실제로는 내부적으로 169라는 값이 사용되는듯함

실제 업그레이드 하여 확인
참고 : 오라클 19c to 26ai AutoUpgrade Refreshable Pluggable Database 이용 업그레이드 ( https://positivemh.tistory.com/1336 )
19c에서 먼저 샘플 테이블, 인덱스 생성 후 데이터 삽입

1
2
3
4
5

SQL> 
create table t1 (col1 number);
create index t1_ix1 on t1(col1) initrans 255;
insert into t1 select object_id from dba_objects;
commit;

autoupgrade 수행

1
2

$ java -jar autoupgrade.jar -config ORA19DBFS.cfg -mode deploy
(동작)

테스트 환경에서는 인덱스가 하나여서 그런지 업그레이드가 잘 수행되었음
아마 운영 환경처럼 데이터가 많은경우 문제가 발생하는듯 함

참조 :

Autoupgrade :Database upgrade to 26ai hung with block checking events(KB914929)
38946554 - HANG ON BLOCKCHECK DUE OVERFLOW ON MAX ITL COUNT
https://mikedietrichde.com/2026/07/15/upgrade-to-26ai-may-hang-due-to-block-checking-events/
https://docs.oracle.com/en/database/oracle/oracle-database/26/sqlrf/physical_attributes_clause.html

오라클 19c CLOB 컬럼 STORAGE IN ROW 옵션별 저장 위치 확인 테스트

내맘대로긍정 — Sun, 5 Jul 2026 21:17:31 +0900

OS 환경 : Oracle Linux 9.6 (64bit)

DB 환경 : Oracle Database 19.31.0.0

방법 : 오라클 19c CLOB 컬럼 STORAGE IN ROW 옵션별 저장 위치 확인 테스트

이전 게시글에서는 CLOB 컬럼 STORAGE IN ROW 옵션별 용량을 확인해보였음

참고 : 오라클 11gR2 CLOB 컬럼 STORAGE IN ROW 옵션별 용량 확인 테스트 ( https://positivemh.tistory.com/1418 )

본문에서는 CLOB 컬럼 STORAGE IN ROW 옵션별 저장 위치를 확인해봄

일반적으로 CLOB 컬럼에 들어가는 데이터가 4000byte가 넘어가면 LOB 세그먼트에 들어가는것으로 알고 있음
참고: https://docs.oracle.com/en/database/oracle/oracle-database/19/adlob/LOB-storage-with-applications.html#GUID-D3BD47D3-DD6A-4DC9-9BAF-5DBB60918087
하지만 이 기준은 BasicFile과 SecureFile 별로 조금 다름
BASICFILE의 경우 1982byte 보다 큰 1983byte 이상인 길이의 문자를 CLOB 컬럼에 삽입하게 되면 LOB 세그먼트에 별도로 저장됨(Out-of-line에 저장)
SECUREFILE의 경우 1984byte 보다 큰 1985byte 이상인 길이의 문자를 CLOB 컬럼에 삽입하게 되면 LOB 세그먼트에 별도로 저장됨(Out-of-line에 저장)
참고 : CLOB Is Stored Out-of-line When Insert CLOB Data Greater Than 1982 Bytes(KB139645)
본문에서는 CLOB 컬럼을 만들고 RPAD 함수를 이용해 데이터를 각각 1982byte, 1983byte, 1985byte(SECUREFILE) 삽입해보고 블록 덤프를 확인해서 실제로 어디에 저장되는지 확인해봄
BASICFILE과 SECUREFILE을 각각 나눠서 확인해봄

(참고로 11gR2까지는 BASICFILE, SECUREFILE 모두 1982byte까지 테이블 row에 저장되고 12c 이상부터는 SECUREFILE은 1984byte까지 테이블 row에 저장됨, 참고 : https://hrjeong.tistory.com/294)

테스트
1. BASICFILE + 1982byte 데이터
2. SECUREFILE + 1982byte 데이터
3. BASICFILE + 1983byte 데이터
4. SECUREFILE + 1985byte 데이터

테스트
1. BASICFILE + 1982byte 데이터
샘플 테이블 생성

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

SQL>
DROP TABLE basic_1982 PURGE;
 
CREATE TABLE basic_1982
(
    id        NUMBER,
    c_data    CLOB,
    ins_date  DATE DEFAULT SYSDATE
)
TABLESPACE USERS
LOB (c_data) STORE AS BASICFILE basic_1982_lob
(
    TABLESPACE USERS
    CHUNK 8192
    PCTVERSION 10
    NOCACHE
    LOGGING
);

dba_lobs로 정보 조회

1
2
3
4
5
6
7
8
9
10
11
12
13
14

SQL>
set lines 200 pages 1000
col table_name for a15
col column_name for a10
col segment_name for a20
col index_name for a25
col securefile for a5
SELECT table_name, column_name, segment_name, index_name, securefile, chunk, in_row, pctversion, retention, cache, logging
FROM   dba_lobs
WHERE  table_name = 'BASIC_1982';
 
TABLE_NAME      COLUMN_NAM SEGMENT_NAME         INDEX_NAME                SECUR      CHUNK IN_ PCTVERSION  RETENTION CACHE      LOGGING
--------------- ---------- -------------------- ------------------------- ----- ---------- --- ---------- ---------- ---------- -------
BASIC_1982      C_DATA     BASIC_1982_LOB       SYS_IL0000059185C00002$$  NO          8192 YES         10            NO         YES

현재 SECUREFILE이 아니고 CHUNK 크기는 8192(8k)임, IN_ROW가 Yes임
ENABLE STORAGE IN ROW 상태에서 LOB 값과 control information을 합친 크기가 약 4000 bytes 이하이면 테이블 row 내부에 저장될 수 있음

샘플 데이터 삽입(문자열 1982byte 길이 삽입)

1
2
3
4
5
6
7
8
9
10
11
12
13

SQL>
INSERT INTO basic_1982 (id, c_data)
values (1, TO_CLOB(RPAD('A', 1982, 'A')));
 
1 row created.
 
SQL> commit;
 
Commit complete.
 
SQL> alter system checkpoint;
 
System altered.

1건 삽입됨

clob 컬럼 실제 길이 확인

1
2
3
4
5
6
7
8
9

SQL>
SELECT COUNT(*) AS row_cnt,
       MAX(DBMS_LOB.GETLENGTH(c_data)) AS len,
       MAX(LENGTHB(DBMS_LOB.SUBSTR(c_data, 4000, 1))) AS lenb
FROM   basic_1982;
 
   ROW_CNT        LEN       LENB
---------- ---------- ----------
         1       1982       1982

1982byte CLOB임

논리 용량 vs CHUNK 기준 예상 용량

1
2
3
4
5
6
7
8
9
10

SQL>
SELECT COUNT(*) AS row_cnt,
       ROUND(SUM(DBMS_LOB.GETLENGTH(c_data)) / 1024, 2) AS logical_kb,
       ROUND(SUM(CEIL(DBMS_LOB.GETLENGTH(c_data) / 8192) * 8192)
             / 1024, 2) AS chunk_est_kb
FROM   basic_1982;
 
   ROW_CNT LOGICAL_KB CHUNK_EST_KB
---------- ---------- ------------
         1       1.94            8

1개 row의 논리 용량은 1.94kb, CHUNK 기준 예상 용량은 8kb임

실제 세그먼트 용량 확인

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

SQL>
col segment_name for a30
WITH lob_info AS
(
    SELECT segment_name,
           index_name
    FROM   user_lobs
    WHERE  table_name = 'BASIC_1982'
)
SELECT s.segment_name,
       s.segment_type,
       ROUND(s.bytes / 1024, 2) AS kb
FROM   dba_segments s
WHERE  s.segment_name = 'BASIC_1982'
OR     s.segment_name IN (SELECT segment_name FROM lob_info)
OR     s.segment_name IN (SELECT index_name FROM lob_info)
ORDER BY s.bytes DESC;
 
SEGMENT_NAME                   SEGMENT_TYPE               KB
------------------------------ ------------------ ----------
BASIC_1982                     TABLE                      64
BASIC_1982_LOB                 LOBSEGMENT                 64
SYS_IL0000059185C00002$$       LOBINDEX                   64

LOB 세그먼트와 일반 세그먼트가 둘다 64kb여서 어디에 저장되었는지 아직 알수 없음

익스텐트 확인

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

SQL>
col segment_name for a25
SELECT segment_name,
       file_id,
       block_id,
       blocks
FROM dba_extents
WHERE segment_name in('BASIC_1982','BASIC_1982_LOB','SYS_IL0000059185C00002$$')
ORDER BY extent_id;
 
SEGMENT_NAME                 FILE_ID   BLOCK_ID     BLOCKS
------------------------- ---------- ---------- ----------
BASIC_1982                         4     759224          8
SYS_IL0000059185C00002$$           4     814928          8
BASIC_1982_LOB                     4     814920          8

각각 블록을 8개씩 할당 받아서 8 block * 8 kb(기본블록크기) => 64kb가 된것임

테스트 row의 물리 위치 확인

1
2
3
4
5
6
7
8
9
10

SQL>
select rowid,
       DBMS_ROWID.ROWID_TO_ABSOLUTE_FNO(rowid, USER, 'BASIC_1982') AS file#,
       DBMS_ROWID.ROWID_BLOCK_NUMBER(rowid) AS block#,
       DBMS_ROWID.ROWID_ROW_NUMBER(rowid) AS row#
from basic_1982;
 
ROWID                   FILE#     BLOCK#       ROW#
------------------ ---------- ---------- ----------
AAAOcxAAEAAC5W9AAA          4     759229          0

4번 파일에 759229번째 블록에 있음

해당 블록 덤프

1
2
3
4
5
6
7
8
9

SQL>
alter session set tracefile_identifier = 'basic_1982_block_dump';
 
Session altered.
 
예시) alter system dump datafile <file#> block <block#>;
alter system dump datafile 4 block 759229;
 
System altered.

덤프 경로 확인

1
2
3
4
5
6
7
8

SQL>
select value
from v$diag_info
where name = 'Default Trace File';
 
VALUE
---------------------------------------------------------------------------------
/app/oracle/diag/rdbms/ora19dbfs/ORA19DBFS/trace/ORA19DBFS_ora_457439_basic_1982_block_dump.trc

덤프 확인

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

$ vi /app/oracle/diag/rdbms/ora19dbfs/ORA19DBFS/trace/ORA19DBFS_ora_457439_basic_1982_block_dump.trc
...
data_block_dump,data header at 0xbf6a0064
===============
tsiz: 0x1f98
hsiz: 0x14
pbl: 0xbf6a0064
     76543210
flag=--------
ntab=1
nrow=1
frre=-1
fsbo=0x14
fseo=0xfe7
avsp=0xfd3
tosp=0xfd3
0xe:pti[0]      nrow=1  offs=0
0x12:pri[0]     offs=0xfe7
block_row_dump:
tab 0, row 0, @0xfe7
tl: 4017 fb: --H-FL-- lb: 0x1  cc: 3
col  0: [ 2]  c1 02
col  1: [4000]
 00 70 00 01 02 0c 80 00 00 02 00 00 00 01 00 00 00 2f 1c 5b 0f 8c 09 00 00
 00 00 00 0f 7c 00 00 00 00 00 01 00 41 00 41 00 41 00 41 00 41 00 41 00 41
 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00
 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41
 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00
 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41
 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00
...

덤프에 00 41 00 41...이 반복되고 있음(0x41(A) 값이 반복 되고 있음)

테스트1 결론 :
실제 CLOB 문자 데이터 1982자
=> 내부 저장 시 00 41 형태로 약 2byte씩 저장됨
=> 1982 * 2 = 3964 byte

LOB control information 약 36 byte
=> 3964 + 36 = 4000 byte
col 1: [4000]의 00 41이 나오기 전까지의 앞 36개(36byte)
00 70 00 01 02 0c 80 00 00 02 00 00 00 01 00 00 00 2f 1c 5b 0f 8c 09 00 00 00 00 00 0f 7c 00 00 00 00 00 01

블록 덤프에서 테스트 row를 확인해보면 row 전체 길이(tl)는 4017 byte이고 CLOB 컬럼에 해당하는 col 1의 길이는 4000 byte로 표시됨
또한 col 1 내부에는 00 41 값이 반복적으로 저장되어 있는데 이는 삽입한 'A' 문자열이 테이블 row 내부에 실제로 저장되어 있음을 의미함
즉 1982byte 길이의 CLOB 데이터는 LOB 세그먼트에 저장되지 않고 테이블 row 내부에 저장된 것으로 확인됨

2. SECUREFILE + 1982byte 데이터
샘플 테이블 생성

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

SQL>
DROP TABLE secure_1982 PURGE;
 
CREATE TABLE secure_1982
(
    id        NUMBER,
    c_data    CLOB,
    ins_date  DATE DEFAULT SYSDATE
)
TABLESPACE USERS
LOB (c_data) STORE AS SECUREFILE secure_1982_lob
(
    TABLESPACE USERS
    CHUNK 8192
    PCTVERSION 10
    NOCACHE
    LOGGING
);

dba_lobs로 정보 조회

1
2
3
4
5
6
7
8
9
10
11
12
13
14

SQL>
set lines 200 pages 1000
col table_name for a15
col column_name for a10
col segment_name for a20
col index_name for a25
col securefile for a5
SELECT table_name, column_name, segment_name, index_name, securefile, chunk, in_row, pctversion, retention, cache, logging
FROM   dba_lobs
WHERE  table_name = 'SECURE_1982';
 
TABLE_NAME      COLUMN_NAM SEGMENT_NAME         INDEX_NAME                SECUR      CHUNK IN_ PCTVERSION  RETENTION CACHE      LOGGING
--------------- ---------- -------------------- ------------------------- ----- ---------- --- ---------- ---------- ---------- -------
SECURE_1982     C_DATA     SECURE_1982_LOB      SYS_IL0000059191C00002$$  YES         8192 YES                       NO         YES

현재 SECUREFILE이면서 CHUNK 크기는 8192(8k)임, IN_ROW가 Yes임
ENABLE STORAGE IN ROW 상태에서 LOB 값과 control information을 합친 크기가 약 4000 bytes 이하이면 테이블 row 내부에 저장될 수 있음

샘플 데이터 삽입(문자열 1982byte 길이 삽입)

1
2
3
4
5
6
7
8
9
10
11
12
13

SQL>
INSERT INTO secure_1982 (id, c_data)
values (1, TO_CLOB(RPAD('A', 1982, 'A')));
 
1 row created.
 
SQL> commit;
 
Commit complete.
 
SQL> alter system checkpoint;
 
System altered.

1건 삽입됨

clob 컬럼 실제 길이 확인

1
2
3
4
5
6
7
8
9

SQL>
SELECT COUNT(*) AS row_cnt,
       MAX(DBMS_LOB.GETLENGTH(c_data)) AS len,
       MAX(LENGTHB(DBMS_LOB.SUBSTR(c_data, 4000, 1))) AS lenb
FROM   secure_1982;
 
   ROW_CNT        LEN       LENB
---------- ---------- ----------
         1       1982       1982

1982byte CLOB임

논리 용량 vs CHUNK 기준 예상 용량

1
2
3
4
5
6
7
8
9
10

SQL>
SELECT COUNT(*) AS row_cnt,
       ROUND(SUM(DBMS_LOB.GETLENGTH(c_data)) / 1024, 2) AS logical_kb,
       ROUND(SUM(CEIL(DBMS_LOB.GETLENGTH(c_data) / 8192) * 8192)
             / 1024, 2) AS chunk_est_kb
FROM   secure_1982;
 
   ROW_CNT LOGICAL_KB CHUNK_EST_KB
---------- ---------- ------------
         1       1.94            8

1개 row의 논리 용량은 1.94kb, CHUNK 기준 예상 용량은 8kb임

실제 세그먼트 용량 확인

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

SQL>
col segment_name for a30
WITH lob_info AS
(
    SELECT segment_name,
           index_name
    FROM   user_lobs
    WHERE  table_name = 'SECURE_1982'
)
SELECT s.segment_name,
       s.segment_type,
       ROUND(s.bytes / 1024, 2) AS kb
FROM   dba_segments s
WHERE  s.segment_name = 'SECURE_1982'
OR     s.segment_name IN (SELECT segment_name FROM lob_info)
OR     s.segment_name IN (SELECT index_name FROM lob_info)
ORDER BY s.bytes DESC;
 
SEGMENT_NAME                   SEGMENT_TYPE               KB
------------------------------ ------------------ ----------
SECURE_1982_LOB                LOBSEGMENT                128
SECURE_1982                    TABLE                      64
SYS_IL0000059191C00002$$       LOBINDEX                   64

LOB 세그먼트는 128kb를 할당받았고 일반 세그먼트는 64kb를 할당받음

익스텐트 확인

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

SQL>
col segment_name for a25
SELECT segment_name,
       file_id,
       block_id,
       blocks
FROM dba_extents
WHERE segment_name in('SECURE_1982','SECURE_1982_LOB','SYS_IL0000059191C00002$$')
ORDER BY extent_id;
 
SEGMENT_NAME                 FILE_ID   BLOCK_ID     BLOCKS
------------------------- ---------- ---------- ----------
SECURE_1982                        4     814936          8
SYS_IL0000059191C00002$$           4     814960          8
SECURE_1982_LOB                    4     814944         16

SECURE_1982, SYS_IL0000059191C00002$$는 블록을 8개씩 할당 받아서 8 block * 8 kb(기본블록크기) => 64kb 이고
SECURE_1982_LOB는 블록을 16개 할당 받아서 16 block * 8 kb(기본블록크기) => 128kb가 된것임

테스트 row의 물리 위치 확인

1
2
3
4
5
6
7
8
9
10

SQL>
select rowid,
       DBMS_ROWID.ROWID_TO_ABSOLUTE_FNO(rowid, USER, 'SECURE_1982') AS file#,
       DBMS_ROWID.ROWID_BLOCK_NUMBER(rowid) AS block#,
       DBMS_ROWID.ROWID_ROW_NUMBER(rowid) AS row#
from secure_1982;
 
ROWID                   FILE#     BLOCK#       ROW#
------------------ ---------- ---------- ----------
AAAOc3AAEAADG9dAAA          4     814941          0

4번 파일에 814941번째 블록에 있음

해당 블록 덤프

1
2
3
4
5
6
7
8
9

SQL>
alter session set tracefile_identifier = 'secure_1982_block_dump';
 
Session altered.
 
예시) alter system dump datafile <file#> block <block#>;
alter system dump datafile 4 block 814941;
 
System altered.

덤프 경로 확인

1
2
3
4
5
6
7
8

SQL>
select value
from v$diag_info
where name = 'Default Trace File';
 
VALUE
---------------------------------------------------------------------------------
/app/oracle/diag/rdbms/ora19dbfs/ORA19DBFS/trace/ORA19DBFS_ora_496314_secure_1982_block_dump.trc

덤프 확인

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

$ vi /app/oracle/diag/rdbms/ora19dbfs/ORA19DBFS/trace/ORA19DBFS_ora_496314_secure_1982_block_dump.trc
...
data_block_dump,data header at 0xd4d66064
===============
tsiz: 0x1f98
hsiz: 0x14
pbl: 0xd4d66064
     76543210
flag=--------
ntab=1
nrow=1
frre=-1
fsbo=0x14
fseo=0xfec
avsp=0xfd8
tosp=0xfd8
0xe:pti[0]      nrow=1  offs=0
0x12:pri[0]     offs=0xfec
block_row_dump:
tab 0, row 0, @0xfec
tl: 4012 fb: --H-FL-- lb: 0x1  cc: 3
col  0: [ 2]  c1 02
col  1: [3995]
 00 70 00 01 02 0c 80 80 00 02 00 00 00 01 00 00 00 2f 1c f1 0f 87 48 90 0f
 81 01 00 0f 7c 01 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00
 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41
 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00
 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41
 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00
 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41
...

덤프에 00 41 00 41...이 반복되고 있음(0x41(A) 값이 반복 되고 있음)

테스트2 결론 :
실제 CLOB 문자 데이터 1982자
=> 내부 저장 시 00 41 형태로 약 2byte씩 저장
=> 1982 * 2 = 3964 byte

LOB control information 약 31 byte
=> 3964 + 31 = 3995 byte
col 1: [3995]의 00 41이 나오기 전까지의 앞 31개(31byte)
00 70 00 01 02 0c 80 80 00 02 00 00 00 01 00 00 00 2f 1c f1 0f 87 48 90 0f 81 01 00 0f 7c 01

SecureFile 방식으로 생성한 CLOB 컬럼에 1982byte 데이터를 삽입한 뒤 테이블 row 블록을 덤프해보면 row 전체 길이(tl)는 4012 byte이고 CLOB 컬럼에 해당하는 col 1의 길이는 3995 byte로 표시됨
또한 col 1 내부에는 00 41 값이 반복적으로 저장되어 있는데 이는 삽입한 'A' 문자열이 테이블 row 내부에 실제로 저장되어 있음을 의미함
따라서 SecureFile CLOB 역시 1982byte 데이터는 LOB 세그먼트가 아닌 테이블 row 내부에 저장된 것으로 확인됨

3. BASICFILE + 1983byte 데이터
샘플 테이블 생성

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

SQL>
DROP TABLE basic_1983 PURGE;
 
CREATE TABLE basic_1983
(
    id        NUMBER,
    c_data    CLOB,
    ins_date  DATE DEFAULT SYSDATE
)
TABLESPACE USERS
LOB (c_data) STORE AS BASICFILE basic_1983_lob
(
    TABLESPACE USERS
    CHUNK 8192
    PCTVERSION 10
    NOCACHE
    LOGGING
);

dba_lobs로 정보 조회

1
2
3
4
5
6
7
8
9
10
11
12
13
14

SQL>
set lines 200 pages 1000
col table_name for a15
col column_name for a10
col segment_name for a20
col index_name for a25
col securefile for a5
SELECT table_name, column_name, segment_name, index_name, securefile, chunk, in_row, pctversion, retention, cache, logging
FROM   dba_lobs
WHERE  table_name = 'BASIC_1983';
 
TABLE_NAME      COLUMN_NAM SEGMENT_NAME         INDEX_NAME                SECUR      CHUNK IN_ PCTVERSION  RETENTION CACHE      LOGGING
--------------- ---------- -------------------- ------------------------- ----- ---------- --- ---------- ---------- ---------- -------
BASIC_1983      C_DATA     BASIC_1983_LOB       SYS_IL0000059200C00002$$  NO          8192 YES         10            NO         YES

샘플 데이터 삽입(문자열 1983byte 길이 삽입)

1
2
3
4
5
6
7
8
9
10
11
12
13

SQL>
INSERT INTO basic_1983 (id, c_data)
values (1, TO_CLOB(RPAD('A', 1983, 'A')));
 
1 row created.
 
SQL> commit;
 
Commit complete.
 
SQL> alter system checkpoint;
 
System altered.

1건 삽입됨

clob 컬럼 실제 길이 확인

1
2
3
4
5
6
7
8
9

SQL>
SELECT COUNT(*) AS row_cnt,
       MAX(DBMS_LOB.GETLENGTH(c_data)) AS len,
       MAX(LENGTHB(DBMS_LOB.SUBSTR(c_data, 4000, 1))) AS lenb
FROM   basic_1983;
 
   ROW_CNT        LEN       LENB
---------- ---------- ----------
         1       1983       1983

1983byte CLOB임

논리 용량 vs CHUNK 기준 예상 용량

1
2
3
4
5
6
7
8
9
10

SQL>
SELECT COUNT(*) AS row_cnt,
       ROUND(SUM(DBMS_LOB.GETLENGTH(c_data)) / 1024, 2) AS logical_kb,
       ROUND(SUM(CEIL(DBMS_LOB.GETLENGTH(c_data) / 8192) * 8192)
             / 1024, 2) AS chunk_est_kb
FROM   basic_1983;
 
   ROW_CNT LOGICAL_KB CHUNK_EST_KB
---------- ---------- ------------
         1       1.94            8

1개 row의 논리 용량은 1.94kb, CHUNK 기준 예상 용량은 8kb임

실제 세그먼트 용량 확인

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

SQL>
col segment_name for a30
WITH lob_info AS
(
    SELECT segment_name,
           index_name
    FROM   user_lobs
    WHERE  table_name = 'BASIC_1983'
)
SELECT s.segment_name,
       s.segment_type,
       ROUND(s.bytes / 1024, 2) AS kb
FROM   dba_segments s
WHERE  s.segment_name = 'BASIC_1983'
OR     s.segment_name IN (SELECT segment_name FROM lob_info)
OR     s.segment_name IN (SELECT index_name FROM lob_info)
ORDER BY s.bytes DESC;
 
SEGMENT_NAME                   SEGMENT_TYPE               KB
------------------------------ ------------------ ----------
SYS_IL0000059200C00002$$       LOBINDEX                   64
BASIC_1983                     TABLE                      64
BASIC_1983_LOB                 LOBSEGMENT                 64

LOB 세그먼트와 일반 세그먼트가 둘다 64kb여서 어디에 저장되었는지 아직 알수 없음

익스텐트 확인

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

SQL>
col segment_name for a25
SELECT segment_name,
       file_id,
       block_id,
       blocks
FROM dba_extents
WHERE segment_name in('BASIC_1983','BASIC_1983_LOB','SYS_IL0000059200C00002$$')
ORDER BY extent_id;
 
SEGMENT_NAME                 FILE_ID   BLOCK_ID     BLOCKS
------------------------- ---------- ---------- ----------
BASIC_1983                         4     814968          8
SYS_IL0000059200C00002$$           4     815032          8
BASIC_1983_LOB                     4     815024          8

각각 블록을 8개씩 할당 받아서 8 block * 8 kb(기본블록크기) => 64kb가 된것임

테스트 row의 물리 위치 확인

1
2
3
4
5
6
7
8
9
10

SQL>
select rowid,
       DBMS_ROWID.ROWID_TO_ABSOLUTE_FNO(rowid, USER, 'BASIC_1983') AS file#,
       DBMS_ROWID.ROWID_BLOCK_NUMBER(rowid) AS block#,
       DBMS_ROWID.ROWID_ROW_NUMBER(rowid) AS row#
from basic_1983;
 
ROWID                   FILE#     BLOCK#       ROW#
------------------ ---------- ---------- ----------
AAAOdAAAEAADG99AAA          4     814973          0

4번 파일에 814973번째 블록에 있음

해당 블록 덤프

1
2
3
4
5
6
7
8
9

SQL>
alter session set tracefile_identifier = 'basic_1983_block_dump';
 
Session altered.
 
예시) alter system dump datafile <file#> block <block#>;
alter system dump datafile 4 block 814973;
 
System altered.

덤프 경로 확인

1
2
3
4
5
6
7
8

SQL>
select value
from v$diag_info
where name = 'Default Trace File';
 
VALUE
---------------------------------------------------------------------------------
/app/oracle/diag/rdbms/ora19dbfs/ORA19DBFS/trace/ORA19DBFS_ora_500143_basic_1983_block_dump.trc

덤프 확인

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

$ vi /app/oracle/diag/rdbms/ora19dbfs/ORA19DBFS/trace/ORA19DBFS_ora_500143_basic_1983_block_dump.trc
...
data_block_dump,data header at 0xd5b2a064
===============
tsiz: 0x1f98
hsiz: 0x14
pbl: 0xd5b2a064
     76543210
flag=--------
ntab=1
nrow=1
frre=-1
fsbo=0x14
fseo=0x1f61
avsp=0x1f4d
tosp=0x1f4d
0xe:pti[0]      nrow=1  offs=0
0x12:pri[0]     offs=0x1f61
block_row_dump:
tab 0, row 0, @0x1f61
tl: 55 fb: --H-FL-- lb: 0x1  cc: 3
col  0: [ 2]  c1 02
col  1: [40]
 00 70 00 01 02 0c 80 00 00 02 00 00 00 01 00 00 00 2f 1d 24 00 14 05 00 00
 00 00 00 0f 7e 00 00 00 00 00 02 01 0c 6f b5
col  2: [ 7]  78 7e 07 06 0e 0a 06
end_of_block_dump
...

이전 테스트와 달리 col1에 40byte만 존재함(lob locator만 존재하는것)(col 1: [40] 부분)

col 1: [40]의 끝부분에 01 0c 6f b5값이 존재함
0x010c6fb5로 해석하면 file# 4, block# 815029를 가리키고 있음
해당 값의 데이터파일과 블록번호 확인

1
2
3
4
5
6
7
8

SQL>
SELECT DBMS_UTILITY.DATA_BLOCK_ADDRESS_FILE(TO_NUMBER('010C6FB5', 'XXXXXXXX'))  AS file_no,
       DBMS_UTILITY.DATA_BLOCK_ADDRESS_BLOCK(TO_NUMBER('010C6FB5', 'XXXXXXXX')) AS block_no
FROM dual;
 
   FILE_NO   BLOCK_NO
---------- ----------
         4     815029

해당 블록 덤프

1
2
3
4
5
6
7
8
9

SQL>
alter session set tracefile_identifier = 'lob_block_dump1';
 
Session altered.
 
예시) alter system dump datafile <file#> block <block#>;
alter system dump datafile 4 block 815029;
 
System altered.

덤프 경로 확인

1
2
3
4
5
6
7
8

SQL>
select value
from v$diag_info
where name = 'Default Trace File';
 
VALUE
---------------------------------------------------------------------------------
/app/oracle/diag/rdbms/ora19dbfs/ORA19DBFS/trace/ORA19DBFS_ora_509751_lob_block_dump1.trc

덤프 확인

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

$ vi /app/oracle/diag/rdbms/ora19dbfs/ORA19DBFS/trace/ORA19DBFS_ora_500143_basic_1982_block_dump2.trc
...
Start dump data blocks tsn: 4 file#:4 minblk 815029 maxblk 815029
Block dump from cache:
Dump of buffer cache at level 3 for pdb=0 tsn=4 rdba=17592245
Dump of buffer cache for pdb 0 tsn 4 rdba 0x10c6fb5 at level 2 done.
Block dump from disk:
buffer tsn: 4 rdba: 0x010c6fb5 (4/815029)
scn: 0x157a984 seq: 0x02 flg: 0x04 tail: 0xa9842802
frmt: 0x02 chkval: 0x0327 type: 0x28=PAGETABLE MANAGED LOB BLOCK
Hex dump of block: st=0, typ_found=1
Dump of memory from 0x00007F7E241F6000 to 0x00007F7E241F8000
7F7E241F6000 0000A228 010C6FB5 0157A984 04020000  [(....o....W.....]
7F7E241F6010 00000327 0000E741 01000000 2F000000  ['...A........../]
7F7E241F6020 0000241D 00000001 00000000 00000000  [.$..............]
7F7E241F6030 010C6FB0 00000000 41004100 41004100  [.o.......A.A.A.A]
7F7E241F6040 41004100 41004100 41004100 41004100  [.A.A.A.A.A.A.A.A]
        Repeat 246 times
7F7E241F6FB0 41004100 20004100 20002000 20002000  [.A.A.A. . . . . ]
7F7E241F6FC0 20002000 20002000 20002000 20002000  [. . . . . . . . ]
        Repeat 258 times
7F7E241F7FF0 20002000 20002000 20002000 A9842802  [. . . . . . .(..]
Block scn: 0x157a984
Long field block dump:
Object Id    59201
LobId: 00010002F1D24 PageNo        0
Version: 0x0000.00000001  pdba: 17592240
00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41
    00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41
    00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41
    00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41
    00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41
...
End dump data blocks tsn: 4 file#: 4 minblk 815029 maxblk 815029

이 블록은 LOB 블록이고(type: 0x28=PAGETABLE MANAGED LOB BLOCK)
덤프에 00 41 00 41...이 반복되고 있음(0x41(A) 값이 반복 되고 있음)

테스트3 결론 :
BASIC_1983 테이블 row 블록
=> col 1: [40]
=> LOB locator만 저장

BASIC_1983_LOB LOB 블록
=> type: 0x28=PAGETABLE MANAGED LOB BLOCK
=> 00 41 00 41 ... 실제 CLOB 데이터 저장

테이블 row 블록만 확인했을 때는 CLOB 컬럼에 해당하는 col 1의 길이가 40byte로 표시되었고 실제 문자열 데이터는 보이지 않았음
이는 row 내부에는 실제 CLOB 데이터가 아니라 LOB locator 정보만 저장되었음을 의미함
이후 locator가 가리키는 LOB 블록을 덤프해보면 해당 블록은 type: 0x28=PAGETABLE MANAGED LOB BLOCK으로 표시됨
또한 Long field block dump 영역에서 00 41 값이 반복적으로 확인되는데 이는 삽입한 'A' 문자열 데이터가 LOB 블록에 실제로 저장되어 있음을 의미함
따라서 1983byte 길이의 CLOB 데이터는 테이블 row 내부가 아니라 LOB 세그먼트의 LOB 블록에 out-of-line 방식으로 저장된 것으로 확인됨

4. SECUREFILE + 1985byte 데이터
4번 테스트 전에
SECUREFILE + 1983byte 데이터를 넣었더니 row에 같이 저장되었음(col 1: [3997])
SECUREFILE + 1984byte 데이터를 넣었더니 row에 같이 저장되었음(col 1: [3999])
그래서 이 테스트에선 1985byte 데이터를 넣음

샘플 테이블 생성

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

SQL>
DROP TABLE secure_1985 PURGE;
 
CREATE TABLE secure_1985
(
    id        NUMBER,
    c_data    CLOB,
    ins_date  DATE DEFAULT SYSDATE
)
TABLESPACE USERS
LOB (c_data) STORE AS SECUREFILE secure_1985_lob
(
    TABLESPACE USERS
    CHUNK 8192
    PCTVERSION 10
    NOCACHE
    LOGGING
);

dba_lobs로 정보 조회

1
2
3
4
5
6
7
8
9
10
11
12
13
14

SQL>
set lines 200 pages 1000
col table_name for a15
col column_name for a10
col segment_name for a20
col index_name for a25
col securefile for a5
SELECT table_name, column_name, segment_name, index_name, securefile, chunk, in_row, pctversion, retention, cache, logging
FROM   dba_lobs
WHERE  table_name = 'SECURE_1985';
 
TABLE_NAME      COLUMN_NAM SEGMENT_NAME         INDEX_NAME                SECUR      CHUNK IN_ PCTVERSION  RETENTION CACHE      LOGGING
--------------- ---------- -------------------- ------------------------- ----- ---------- --- ---------- ---------- ---------- -------
SECURE_1985     C_DATA     SECURE_1985_LOB      SYS_IL0000059218C00002$$  YES         8192 YES                       NO         YES

샘플 데이터 삽입(문자열 1985byte 길이 삽입)

1
2
3
4
5
6
7
8
9
10
11
12
13

SQL>
INSERT INTO secure_1985 (id, c_data)
values (1, TO_CLOB(RPAD('A', 1985, 'A')));
 
1 row created.
 
SQL> commit;
 
Commit complete.
 
SQL> alter system checkpoint;
 
System altered.

1건 삽입됨

clob 컬럼 실제 길이 확인

1
2
3
4
5
6
7
8
9

SQL>
SELECT COUNT(*) AS row_cnt,
       MAX(DBMS_LOB.GETLENGTH(c_data)) AS len,
       MAX(LENGTHB(DBMS_LOB.SUBSTR(c_data, 4000, 1))) AS lenb
FROM   secure_1985;
 
   ROW_CNT        LEN       LENB
---------- ---------- ----------
         1       1985       1985

1985byte CLOB임

논리 용량 vs CHUNK 기준 예상 용량

1
2
3
4
5
6
7
8
9
10

SQL>
SELECT COUNT(*) AS row_cnt,
       ROUND(SUM(DBMS_LOB.GETLENGTH(c_data)) / 1024, 2) AS logical_kb,
       ROUND(SUM(CEIL(DBMS_LOB.GETLENGTH(c_data) / 8192) * 8192)
             / 1024, 2) AS chunk_est_kb
FROM   secure_1985;
 
   ROW_CNT LOGICAL_KB CHUNK_EST_KB
---------- ---------- ------------
         1       1.94            8

1개 row의 논리 용량은 1.94kb, CHUNK 기준 예상 용량은 8kb임

실제 세그먼트 용량 확인

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

SQL>
col segment_name for a30
WITH lob_info AS
(
    SELECT segment_name,
           index_name
    FROM   user_lobs
    WHERE  table_name = 'SECURE_1985'
)
SELECT s.segment_name,
       s.segment_type,
       ROUND(s.bytes / 1024, 2) AS kb
FROM   dba_segments s
WHERE  s.segment_name = 'SECURE_1985'
OR     s.segment_name IN (SELECT segment_name FROM lob_info)
OR     s.segment_name IN (SELECT index_name FROM lob_info)
ORDER BY s.bytes DESC;
 
SEGMENT_NAME                   SEGMENT_TYPE               KB
------------------------------ ------------------ ----------
SECURE_1985_LOB                LOBSEGMENT               1216
SECURE_1985                    TABLE                      64
SYS_IL0000059218C00002$$       LOBINDEX                   64

LOB 세그먼트는 1216kb를 할당받았고 일반 세그먼트는 64kb를 할당받음

익스텐트 확인

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

SQL>
col segment_name for a25
SELECT segment_name,
       file_id,
   extent_id,
       block_id,
       blocks
FROM dba_extents
WHERE segment_name in('SECURE_1985','SECURE_1985_LOB','SYS_IL0000059218C00002$$')
ORDER BY extent_id;
 
SEGMENT_NAME                 FILE_ID  EXTENT_ID   BLOCK_ID     BLOCKS
------------------------- ---------- ---------- ---------- ----------
SECURE_1985                        4          0     815072          8
SECURE_1985_LOB                    4          0     815080         16
SYS_IL0000059218C00002$$           4          0     815096          8
SECURE_1985_LOB                    4          1     815328          8
SECURE_1985_LOB                    4          2     820224        128

SECURE_1985, SYS_IL0000059218C00002$$는 블록을 8개씩 할당 받아서 8 block * 8 kb(기본블록크기) => 64kb 이고
SECURE_1985_LOB는 총 3개 익스텐트를 할당 받고 블록을 각각 16개, 8개, 128개 할당 받아서 (16 block + 8 block + 128 block) * 8 kb(기본블록크기) = 1216kb 인것임
SECUREFILE의 내부 extent 할당 및 관리 구조가 반영된 결과이기 때문에 모든 환경에서 1985byte 데이터 1건이 항상 약 1MB를 차지한다고 일반화하기보다는 테스트 환경에서 관찰된 할당 크기로 봐야함

테스트 row의 물리 위치 확인

1
2
3
4
5
6
7
8
9
10

SQL>
select rowid,
       DBMS_ROWID.ROWID_TO_ABSOLUTE_FNO(rowid, USER, 'SECURE_1985') AS file#,
       DBMS_ROWID.ROWID_BLOCK_NUMBER(rowid) AS block#,
       DBMS_ROWID.ROWID_ROW_NUMBER(rowid) AS row#
from secure_1985;
 
ROWID                   FILE#     BLOCK#       ROW#
------------------ ---------- ---------- ----------
AAAOdSAAEAADG/mAAA          4     815078          0

4번 파일에 815078번째 블록에 있음

해당 블록 덤프

1
2
3
4
5
6
7
8
9

SQL>
alter session set tracefile_identifier = 'secure_1985_block_dump';
 
Session altered.
 
예시) alter system dump datafile <file#> block <block#>;
alter system dump datafile 4 block 815078;
 
System altered.

덤프 경로 확인

1
2
3
4
5
6
7
8

SQL>
select value
from v$diag_info
where name = 'Default Trace File';
 
VALUE
---------------------------------------------------------------------------------
/app/oracle/diag/rdbms/ora19dbfs/ORA19DBFS/trace/ORA19DBFS_ora_718764_secure_1985_block_dump.trc

덤프 확인

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

$ vi /app/oracle/diag/rdbms/ora19dbfs/ORA19DBFS/trace/ORA19DBFS_ora_718764_secure_1985_block_dump.trc
...
data_block_dump,data header at 0xe562e064
===============
tsiz: 0x1f98
hsiz: 0x14
pbl: 0xe562e064
     76543210
flag=--------
ntab=1
nrow=1
frre=-1
fsbo=0x14
fseo=0x1f63
avsp=0x1f4f
tosp=0x1f4f
0xe:pti[0]      nrow=1  offs=0
0x12:pri[0]     offs=0x1f63
block_row_dump:
tab 0, row 0, @0x1f63
tl: 53 fb: --H-FL-- lb: 0x1  cc: 3
col  0: [ 2]  c1 02
col  1: [38]
 00 70 00 01 02 0c 80 80 00 02 00 00 00 01 00 00 00 2f 1f 17 00 12 40 90 00
 0c 21 00 0f 82 01 00 01 01 0c 6f f3 01
col  2: [ 7]  78 7e 07 06 12 30 27
end_of_block_dump
...

이전 테스트와 달리 col1에 38byte만 존재함(lob locator만 존재하는것)(col 1: [38] 부분)

col 1: [38]의 끝부분에 01 0c 6f f3값이 존재함(맨뒤 01은 제외)
0x010c6ff3로 해석하면 file# 4, block# 815091를 가리키고 있음
해당 값의 데이터파일과 블록번호 확인

1
2
3
4
5
6
7
8

SQL>
SELECT DBMS_UTILITY.DATA_BLOCK_ADDRESS_FILE(TO_NUMBER('010c6ff3', 'XXXXXXXX'))  AS file_no,
       DBMS_UTILITY.DATA_BLOCK_ADDRESS_BLOCK(TO_NUMBER('010c6ff3', 'XXXXXXXX')) AS block_no
FROM dual;
 
   FILE_NO   BLOCK_NO
---------- ----------
         4     815091

해당 블록 덤프

1
2
3
4
5
6
7
8
9

SQL>
alter session set tracefile_identifier = 'lob_block_dump2';
 
Session altered.
 
예시) alter system dump datafile <file#> block <block#>;
alter system dump datafile 4 block 815091;
 
System altered.

덤프 경로 확인

1
2
3
4
5
6
7
8

SQL>
select value
from v$diag_info
where name = 'Default Trace File';
 
VALUE
---------------------------------------------------------------------------------
/app/oracle/diag/rdbms/ora19dbfs/ORA19DBFS/trace/ORA19DBFS_ora_729387_lob_block_dump2.trc

덤프 확인

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

$ vi /app/oracle/diag/rdbms/ora19dbfs/ORA19DBFS/trace/ORA19DBFS_ora_729387_lob_block_dump2.trc
...
Block header dump:  0x010c6ff3
 Object id on Block? Y
 seg/obj: 0xe753  csc:  0x000000000157d891  itc: 1  flg: E  typ: 5 - LOCAL LOBS
     fsl: 0  fnx: 0xffffffff ver: 0x01
 
 Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0x0008.003.0000319c  0x00000000.0000.00  -B--    0  fsc 0x0000.00000000
========
bdba    [0x010c6ff3]
kdlich  [0x7f2841bc904c 56]
  flg0  0x20 [ver=0 typ=data lock=n]
  flg1  0x00
  scn   0x000000000157d891 [0x0000.8000.0157d891]
  lid   000000010000002f1f17
  spare 0x00000000
kdlidh  [0x7f2841bc9064 24]
  flg2  0x00 [ver=0 lid=short-rowid hash=n cmap=n pfill=n]
  flg3  0x00
  pskip 0
  sskip 0
  hash  0000000000000000000000000000000000000000
  hwm   3970
  spr   0
  data  [0x7f2841bc9080 52 8060]
00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41
00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41
00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41
00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41
00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41 00 41
...
End dump data blocks tsn: 4 file#: 4 minblk 815091 maxblk 815091

이 블록은 SecureFile LOB 블록이고 블록 헤더에서 typ: 5 - LOCAL LOBS로 표시됨
kdlich 영역의 flg0 값에서 typ=data로 표시되고, kdlidh 아래의 data 영역에서 00 41 값이 반복적으로 확인됨
이는 삽입한 'A' 문자열 데이터가 SecureFile LOB 블록에 실제로 저장되어 있음을 의미함

테스트4 결론 :
SECURE_1985 테이블 row 블록
=> col 1: [38]
=> row 내부에는 LOB locator만 저장

SECURE_1985_LOB LOB 블록
=> typ: 5 - LOCAL LOBS
=> kdlich의 typ=data 확인
=> data 영역에 00 41 00 41 ... 실제 CLOB 데이터 저장

테이블 row 블록만 확인했을 때는 CLOB 컬럼에 해당하는 col 1의 길이가 38byte로 표시되었고 실제 문자열 데이터는 보이지 않았음
이는 row 내부에는 실제 CLOB 데이터가 아니라 LOB locator 정보만 저장되었음을 의미함
이후 locator가 가리키는 LOB 블록을 덤프해보면 해당 블록은 typ: 5 - LOCAL LOBS로 표시됨
또한 kdlich 영역에서 typ=data가 확인되고, kdlidh 아래의 data 영역에서 00 41 값이 반복적으로 확인됨
이는 삽입한 'A' 문자열 데이터가 SecureFile LOB 블록에 실제로 저장되어 있음을 의미함
따라서 1985byte 길이의 CLOB 데이터는 테이블 row 내부가 아니라 LOB 세그먼트의 LOB 블록에 out-of-line 방식으로 저장된 것으로 확인됨

최종 결론 :
CLOB 컬럼에 ENABLE STORAGE IN ROW가 활성화되어 있더라도 모든 CLOB 데이터가 무조건 row 내부에 저장되는 것은 아님
이번 테스트에서는 BasicFile CLOB과 SecureFile CLOB에 각각 1982byte, 1983byte, 1985byte(SECUREFILE) 길이의 데이터를 삽입하고 블록 덤프를 통해 실제 저장 위치를 확인해봤음
1982byte 데이터를 삽입한 경우에는 BasicFile, SecureFile 모두 테이블 row 블록의 CLOB 컬럼 영역에서 실제 데이터가 확인됨
BasicFile은 col 1: [4000], SecureFile은 col 1: [3995]로 표시되었고 해당 영역 안에서 00 41 값이 반복적으로 확인됨
이는 삽입한 'A' 문자열이 LOB 세그먼트가 아닌 테이블 row 내부에 저장되었음을 의미함

반면 BASICFILE에 1983byte 데이터를 삽입한 경우에는 테이블 row 블록의 CLOB 컬럼 영역이 col 1: [40]으로 표시됨
이는 row 내부에 실제 CLOB 데이터가 저장된 것이 아니라 LOB locator만 저장되었음을 의미함
이후 locator가 가리키는 LOB 블록을 덤프해보면 type: 0x28=PAGETABLE MANAGED LOB BLOCK으로 표시되고 Long field block dump 영역에서 00 41 값이 반복적으로 확인됨
즉 실제 CLOB 데이터는 LOB 세그먼트의 LOB 블록에 저장된 것으로 확인됨

그리고 SECUREFILE에 1985byte 데이터를 삽입한 경우에는 테이블 row 블록의 CLOB 컬럼 영역이 col 1: [38]으로 표시됨
이는 row 내부에 실제 CLOB 데이터가 저장된 것이 아니라 LOB locator만 저장되었음을 의미함
이후 locator가 가리키는 LOB 블록을 덤프해보면 typ: 5 - LOCAL LOBS으로 표시되고 kdlidh 아래의 data 영역에서 00 41 값이 반복적으로 확인됨
즉 실제 CLOB 데이터는 LOB 세그먼트의 LOB 블록에 저장된 것으로 확인됨
그리고 SecureFile CLOB이 out-of-line으로 저장되면서 SECURE_1985_LOB 세그먼트가 총 1216KB까지 할당되었음
다만 이는 SecureFile의 내부 extent 할당 및 관리 구조가 반영된 결과이므로 모든 환경에서 1985byte 데이터 1건이 항상 약 1MB를 차지한다고 일반화하기보다는 테스트 환경에서 관찰된 할당 크기로 봐야함

19c 환경에서 ENABLE STORAGE IN ROW 상태의 CLOB은 LOB 값과 내부 control information을 합친 크기가 약 4000byte 이하이면 테이블 row 내부에 저장될 수 있음
하지만 이 기준을 초과하면 row 내부에는 LOB locator만 저장되고 실제 CLOB 데이터는 LOB 세그먼트에 out-of-line 방식으로 저장됨
이 기준이 BASICFILE은 1982byte이고, SECUREFILE은 1985byte임

참조 :

오라클 11gR2 CLOB 컬럼 STORAGE IN ROW 옵션별 용량 확인 테스트 ( https://positivemh.tistory.com/1418 )
How to Calculate Space Used by LOB Segments in the Database(KB114063)
CLOB Is Stored Out-of-line When Insert CLOB Data Greater Than 1982 Bytes(KB139645)
How to Compute the Size of a Table containing Outline CLOBs and BLOBs(KB149847)
How to Determine what storage is used in a LOBSEGMENT and should it be shrunk / reorganized?(KB164984)
CLOBs and NCLOBs character set storage in Oracle Release 8i, 9i, 10g and higher(KB772367)
https://docs.oracle.com/en/database/oracle/oracle-database/19/adlob/LOB-storage-with-applications.html#GUID-B82B3C24-1FAF-4661-96A0-28241FD2A052
https://docs.oracle.com/en/database/oracle/oracle-database/21/adlob/creating-new-LOB-column.html#GUID-6378560B-4305-496A-95A7-1FDFB6719FDC
https://hrjeong.tistory.com/294

내맘대로긍정

오라클 Exadata cellcli list 명령에서 attributes 목록 확인

EXADATA Image : 22.1.33.0.0.250304

OS 환경 : Oracle Linux 7.9 (64bit)

DB 환경 : Oracle Database 19.31.0.0

방법 : 오라클 Exadata cellcli list 명령에서 attributes 목록 확인

오라클 26ai select ai 로컬 llm 이용(로컬 gpu 서버) 방법

OS 환경 : Oracle Linux 9.6 (64bit)

DB 환경 : Oracle AI Database 23.26.2.0.0 ai

방법 : 오라클 26ai select ai 로컬 llm 이용(로컬 gpu 서버) 방법

오라클 26ai deadlock 자동 테스트 스크립트

OS 환경 : Oracle Linux 9.6 (64bit)

DB 환경 : Oracle AI Database 23.26.2.0.0 ai

방법 : 오라클 26ai deadlock 자동 테스트 스크립트

오라클 19c insert 시 undo 발생량 확인 및 감소 테스트

OS 환경 : Oracle Linux 9.4 (64bit)

DB 환경 : Oracle Database 19.31.0.0

방법 : 오라클 19c insert 시 undo 발생량 확인 및 감소 테스트

AIX nmon 명령어를 이용한 시스템 자원 모니터링

OS 환경 : AIX 7.2 (64bit)

DB 환경 : Oracle Database 19.27.0.0

방법 : AIX nmon 명령어를 이용한 시스템 자원 모니터링

ORA-12162: TNS:net service name is incorrectly specified

OS 환경 : Oracle Linux 8.7 (64bit)

DB 환경 : Oracle Database 19.27.0.0

에러 : ORA-12162: TNS:net service name is incorrectly specified

해결 방법 : ORACLE_SID 환경 변수 설정

원인 : OS 환경변수(ORACLE_SID)가 제대로 설정되어 있지 않아 발생한 문제

처음 만나는 오라클 AI 데이터베이스 실습 스크립트

처음 만나는 오라클 AI 데이터베이스 출간 안내

서적 명 : 처음 만나는 오라클 AI 데이터베이스 - 내맘대로긍정이 알려주는 26ai 신기능 가이드

구매처 : 인터넷 온라인 서점 등

책소개

목차

실습 스크립트

오라클 26ai autoupgrade시 block checking 이벤트로 인한 hang 현상

OS 환경 : Oracle Linux 9.6 (64bit)

DB 환경 : Oracle AI Database 23.26.2.0.0 ai, 19.31

방법 : 오라클 26ai autoupgrade시 block checking 이벤트로 인한 hang 현상

오라클 19c CLOB 컬럼 STORAGE IN ROW 옵션별 저장 위치 확인 테스트

OS 환경 : Oracle Linux 9.6 (64bit)

DB 환경 : Oracle Database 19.31.0.0

방법 : 오라클 19c CLOB 컬럼 STORAGE IN ROW 옵션별 저장 위치 확인 테스트