트랜잭션 롤백
트랜잭션이 테이블의 행을 변경할  때, 이전 이미지는 롤백 세그먼트에 저장됩니다. 트랜잭션이 롤백되었을 경우, 롤백 세그먼트의 값은 행에 다시 기록되어 원래의 값이 복원됩니다.

트랜잭션 복구
트랜잭션이 진행 중 일 때 인스턴스가 비정상적으로 종료할 경우, 오라클 서버는 데이터베이스가 다시 오픈될 때 커밋되지 않은 변경 내역을 롤백할 필요가 있습니다.  이러한 롤백은 트랜잭션 복구로 알려져 있으며, 롤백 세그먼트에 행해진 변경 내역이 또한 리두 로그 파일에 의해 보호될 경우에만 가능합니다.

읽기 일관성
트랜잭션이 진행 중 일 때, 데이터베이스의 다른 사용자들은 이들 트랜잭션에 의해 행해진 커밋되지 않은 다른 변경 사항을 보아서는 안됩니다. 이외에도, 문장은 실행되기 시작한 후 커밋된 어떠한 변경 사항도 보아서는 안됩니다. 롤백 세그먼트의 이전 값은 또한 reader에게 특정 문장의 일관된 이미지를 제공하는데 사용됩니다.

활동 및 비활동 이벤트
트랜잭션은 현재의 익스텐트가 채워지면 다음 익스텐트로 이동하는 순차적 순환방식으로 롤백 세그먼트의 익스텐트를 사용합니다. 트랜잭션은 롤백 세그먼트의 현 위치에 레코드를 기록하며 레코드 크기별로 현재의 포인터를 내보냅니다.
주의: 하나 이상의 트랜잭션이 롤백 세그먼트의 동일한 익스텐트에 기록할 수 있습니다. 각 롤백 세그먼트 블록에는 한 트랜잭션만이 제공하는 정보가 포함되어 있습니다.

롤백 세그먼트 활동
롤백 세그먼트에 기록하기 위해서는 캐쉬에 버퍼가 필요하고(또한 직접 쓰기를 하지 않으며)  데이터 블록을 포함하는 버퍼를 overlay하므로 더 많은 물리적 I/O를 요구하기 때문에, 롤백 활동은 적중율에 영향을 미칠 수 있습니다. 일반적으로 데이터 세그먼트와 롤백 세그먼트 모두에 액세스할 필요가 있는 질의는 별도로 데이터 세그먼트에만 액세스되는 경우보다 더 느리게 수행됩니다.

롤백 세그먼트 헤더 활동
오라클 서버는 트랜잭션 테이블을 모든 롤백 세그먼트의 헤더에 보관합니다.

롤백 세그먼트 헤더 활동은 변경된 데이터 블록을 롤백 세그먼트에 기록하는 활동을 제어합니다. 롤백 세그먼트 헤더는 데이터 블록이며, 빈번하게 수정됩니다. 따라서, 롤백 세그먼트 헤더 블록은 오랫동안 데이터 블록 버퍼 캐시에 남게 될 것입니다. 그렇기 때문에, 롤백 세그먼트 헤더 블록에 액세스하는 것은 데이터 블록과 관계가 없다 하더라도 애플리케이션에 대한 적중율을 증가시킬 것입니다.

롤백 세그먼트 헤더 활동의 영향
롤백 세그먼트 헤더 활동이 캐쉬적중율에 미치는 영향은 규모가 작은 트랜잭션을 많이 수행하는 OLTP 시스템에게는 매우 중요할 것입니다.

모든 트랜잭션은 갱신 작업을 수행하기 위하여 롤백 세그먼트에 대한 트랜잭션 테이블에 액세스해야 합니다. 트랜잭션이 트랜잭션 테이블을 사용하기 위해 경쟁하는 것을 막기 위해서는 충분한 롤백 세그먼트가 필요합니다.

필요한 롤백 세그먼트의 수를 필요 이하로 산정할 경우, 성능은 저하되고 트랜잭션은 오류를 생성하게 될 것입니다.

롤백 세그먼트의 수를 필요 이상으로 산정할 경우에는 추가 공간이 필요합니다. 

