[EXADATA] Cell_Offlload_Processing

haisins

7년 ago

cell offload processing 에 대한 이해와 검증을 위해서 아래의 시나리오을 실습합니다.

이번 실습은 난이도가 높은 실습 입니다.

· Demonstrate Smart File creation for Creating Tablespaces

· Demonstrate Smart Scan processing for Table Scans

· Demonstrate Smart Scans in Index Fast Full Scan

· Demonstrate Smart Scans in Bitmap Index Scan

· Demonstrate Exadata Cell failure

· Shutdown the Lab Environment

Tablespaces 생성을 통해 Smart File creation 검증

Exadata 의 주요 특장점인 Smart File creation은 file 생성을 cell offloading 을 통해 성능을 극대화 합니다. 아래의 실습을 통해서 그 내용을 이해하고 검증해 보도록 하겠습니다.아래의 실습은 lab_user DB 사용자 계정으로 진행 합니다.

v$sysstat 뷰 테이블을 통해 현재 cell physical io bytes saved during smart file creation 값을 확인 할 수 있습니다. 이 통계 정보는 Smart File creation 을 사용하는 동안 발생한 IO bytes 입니다.

SQL> select name, value from v$sysstat where name = ‘cell physical IO bytes saved during optimized file creation’;

NAME VALUE

—————————————————————- ———-

cell physical IO bytes saved during optimized file creation 0

cell_offload_processing 파라미터의 값을 TRUE 로 설정한 이후 tablespace 생성 명령어을 수행 합니다. cell_offload_processing 파라미터는 smart processing 을 위해서 Exadata 에서 고려 되어야 하는 파라미터 입니다. tablsepace 생성 이후 cell physical io bytes 의 변경된 값을 확인 합니다. 변경된 값을 비교하면, Exadata Cell 의 offloading 을 통해서 얻을 수 있는 이점 등을 확인 할 수 있습니다.

SQL> alter session set cell_offload_processing = TRUE;

Session altered.

SQL> create tablespace smart_file_tbs datafile ‘+DATA’ size 100M;

Tablespace created.

SQL> select name, value from v$sysstat where name = ‘cell physical IO bytes saved during optimized file creation’;

NAME VALUE

—————————————————————- ———-

cell physical IO bytes saved during optimized file creation 838860800

이번에는 cell_offload_processing 파라미터을 turn-off 로 변경하고, “_cell_fast_file_create” 파라미터을 FALSE로 설정한 이후 tablespace 삭제 후 생성 명령을 다시 수행합니다. 그리고 smart file 생성 후 cell physical IO bytes 값을 확인하여 위의 결과값과 비교합니다. 이것을 통해 cell_offload_processing 파라미터을 turn-off 시키면 smart file creation 의 이점이 전혀 없다는 것을 알 수 있습니다.

SQL> alter session set “_cell_fast_file_create” = FALSE;

Session altered.

SQL> drop tablespace smart_file_tbs including contents;

Tablespace dropped.

SQL> create tablespace smart_file_tbs datafile ‘+DATA’ size 100M;

Tablespace created.

SQL> select name, value from v$sysstat where name = ‘cell physical IO bytes saved during optimized file creation’;

NAME VALUE

—————————————————————- ———-

cell physical IO bytes saved during optimized file creation 838860800

SQL> drop tablespace smart_file_tbs;

Tablespace dropped.

효율적인 Table Scans 위한 Smart Scan Processing 검증

v$sql 뷰테이블을 통해서 아래의 통계 정보을 확인 합니다.

IO_INTERCONNECT_BYTES: query 을 위해 통신한 IO 값에 대한 지표 입니다. 이 값을 통해서 block IO 와 smart IO 에 대한 통계을 알 수 있습니다 .
IO_DISK_BYTES: query을 위해 cell 의 IO 성능에 대한 지표 입니다. 이 값을 통해서 cell IO 성능에 대한 block IO 와 smart IO 에 대한 통계을 알 수 있습니다 .
IO_CELL_OFFLOAD_ELIGIBLE_BYTES: query을 위해 cell의 smart scan 을 위해 offload 된 IO 값에 대한 지표 입니다. Cell Offload Processiong 에 대한 통계을 알 수 있는 아주 중요한 지표 입니다.