롤백 세그먼트의 증가
롤백 세그먼트의 포인터 또는 헤드는 현재의 익스텐트가 가득 차면, 다음 익스텐트로 이동합니다. 현재 이용할 수 있는 마지막 익스텐트가 가득 차면, 포인터는 익스텐트가  비어 있을 경우 첫번째 익스텐트의 시작으로만 다시 이동할 수 있습니다.  포인터는 익스텐트를 건너 뛰어 두번째 익스텐트나 다른 익스텐트로 이동할 수 없습니다. 첫번째 익스텐트가 사용 중이라면, 트랜잭션은 롤백 세그먼트에 대해 추가 익스텐트를 할당할 것입니다. 이것을 '확장'이라고 합니다. 이와 비슷하게, 헤드가 활동 익스텐트로 이동하려고 하면, 롤백 세그먼트는 추가 익스텐트를 할당할 것입니다.

롤백 세그먼트 확장으로 인한 영향
롤백 세그먼트는 정상적인 실행 동안에는 확장되어서는 안됩니다. 이것은 세그먼트당 익스텐트의 수에 따라 다릅니다. 롤백 세그먼트는 트랜잭션에 대한 롤백 엔트리를 유지할 수 있을 만큼 충분히 커야 합니다.

다른 객체를 사용할 때처럼, 동적인 공간 관리를 피해야 합니다.
필요한 롤백 세그먼트의 수를 필요 이하로 산정할 경우, 성능은 저하되고 트랜잭션은 오류를 생성하게 될 것입니다.

롤백 세그먼트의 수를 필요 이상으로 산정할 경우에는 추가 공간이 필요합니다.

Read Only 및 Read Write 트랜잭션

• 모든 트랜잭션에 대해 디폴트 상태는 ‘문장 레벨 읽기 일관성(Read Write 트랜잭션)'입니다.
• '트랜잭션 레벨 읽기 일관성(Read Only 트랜잭션)’도 설정할 수 있습니다. Read Only 트랜잭션에서 모든 후속 질의는 트랜잭션이 시작하기 전에 커밋된 변경사항만 봅니다.
  
  CONSISTENT = Y로 하고 익스포트할 경우, 트랜잭션은 Read Only 으로 설정됩니다.
  DML 문장은 허용되지 않습니다.

연속가능한(Serializable) 분리 레벨 트랜잭션과 읽기 커밋된 분리 레벨 트랜잭션

• 모든 트랜잭션에 대한 디폴트 오라클 행동은 ‘읽기 커밋된 분리 레벨(read committed isolation level)’입니다. 트랜잭션이 다른 트랜잭션이 점유하고 있는 행 잠금(lock)을 요구하는 DML 을 포함하고 있을 경우, DML 문은 행 잠금이 해제될 때까지 기다립니다. 읽기 커밋된  분리 레벨은 더 많은 동시성을 제공합니다.
• 연속 가능한 분리 레벨은 Read Only 트랜젝션이 제공하는 일관성도 제공하고 DML 문도 허용합니다.
  
  연속가능한 분리 레벨 트랜재션이 연속가능한 트랜잭션 시작 시 커밋되지 않은 트랜잭션에서  갱신된 행을 갱신하는 DML 문을 실행시키려고 시도할 경우, DML 문은 비정상적으로  종료됩니다.
  
  이 분리 레벨은, 2개의 동시 트랜잭션이 동일한 행을 수정 할 가능성이 비교적 적고, 상대적으로 길게 실행되는 트랜잭션이 주로 Read Only인 환경에 적합합니다 (큰 데이터베이스와 짧게 실행되는 트랜잭션은 행을 적게 갱신합니다).

Read Only 트랜잭션과 연속가능한 트랜잭션의 영향
모든 커밋된 변경 사항은 Read Only 트랜잭션이나 연속가능한 트랜잭션이 COMMIT으로 종료될 때까지 롤백 세그먼트에 보관됩니다. 애플리케이션 개발자는 데이터를 롤백하는 데에 드는 비용을 고려해야 합니다.

튜닝 목표

• 트랜잭션은 결코 롤백 세그먼트에 액세스하기를 기다려서는 안됩니다. 이것은 롤백 세그먼트  수에 따라 좌우됩니다.
   
• 롤백 세그먼트는 정상적인 실행 동안에는 확장되어서는 안됩니다. 이것은 다음에 따라 좌우됩니다:
  -  세그먼트 당 익스텐트 수
  -  적절한 익스텐트 크기
  -  적절한 롤백 세그먼트 수
  -  롤백을 적게 사용할 수 있는 유틸리티의 적절한 사용
  
  