$sysstat 뷰테이블을 통해서 아래의 통계 정보을 확인 합니다.

cell physical IO interconnect bytes: 인스턴스 서비스 이후부터 모든 Cell 로부터 서비스된 IO의 통계 지표을 나타냅니다. 이 이 값을 통해서 block IO 와 smart IO 에 대한 통계을 알 수 있습니다 .

physical IO disk bytes: 인스턴스 서비스 이후 cell 의 IO 성능에 대한 지표 입니다. 이 값을 통해서 cell IO 성능에 대한 block IO 와 smart IO 에 대한 통계을 알 수 있습니다 .

cell physical IO bytes eligible for predicate offload: 인스턴스 서비스 이후 위해 cell의 smart scan 을 위해 offload 된 IO 값에 대한 지표 입니다. Cell Offload Processiong 에 대한 통계을 알 수 있는 아주 중요한 지표 입니다.

lab_user 로 접속해서 아래의 단계을 순차적으로 수행 합니다.

이번 단계에서는 몇가지 Query 을 수행함을 통해서 lab_table 에 block I/O 을 생성 시킵니다. I/O 을 발생하는 Query의 조건을 간제적으로 정의하기 위해서 아래의 파라미터 값을 변경 합니다. 파라미터 offload_processing 값을 FALSE 로 변경합니다. offload processing 을 사용하지 못하도록 변경했기 때문에 Exadata cell 에서 predicate filtering 이 수행되지 못하게 됩니다.

count(*) query 을 수행해서 Exadata cell 의 I/O 사용 통계에 대한 값을 확인 합니다. 통계 정보의 값을 확인하기 위해서 v$sql_text 뷰테이블을 조회 합니다.

SQL> show parameter cell;

NAME TYPE VALUE

———————————— ———– ——————————

_cell_fast_file_create boolean FALSE

cell_offload_compaction string ADAPTIVE

cell_offload_parameters string

cell_offload_plan_display string AUTO

cell_offload_processing boolean TRUE

cell_partition_large_extents string DEFAULT

SQL> alter session set cell_offload_processing = FALSE;

Session altered.

SQL> select count(*) from lab_table where object_id>-10;

COUNT(*)

———-

1442154

SQL> select sql_text, sql_id, io_cell_offload_eligible_bytes, io_interconnect_bytes, io_disk_bytes from v$sql where sql_text like ‘select count(*) from lab_table where object_id>-10’;

SQL_TEXT

——————————————————————————–

SQL_ID IO_CELL_OFFLOAD_ELIGIBLE_BYTES IO_INTERCONNECT_BYTES IO_DISK_BYTES

————- —————————— ——————— ————-

select count(*) from lab_table where object_id>-10

cjgs05a0400y5 0 128065536 128065536

io_cell_offload_eligible_bytes 값이 0 인 것을 확인 함으로써, 위 SQL을 통해서 block IO가

Exadata Cell 에서 predicate filtering 없이 수행 되어졌다는 것을 이해 할 수 있습니다.

이번 단계에서는 몇가지 Query 을 수행함으로 lab_table 에서 predicate I/Os ( 또는 Smart I/Os) 가 발생하도록 확인 하겠습니다. 이을 위해서 파라미터 cell_offload_processing 값을 TRUE 로 조정해서 진행 합니다. 이 파라미터 값이 TRUE 하 할지라도, 모든 Query 가 predicate I/Os ( 또는 Smart I/Os) 을 하게 되는 것은 아닙니다.