• 크거나 예외적인 트랜잭션은 롤백 공간이 부족해서는 안됩니다. 이것이 의미하는 바는 다음과 같습니다:
  -  롤백 세그먼트의 크기는 정확하게 재조정되어야 합니다.
  -  큰 트랜잭션은 더 작은 트랜잭션으로 분할되어야 합니다.
  
  
• reader는 필요로 하는 읽기 일관성 이미지를 항상 볼 수 있어야 합니다. 이것은 다음에  따라 좌우됩니다:
  -  롤백 세그먼트 수
  -  롤백 세그먼트 크기

동적인 뷰와 Report.txt 출력 결과

• V$ROLLNAME뷰는 온라인 롤백 세그먼트의 이름과 수를 출력합니다.
  
  
• V$ROLLSTAT뷰는 각 온라인 롤백 세그먼트의 활동에 관한 통계를 출력합니다:
  -  헤더 트랜잭션 테이블에서의 대기 수
  -  트랜잭션에 의해 쓰여지는 바이트 양
  
  
• REPORT.TXT 출력 결과는 헤더 트랜잭션 테이블에서 기다리고 있는데 소요된 시간을 나타냅니다. 이들 수치는 utlbstat와 utlestat가 실행되는 기간을 포함합니다.
  
  
• V$SYSTEM_EVENT 뷰: “undo segment tx slot” 이벤트는 트랜잭션 슬롯에 대한 대기와 롤백   세그먼트 헤더에 대한 경합을 나타냅니다.
  
  
• V$WAITSTAT뷰는 헤더 블록과 시스템 및 비시스템 롤백 세그먼트의 데이터 블록에 대한  대기와 관련된 누적 통계를 출력합니다.
  
  
• V$SYSSTAT 뷰는 데이터 블록의 획득(consistent and data block gets) 수를 출력합니다. 총  데이터 요청 수를 사용하여 대기 수를 계산할 수 있습니다.
  
  
• V$TRANSACTION 뷰는 롤백 세그먼트를 사용하는 현재의 트랜잭션과 필요한 공간의 양을 출력합니다.

주의: OEM 진단 팩 애플리케이션
Performance Manager -> Contention -> 롤백 비 대기(Nowait) 적중 %
Performance Manager -> Database_instance -> 시스템 통계 

비율

• V$ROLLSTAT의 WAITS 열, V$WAITSTAT의 UNDO HEADER 열, 또는 V$SYSTEM_EVENT 의 “undo segment tx slot” 이벤트에서 값이 0이 아닐 때, 이것은 롤백 세그먼트 헤더 블록에 대해  경합이 있다는 것을 나타냅니다.
  
   SQL> select class, count from v$waitstat
     2  where class like ‘%undo%’;
  
   CLASS                   COUNT
   ----------------- -----------
   system undo header          0
   system undo block           0
   undo header                 7
   undo block                  0
  
  WAITS의 합계 대 GETS의 합계의 비율은 거의 0 이어야 합니다.
  
  
• Report.txt 출력 결과: report.txt 출력 결과의 이 섹션은 V$ROLLSTAT 뷰의 WAITS 열  및 GETS 열과 동일한 정보를 나타내지만, 통계는 더 긴 기간 동안 수집된 것입니다.
  
   UNDO_SEGMENT     TRANS_TBL_GETS     TRANS_TBL_WAITS
   ------------  -----------------  ------------------
              0                  8                   0
              1                749                 118
              2                878                  95
  
  
• 이벤트 “undo segment tx slot”: V$SYSTEM_EVENT의 이 이벤트는 트랜잭션 슬롯에 대한   대기를 나타냅니다. 또한, 경합이 반드시 헤더 경합을 의미하는 것이 아니라는 사실을 주의하십시오. 버퍼 캐쉬크기 또한 정확하게 조정되어야 합니다.

Guidelines
비율이 1% 보다 클 경우, 더 많은 롤백 세그먼트를 생성할 것을 고려하십시오. 