그렇기 때문에 직접 Exadata Cell 을 읽어서 강제적으로 무조건 predicate I/Os ( 또는 Smart I/Os) 을 수행하도록 몇가지 파라미터을 추가적으로 변경 해야합니다. 즉 병렬 Query가 수행되지 않아서 직접 Exadata Cell 을 읽지 않을때에도 강제적으로 Exadata Cell 을 읽도록 하는 것입니다. 이를 위해서 파라미터 “_serial_direct_read” 값을 TRUE 로 변경 합니다.위 조건에서는 병렬 Query 가 수행되지 않을 때에도 buffer cache 을 거지치 않고 Exadata Cell 에서 직접 데이터을 읽어 오게 됩니다.

아래 SQL 의 실행계획을 통해서 위의 예상 결과을 확인 할 수 있습니다. 특히 Predicate clause 부분은 Exadata Cell Offload Processing 에 대한 실행계획 입니다.

SQL> alter session set cell_offload_processing=TRUE;

Session altered.

SQL> alter session set “_serial_direct_read”=TRUE;

Session altered.

SQL> set autotrace on

SQL> select count(*) from lab_table where object_id>-9;

COUNT(*)

———-

1442154

Execution Plan

———————————————————-

Plan hash value: 2189604569

——————————————————————————–

——–

me |

——————————————————————————–

——–

| 0 | SELECT STATEMENT | | 1 | 13 | 5815 (1)| 00

:01:10 |

| 1 | SORT AGGREGATE | | 1 | 13 | |

|* 2 | TABLE ACCESS STORAGE FULL| LAB_TABLE | 1347K| 16M| 5815 (1)| 00

:01:10 |

——————————————————————————–

——–

Predicate Information (identified by operation id):

—————————————————

2 – storage(“OBJECT_ID”>(-9))

filter(“OBJECT_ID”>(-9))

Note

—–

– dynamic sampling used for this statement

Statistics

———————————————————-

298 recursive calls

0 db block gets

21424 consistent gets

21325 physical reads

0 redo size

421 bytes sent via SQL*Net to client

420 bytes received via SQL*Net from client

2 SQL*Net roundtrips to/from client

5 sorts (memory)

0 sorts (disk)

1 rows processed

SQL> set autotrace off

SQL> select sql_text, sql_id, io_cell_offload_eligible_bytes, io_interconnect_bytes, io_disk_bytes from v$sql where sql_text = ‘select count(*) from lab_table where object_id>-9’;

SQL_TEXT

——————————————————————————–

SQL_ID IO_CELL_OFFLOAD_ELIGIBLE_BYTES IO_INTERCONNECT_BYTES IO_DISK_BYTES

————- —————————— ——————— ————-

select count(*) from lab_table where object_id>-9

84uhhywhqd17n 174776320 16583304 174776320

Index Fast Full Scan 을 통한 Smart Scans 검증

lab_user로 접속해서 아래의 단계을 수행 합니다.

우선 lab_table 에 lab_table_index 을 생성합니다.

SQL> create index lab_table_index on lab_table (object_id, owner);

Index created.

lab_table 에 Index Fast Full Scan 을 할 수 있도록 Hint 을 주어서 아래의 SQL을 수행 합니다. cell offload processing 이 수행되도록 하기 위해서 아래와 같이 2개 파라미터의 값을 조정 합니다. 실행 계획을 확인하면 storage 와 filter clause 부분에서 Index Fast Full Scan 이 Cell Offload Processing 을 수행 한 것을 확인 할 수 있습니다.

SQL> alter session set cell_offload_processing = TRUE;

Session altered.

SQL> alter session set “_serial_direct_read” = TRUE;

Session altered.

SQL> set autotrace on

SQL> select /*+INDEX_FFS(lab_table lab_table_index) */ count(*) from lab_table where owner = ‘EXADATA’;

COUNT(*)

———-

Execution Plan

———————————————————-

Plan hash value: 734070628

——————————————————————————–

—————–

%CPU)| Time |

——————————————————————————–

—————–

| 0 | SELECT STATEMENT | | 1 | 17 | 1222

(2)| 00:00:15 |

| 1 | SORT AGGREGATE | | 1 | 17 |

| |

|* 2 | INDEX STORAGE FAST FULL SCAN| LAB_TABLE_INDEX | 235 | 3995 | 1222