비율
동일한 기간 동안 블록의 각 클래스에 대한 대기 수와 데이터 요청의 총합을 비교하십시오.
   
 SQL> select class, count from v$waitstat
   2  where class like ‘%undo%’;

 CLASS                 COUNT
 ------------------ --------
 system undo header        0
 system undo block         0
 undo header               7
 undo block                0

 SQL> select sum(value) from v$systat
   2  where name = ‘consistent gets’;

 SUM(VALUE)
 ----------
      71563

클래스에 대한 비율은 총 요청 수의 1% 이하이어야 합니다.

Guidelines
비율이 1% 보다 클 경우, 더 많은 롤백 세그먼트를 생성할 것을 고려하십시오.

OLTP 트랜잭션

• OLTP 애플리케이션의 특징은 적은 양의 데이터를 수정하는 트랜잭션이 빈번하게  발생한다는 것입니다. 여러 작은 롤백 세그먼트를 OLTP 트랜잭션에 할당하십시오.
  
  
• 최고 200명의 사용자의 경우, 4건의 트랜잭션에 대해 하나의 롤백 세그먼트를 할당하면 적당합니다.

긴 배치 트랜잭션

• 큰 롤백 세그먼트는 대량의 데이터를 수정하는 트랜잭션에 할당하십시오. 이러한 트랜잭션은  큰 롤백 엔트리를 생성합니다. 롤백 엔트리가 롤백 세그먼트에 적합하지 않을 경우, 오라클은  세그먼트를 확장합니다. 동적으로 확장할 경우, 성능이 저하되므로 가능할 때마다 피해야 합니다. 무제한의 MAXEXTENTS를 사용해서 크거나 자동확장이 가능한 테이블스페이스에 롤백 세그먼트를 생성하여 롤백 세그먼트가 증가할 수 있도록 허용하십시오.
  
  
• 예외적으로 긴 트랜잭션에 대해서는, 다음 구문을 사용하여 큰 롤백 세그먼트를 할당하고자  할 것입니다:
  
   SQL> SET TRANSACTION USE ROLLBACK SEGMENT large_rbs;
  
  또한 제공된 프로시저를 사용할 수 있습니다:
  
   SQL> EXECUTE dbms_transaction.use_rollback_segment ('large_rbs');
  
  명시적이든 암시적이든 어떠한 커밋이라도 트랜잭션을 종료시킨다는 사실을 명심하십시오.
          
  주의: SET TRANSACTION USE 롤백 세그먼트는 반드시 트랜잭션에서의  첫번째 문장이어야 합니다. 

저장장소 파라미터
롤백 세그먼트의 크기 설정은 성능에 중요합니다. 크기를 적절하게 설정함으로써, 동적인 확장을 감소시키고 롤백이 필요할 때 버퍼에 있게 될 가능성을 증가시킬 수 있습니다.

• 작은 트랜잭션에 대해서는 8 KB, 16 KB, 32 KB, 64 KB 중에서, 큰 트랜잭션에 대해서는 128   KB, wrapping을 막기에 충분한 크기로 롤백 세그먼트의 크기를 조정하십시오. (엔트리는 현재의 익스텐트에서 충분한 공간을 찾을 수 없을 때 다음 익스텐트로 넘어가게(wrapping) 됩니다).
  
  
• INITIAL에 대한 값과 동일한 값을 NEXT에 대해 사용하십시오. PCTINCREASE가 0이기 때문에, 다른 모든 익스텐트의 크기는 NEXT와 같게 될 것입니다.
  
  
• 모든 롤백 세그먼트의 크기를 같게 하십시오. 그렇지 않더라도, 어쨌든 시간이 경과할수록,  롤백 세그먼트들의 크기는 같아 질것입니다. 작은 롤백 세그먼트는 큰 트랜잭션에 의해 사용될 때  확장됩니다.
  
  
• MINEXTENTS를 20으로 설정하십시오. 이것은, 롤백 세그먼트가 이동해 가야 할 익스텐트는 여전히 활동 중인 트랜잭션에 의해 사용되어지고 있기 때문에, 롤백 세그먼트는 다른 익스텐트를 획득해야 하는 경우를 줄일 수 있게 합니다.

테이블스페이스 크기
트랜잭션이 사용하고 있는 어떠한 롤백 세그먼트라도 확장할 수 있도록 평소보다 큰 트랜잭션을 위해 롤백 세그먼트 테이블스페이스에 충분한 여유 공간을 남겨 놓으십시오. OPTIMAL을 설정하면, 롤백 세그먼트는 나중에 줄어 들 것입니다.

트랜잭션 문장
롤백이 수행되는 경우에 필요한 정보를 저장하는 데 요구되는 바이트 수는 수행되고 있는 트랜잭션의 종류에 따라 다릅니다:

• 삭제 작업은 롤백 세그먼트의 경비가 많이 듭니다. 삭제 시, 실제 행 자체를 저장할 필요가 있기 때문입니다. 대신 TRUNCATE를 사용할 수 있다면, 성능이 향상될 것입니다.
  
  
• 삽입 작업에는 롤백 공간이 거의 사용되지 않습니다. ROWID만이 유지되기 때문입니다.
  
  
• 갱신 작업에 사용된 양은 갱신되고 있는 열 수에 따라 다릅니다.
  
  
• 인덱스된 값에 대해서는 서버 프로세스가 테이블 값은 물론 인덱스 값도 변경해야 하기 때문에, 더 많은 롤백이 생성됩니다. 인덱스된 열에서 갱신 작업 시, 오라클 서버는 이전 데이터 값, 이전 인덱스 값, 새로운 인덱스 값을 롤백 세그먼트에 기록합니다.

주의: LOB 데이터 유형의 열은 변경 작업 시 롤백 세그먼트 공간을 사용하지 않고, PCTVERSION 절의 설정 값에 의해 정의된 고유 세그먼트 공간을 사용합니다. 따라서, 실제 데이터가 처리됩니다.

트랜잭션 롤백 데이터 양 조정
가장 길 것으로 예상되는 트랜잭션을 실행시키고 롤백 세그먼트의 크기를 검사하여 롤백 세그먼트의 크기를 점검하십시오. 현재의 트랜잭션에 대해서, 롤백 세그먼트에서 사용된 블록의 수를 질의하십시오.
 SQL> SELECT s.username, t.used_ublk, t.start_time
   2  FROM v$transaction t, v$session s
   3  WHERE t.addr = s.taddr;

 USERNAME               USED_UBLK   START_TIME
 ------------------   -----------   ------------------
 system                      1075   04/01/98 07:07:14

트랜잭션 롤백 데이터 양 조정
테스트 트랜잭션에 대한 롤백 세그먼트의 양을 산정하는 또 다른 방법은 다음과 같습니다:

1. 테스트 트랜잭션을 실행하기 전에, 롤백 세그먼트의 현재의 쓰기 횟수를 출력하십시오:
   
    SQL> select usn, writes from v$rollstat;
   
      USN          WRITES
    ---------- ----------
             0       1962
             1    1102628
             2      32538
             3    1226096
   
   
2. 테스트 트랜잭션을 실행시키십시오.
   
    SQL> update scott.s_emp set salary=1000;
    6560 rows updated.
    
3. 롤백 세그먼트의 새로운 쓰기 횟수를 출력하십시오.
   
    SQL> select usn, writes from v$rollstat;
   
          USN      WRITES
    ---------  ----------
            0        1962
            1     2232270
            2       32538
            3     1226096
   
   이 테스트 트랜잭션에 사용된 롤백 데이터의 양을 알기 위해서는, 롤백 세그먼트 USN 1의 새로운 쓰기 횟수와 이전의 쓰기 횟수와의 차이를 계산하십시오. 

임포트

• COMMIT = Y로 설정하여, 임포트가 수행될 때 삽입된 각 행의 세트가 커밋되는지 확인하십시오.
  
  
• BUFFER 키워드를 사용하여 행 세트의 크기를 조정하십시오.

익스포트
CONSISTENT = N으로 설정하면 Read Only 트랜잭션으로 트랜잭션을 설정하는 것을 막을 수 있기 때문에, 너무 많은 롤백 세그먼트 공간이 사용되는 것을 막을 수 있습니다.

SQL *Loader
Conventional path loading에 대해, ROWS 키워드를 사용하여 COMMIT 간격을 설정하십시오.

큰 트랜잭션
트랜잭션이 다음과 같이 예외적으로 클 경우, 롤백 세그먼트가 확장될 가능성이 없기 때문에 트랜잭션은 실패할 것입니다.

• 롤백 세그먼트가 MAXENTENTS에 이르렀을 경우
  
  
• 롤백 세그먼트가 확장할 때 테이블스페이스에 여유 공간이 없을 경우