(2)| 00:00:15 |

——————————————————————————–

—————–

Predicate Information (identified by operation id):

—————————————————

2 – storage(“OWNER”=’EXADATA’)

filter(“OWNER”=’EXADATA’)

Note

—–

– dynamic sampling used for this statement

Statistics

———————————————————-

5 recursive calls

0 db block gets

4440 consistent gets

4361 physical reads

0 redo size

417 bytes sent via SQL*Net to client

420 bytes received via SQL*Net from client

2 SQL*Net roundtrips to/from client

0 sorts (memory)

0 sorts (disk)

1 rows processed

Bitmap Index Scan 을 통한 Smart Scans 검증

lab_user 로 접속해서 아래의 단계을 수행 합니다.

lab_table에 bitmap index lab_table_bitmap 을 생성 합니다.

SQL> create bitmap index lab_table_bitmap on lab_table (owner);

Index created.

lab_table 에 Index Fast Full Scan 을 할 수 있도록 Hint 을 주어서 아래의 SQL을 수행 합니다. cell offload processing 이 수행되도록 하기 위해서 아래와 같이 2개 파라미터의 값을 조정 합니다. 실행 계획을 확인하면 storage 와 filter clause 부분에서 lab_table_bitmap 이 Cell Offload Processing 을 수행 한 것을 확인 할 수 있습니다.

SQL> alter session set cell_offload_processing = TRUE;

Session altered.

SQL> alter session set “_serial_direct_read” = TRUE;

Session altered.

SQL> set autotrace on

SQL> select /*+INDEX_FFS(lab_table lab_table_bitmap)*/ count(*) from lab_table where owner = ‘SYS’;

COUNT(*)

———-

626682

Execution Plan

———————————————————-

Plan hash value: 1529707086

——————————————————————————–

——————

(%CPU)| Time |

——————————————————————————–

——————

| 0 | SELECT STATEMENT | | 1 | 17 | 953

(2)| 00:00:12 |

| 1 | SORT AGGREGATE | | 1 | 17 |

| |

|* 2 | INDEX STORAGE FAST FULL SCAN| LAB_TABLE_BITMAP | 563K| 9353K| 953

(2)| 00:00:12 |

——————————————————————————–

——————

Predicate Information (identified by operation id):

—————————————————

2 – storage(“OWNER”=’SYS’)

filter(“OWNER”=’SYS’)

Note

—–

– dynamic sampling used for this statement

Statistics

———————————————————-

9 recursive calls

0 db block gets

3475 consistent gets

3393 physical reads

0 redo size

420 bytes sent via SQL*Net to client

420 bytes received via SQL*Net from client

2 SQL*Net roundtrips to/from client

0 sorts (memory)

0 sorts (disk)

1 rows processed

SQL> exit;

Exadata Cell Failure 에 대한 검증

아래의 검증을 위한 실습은 2개의 Exadata Cell 환경일 경우에만 가능합니다.
(Exadata Cell1, Exadata Cell2)

lab_user 로 sqlplus 에 접속해 아래의 SQL 을 수행 합니다. 아래의 SQL 이 연속적으로 수행 되고 있을때 2번째 단계을 동시에 실행 합니다.

select count(*) from lab_table;

PuTTY(SSH) 을 통해 root 계정Exadata Cell 에 접속해서 init0 명령어로 시스템을 강제적으로 shutdown 시킵니다.

login as: root

root@192.168.204.201’s password:

Last login: Tue Feb 10 20:02:07 2009

[root@ExadataCell1 ~]# init 0

1번째의 sqlplus session 을 통한 SQL 수행이 연속적으로 수행되고 있음을 확인 할 수 있습니다. 이것은 ASM 이 Normal Redundancy 의 속성으로 DISK GROUP 을 생성하였기 때문에 Exadata Cell1 이 Failure 시에도 Exadata Cell1의 ASM Failure Group 을 통해서 연속적으로 서비스 되고 있음을 보여줍니다.