이러한 경우, 더 큰 롤백 세그먼트나 더 많은 테이블스페이스 공간이 필요합니다.

스냅샷이 너무 오래 되었을 경우
질의가 실패하고 다음의 오류 메시지가 나타나면, 읽기 일관성에 필요한 롤백 이미지가 활동 중인 트랜잭션에 의해 겹쳐 쓰여졌을 것입니다:

    ORA-01555: snapshot too old (rollback segment too small)

때때로, 다른 트랜잭션이 활동을 하고 있지 않더라도 이 오류 메시지를 보게 될 것입니다.

이러한 오류를 해결하기 위해서는, 더 큰 롤백 세그먼트가 필요하거나 더 많은 롤백 세그먼트가 필요합니다.

• Database를 튜닝하려고 report.txt를 생성해서 조회해 보니 "TRANS_TBL_WAITS" 컬럼의 값이 0보다 크다고 나타났다. 이에 대한 튜닝은 어떻게 해야 하는가?
  A. redo log buffer에 대한 경합이 발생했으므로 log_buffer의 크기를 늘린다.
  B. Rollback segment header block에 대해 contention이 발생하였으므로, rollback segment를 추가해야 한다.
  C. sort_area크기가 적다는 의미이므로 sort_area_size를 늘린다.
  D. 버퍼캐쉬가 적다는 의미이므로 db_block_buffers를 늘린다.
  답

• ROLLBACK SEGMENT HEADER경합에 대한 V$ROLLSTAT 의 WAIT/GETS 의 적절한 RATIO는 ?
  
  A. 1% 이하
  B. 5% 이하
  C. 10% 이하
  D. 15% 이하
  답

• Rollback Segment생성시 지정된 Optimal Parameter에 의해 자동으로 크기가 재조정된 회수를 보고자 하는 경우 조회하는 동적성능뷰는?
  A. V$ROLLSTAT
  B. V$WAITSTAT
  C. V$SYSSTAT
  D. V$SESSTAT
  답

• Rollback segment에 대한 설명으로 적절하지 못한 것은?
  A. Transaction이 rollbaack segment를 사용할때 rollback segment에 대한 wait가 발생하는 않도록 해야 한다.
  B. 정상적인 실행시에는 rollback segment가 확장되어서는 안된다.
  C. Query를 수행하는 경우 원하는 데이타에 대해서는 언제 read consistent 데이타를 조회할 수 있다.
  D. Update 많이 발생하는 transaction은 rollback segment의 생성데이타가 적다.
  답

• SET TRANSACTION USE ROLLBACK SEGMENT COMMAND는 어느 경우에
  사용하는가?
  
  A. VERY LARGE BATCH JOB
  B. ROLLBACK SEGMENT 가 저장된 TABLESPACE 의 SPACE 가 부족할 때
  C. ROLLBACK SEGMENT의 개수가 너무 작을 때
  답

• V$WAITSTAT에서 Undo Header 컬럼값이 115이다. 이것은 의미하는 것은 무엇인가?
  A. rollback segment header에 대한 contention이 발생했다는 것을 의미한다.
  B. redo log buffer에 대한 contention이 발생했다는 것을 의미한다.
  C. datafile에 대한 contention이 발생했다는 것을 의미한다.
  D. 버퍼캐쉬에 대한 contention이 발생했다는 것을 의미한다.
  답

• report.txt 파일에서 undo segment, trans_tbl_gets,trans_tbl_waits에 대한 정보를 보고 monitor할 수 있는 사항은?
  A. rollback segment에 대한 contention
  B. block transaction slot에 대한 contention
  C. shared pool에 대한 contention
  D. dispatcher에 대한 contention
  답

• rollback segment의 defalut MINEXTENTS는?
  A. 1
  B. 2
  C. 3
  D. 20
  답

• 다음 중 ROLLBACK정보를 덜 발생시키도록 하기 위해 취하는 조치 중 적당하지 않은 것을 고르시오.
  
  A. 사용자들이 정기적으로 commit
  B. SQL*Loader로 direct path loading시에 ROWS option으로 COMMIT을 set
  C. Import할 때 buffer_size와 commit=y option을 설정한다.
  D. rollback segment를 drop하고 다시 만든다.
  답