Hyowon's Archive

ABAP Dictionary란?

 ABAP 프로그램에서 사용되는 오브젝트들을 뜻한다. 데이터 구조를 정의하고 관리하는 역할을 한다. ABAP Dictionary는 ABAP Workbench와 연결되어 있어 오브젝트 변경 시 바로 ABAP Program과 Screen에 영향을 미친다. 통상적으로 다음과 같은 3가지로 ABAP Dictionary를 분류한다.

1.Database Object : Table, View

2. Type Definition : Structure, Data Element, Table Type

3. Tool : Search Help, Lock Object

1. Database Object

 Table은 실제 물리적인 공간으로 데이터베이스의 테이블을 구성한다. View는 하나 이상의 Table이 논리적으로 결합한 구조로서 실제 데이터를 가지는 것은 아니고 Table의 조합을 조건에 맞게 조회하고 수정할 수 있다.(일반적인 RDBMS와 달리 View가 수정가능하다.)

1.1 Table

 테이블은 실제 데이터베이스의 물리적인 테이블과 ABAP Dictionary의 테이블이 존재한다. 위 그림과 같이 ABAP Dictionary에서 생성된 테이블은 SAP DB Utility가 번역하여 데이터베이스 테이블로 생성하게 된다.

 ABAP Table은 3가지가 존재한다. Transparent Table, Pooled Table, Cluster Table이다. Pooled/Cluster Table은 여러 개의 테이블을 하나로 그룹 지어 놓은 오브젝트이다. 기본적으로 Transparent Table을 사용한다.

 테이블 기본 속성은 DD02L에 저장되고 테이블 필드에 대한 정보는 DD03L에 저장된다.

 유지보수를 허용하면 SM30에서 데이터를 유지보수할 수 있다.

필드 속성 정의

 Data Element와 Predefined Type 두 가지 방식을 이용하여 지정할 수 있다. Data Element는 사용자가 직접 생성할  수 있는 오브젝트이다. 이미 존재하는 Data Element를 입력하면 데이터 타입과 길이와 내역이 자동으로 지정된다. Predefined Type을 이용하면 데이터 타입, 필드 길이, 내역을 직접 입력할 수 있다.

 테이블의 필드는 데이터를 유일하게 구분할 수 있는 Key Field와 이외의 내용을 저장하는 Generic Field로 구성되어 있다.

1. Key Field는 총 16개까지 가능하다.

2. Key Field의 길이는 모두 합해서 최대 120자까지 가능하다.

3. Key Field는 Initial Value가 기본적으로 선택된다.

4. Key Field로 선택된 필드는 Primary Index로 자동 생성된다. 

 Null과 Initial Value의 차이

- Null은 값이 없는 것이다. 그러므로 메모리 공간을 차지하지 않는다. Null은 0, '', ' ', SPACE, 공백으로 표현될 수 없다. NULL은 할당. 연산. 비교할 수 없는 대상이다. ABAP언어에는 IS NULL, IS NOT NULL을 SQL 구문에서 사용할 수 있다.

- Initial Value는 값이 존재한다. 그러므로 메모리 공간을 차지한다. 0, '', ' ', SPACE, 공백 값으로 표현될 수 있다. Initial Value는 할당, 연산, 비교할 수 있는 대상이다. ABAP 언어네느 IS INITIAL, IS NOT INITIAL 비교연산자를 소스코드에 사용할 수 있다.

Reference Field와 Reference Table

 수량 표현 데이터 타입 QUAN과 화폐량 표현 데이터 타입 CURR은 단위를 정의하는 참조 필드를 지정해야 한다. QUAN은 UNIT, CURR은 CUKY를 지정해야 한다. (밑의 예시 참조)

 실제 데이터는 10.00으로 입력되어 있고 통화는 KRW를 쓴다면 소수점 두자리가 올라와 1000으로 표시된다.

Foreign Key

 ABAP 영역에서 사용하는 Foreign Key는 ABAP Dictionary에만 저장되어 있으면 실제 DB에는 존재하지 않는다. 개념은 일반 RDBMS의 Foreign Key와 기본적으로 같다.

- Check Field : Foreign Key 필드에 입력되는 값이 존재하는지 체크하는 테이블의 필드를 말한다.

- Check Table에서 체크할 필요가 없는 필드를 Generic Foreign Key로 정의하면 된다. Constant Foreign Key를 설정하고 값을 입력하면 그 값을 가진 테이블의 row에서만 Foreign Key 값을 찾아서 입력할 수 있다. 가독성이 안 좋아 많이 사용하진 않을 것 같음..

Include Structure

 공통으로 사용되는 필드들을 Structure로 생성하고 테이블에 Include하여 사용한다. 9단계 depth까지 가능하다.

Append Structure

 하나의 테이블 또는 구조체에만 할당할 수 있는 구조체로서 테이블 자체를 수정하지 않고 필드를 추가할 수 있게 해준다. SAP입장에서는 이렇게 추가된 필드들을 Customer Field라고 한다.

Append Structure의 역할

1. Standard 또는 CBO 테이블에 신규 필드를 추가한다.

2. 이미 존재하는 테이블에 Foreign Key를 추가 및 정의한다.

3. 이미 존재하는 테이블에 필드의 탐색 도움말을 추가한다.

Index

 SAP 내부에 인덱스 오브젝트는 없고 데이터베이스에 인덱스가 생성되고 ABAP Dictionary를 통해 사용하게 된다.

*ST05에서 실행계획 분석 가능

- 데이터의 입력/수정/삭제가 빈번하면 인덱스의 공간이 비대해져 성능이 떨어진다. 주기적으로 Rebuild를 통해 인덱스를 재정리할 수 있다. SAP에서는 Reorg라는 용어를 사용하고 BC가 OS에서 br*tools라는 SAP DB툴을 이용해서 주기적으로 Reorg를 수행하여 성능을 높힌다.

1.2 View

 여러 테이블에 존재하는 데이터를 통합하여 조회하도록 지원한다. ABAP Dictionary에서 View를 활성화하면 데이터베이스에 생성된다. Maintenance Status는 View를 통해서 읽기 속성만 부여할 것인지 쓰기도 가능하게 할 것인지를 정의한다. 만약 Database view가 2개 이상의 테이블로 구성되어 있다면 이 View를 통해서는 읽기 작업만 할 수 있다.

View의 종류

- Database View : 여러 개의 테이블에서 데이터들을 추출한 View. SQL문에서 사용가능.

- Projection View

- Help View

- Maintenance View : 여러 개의 테이블을 동시에 유지보수할 수 있는 View를 의미하고 이 때 테이블들은 Foreign Key로 연결되어 있어야 한다. 프로그램 안의 SQL문에 사용불가능

2. Type Definition

2.1 Structure

구조체는 구조만 가지고 있다. ABAP 프로그램에서 참조로 사용되거나 테이블 또는 다른 구조체의 구조로 포함된다.(ICLUDE, APPEND). 프로그램에서 WORK AREA처럼 사용하기도 한다. Module Pool 화면(Screen)의 인터페이스를 정의하고 Function Module에서 파라미터  타입으로도 지정될 수 있다. 

2.1 Table Type

 Table Type은 ABAP Dictionary에 존재하며 인터널 테이블의 속성을 정의하는 목적으로 사용된다.

Table Type의 특성

- 인터널 테이블 라인의 데이터 타입 속성과 구조체를 정의하기 위한 Line Type.

- 인터널 테이블 데이터에 접근하고 관리하기 위한 옵션(Access Mode)

- 인터널 테이블의 Key(Key definition과 Key category)

RANGE Table Type

특별한 Table Type으로 ABAP 프로그램에서 RANGE 변수로 사용된다. 4개의 변수로 고정된 필드를 가진다. SIGN, OPTION, LOW, HIGH

RANGE 변수란?

- 개별 프로그램 내에서 RANGES 구문으로 변수를 선언하여 사용할 수 있다. RANGES 변수의 구조는 Header Line이 존재하는 SELECT-OPTIONS와 같은 구조이다. 외부에서 값을 입력받을 수 있는 것이 SELECT-OPTIONS라면 RANGES는 내부 변수로 사용하는 것을 주 목적으로 한다. 

2.2 Domain

000050000300000001.판매오더 - 출하문서 - 자재문서, 대금청구문서 - 재무회계문서, 관리회계문서

위 프로세스에서 마주치는 용어들 정리글

영어(한글) 

- 설명

Sales Order(판매오더) - Header

sales document(영업문서)

- 영업 부서의 비즈니스 트랜잭션 문서들을 뜻함. 고객이 요구한 재화(Goods)나 서비스(Services)에 관련된 데이터를 다룸

- Inquiry(문의), Quotation(견적), Sales Order(판매오더), Outline agreement(계약과 스케줄링), Complaints(반품, 차변 메모, 대변 메모 등)의 종류가 있다.

Net Value(정가)

- 품목(item)들 가격의 총합으로 할인이나 추가금을 고려한 금액으로 SD Document Currency로 표시된다.

SD Document Currency

- 해당 SD문서에 적용되는 통화로 시스템이 Sold-To-Party(판매처)의 customer master record에 있는 정보를 기초로 자동설정한다.

Sold-to-party(판매처)

- 재화나 서비스를 주문한 고객. 계약에 책임이 있는 고객

Ship-to-party(납품처)

- 재화를 받는 고객. 판매처와 다를 수 있음

PO Number

- Inquiry나 Purchase Order 문서 번호를 적어서  판매오더와 연결한다.

- PO번호를 적으면 고객에게 보내는 Delivery Note(출하문서)에 해당 정보를 포함할 수 있다.

Requested delivery date of the document(납품요청일)

- 고객이 재화를 인수할 날짜. 포맷 지정가능(date, day, week, month 등)

- 고객이 요청한 날짜일수도 있고 현재 날짜일 수도 있다. 자동으로 시스템이 한다. 자동으로 설정되는 날짜는 판매오더의 헤더 정보를 컨트롤하는 테이블을 이용해 설정할 수 있다.

- 헤더에 있는 납품요청일을 수정해도 이미 스케줄링 처리가 된 아이템들의 delivery date에 영향을 주지 않는다. 새 납품요청일로 아이템의 일정을 바꾸고 싶다면 Edit -> Fast Change -> Delivery Date 메뉴를 이용한다.

- 납품요청일을 week나 month 형식으로 지정하면, 시스템이 자동으로 공장 달력(factory calender)를 확인하여 첫 번째로 유효한 working day를 납품요청일로 지정할 것이다.

sales documentComplete delivery defined for each sales order?(일괄납품)

- 이 판매 오더가 한 번의 납품(delivery)으로 처리되어야 하는 지 부분적으로 나눠서 납품되거나 다른 납품에 포함되어서 처리될 수 있는지 설정한다.

Deliverying plant(납품 플랜트)

- 재화가 빠져나갈 플랜트. 이 항목을 입력하면 품목 데이터에 default value가 없다면 자동으로 해당 플랜트가 입력된다.

- 기본적으로 품목의 납품 플랜트는 GR의 customer master record나 material master record에서 가져온다.

Total weight(총 중량)

- 시스템이 자동으로 아이템의 gross weight를 합쳐서 입력한다.

Volume

- 아이템들의 볼륨 총합

Delivery block(납품 보류)

- 이 판매오더 전체가 납품 보류상태로 된다. 

- Sales Document 유형에 따라 이 값을 제안한다.

- 헤더가 아닌 아이템별로 설정할 수도 있다.

- TVLSP 테이블에서 문서 유형별로 설정가능한 보류 상태 값이 등록되어 있다. 다만 스케줄 라인 레벨에서는 항상 납품 보류가 가능하다.

- 특정 문서 유형에 납품 보류를 기본값으로 설정하는 상황의 예시에는 무상판매와 같은 경우 출하가 일어나기 전에 담당자나 책임자가 확인한 후 납품 보류를 해제하는 프로세스가 필요할 때 사용할 수 있다.

- 신용 체크 기능(credit limit check)을 사용하고 있다면, 시스템이 자동으로 납품 보류를 설정할 수 있다. 수기로 바꿀 수 있지만 다른 SD문서의 값을 바꾼다면 시스템이 다시 신용체크기능을 다시 적용해 납품 보류 설정으로 바꿀 수 있으니 주의할 것.

Billing Block(대금청구보류)

- 판매 문서 유형에 따라 대금청구 보류를 설정할 수 있다.

- 아이템 레벨에서도 아이템 별로 설정가능하다.

- 대금청구문서가 생기기전에 가격을 한 번 더 확인하도록 할 때 이 기능을 사용할 수 있을 것이다.

Pricing Date(가격결정일)

- 가격과 환율 같은 일자 기반 가격 결정 요소를 결정하기 위한 일자.

- 대금청구문서를 집합적으로(collectively) 처리할 때 선택 기준이 되는 일자들 중 하나이다.

- 시스템은 기본적으로 현재날짜를 제안하며 수기로 수정할 수 있다.

- 과거일자로 적는다면 경고 메시지가 뜬다.

- 커스터마이징을 통해 default value를 설정할 수 있다. 예를 들면 납품요청일을 가격결정일로 자동 지정하는 것이 있다.

- 대금 청구 문서에서는 시스템이 판매오더의 가격결정일을 대금청구일자로 제안한다.

Payment card(지급 카드), Expriation date(만료일), Card Verification Value(카드 검증 코드)

- 카드와 카드의 만료일, CVV 코드

Payment terms(지급 조건)

- 현금 할인 퍼센트나 지급 기간 등에 관한 결제 조건.

- invoice due date나 discount rate 등에 대한 지급 조건을 정한다.

- 대금청구문서 자동 생성 시 이 조건에 따라 할인을 하거나 추가금을 요구할 수 있을 것이다.

Incoterms(인도 조건) - part1, part2

- part1은 International Chamber of Commerce(ICC)에 의해 정립된 기준에 일치하는 주로 사용되는 거래 조건을 말한다.

- 예를들어 FOB Boston : Free On Board조건으로 Boston에서 출하하는 재화

- part2는 추가적인 정보이다,

- part1이 FOB라면 두번 째 필드는 선적지와 같은 항구 정보를 기입할 수 있다.

Order reason(오더 사유)

- SD문서를 만드는 이유 설정. 매출 관련 통계를 낼 때 기준 중 하나로 사용할 수 있다. 조직의 관점에서 자유롭게 커스터마이징 하면 된다.

- 스탠다드에서는 대변 메모나 차변 메모는 반드시 이 오더 이유를 설정해야 한다.

- 특정 이벤트로부터 생긴 판매오더임을 구분하기 위해 오더 사유를 해당 이벤트 이름으로 만들어 지정하면 추후 해당 이벤트의 효과가 얼만큼 매출을 일으켰는 지 파악하는 통계를 작성할 수 있게 된다.

Sales Area(판매 영역)

- Grouping of sales organization, distribution channel and division.

Sales Organization(판매 조직)

- 특정 재화와 서비스의 판매에 책임이 있는 조직 단위. 법적인 책임이나 고객의 요구나 불만에 대한 책임을 지는 것을 기준으로 나눌 수 있다.

- 유통 채널과 제품군을 영역 조직에 할당한다. 이 3가지의 조합이 판매 영역이다.

Distribution Channel(유통 채널)

- 도매, 소매, 직판 등의 유통 채널을 구분하는 값. 내수, 수출 등을 구분할 수도 있다.

Division(제품군)

- 재화나 서비스를 그룹핑하는 방법 중 하나.

- 자재나 서비스에 대한 Sales area나 Bisiness area를 결정하기 위해 사용된다.

- 제품군을 나눔으로써 각 제품군 담당자들을 위한 관리가능 영역을 설정하는 효과가 생긴다. 예를 들면 식품판매 제품군을 아이스크림과 음료수 매출 관리 담당자가 다르다면 제품군을 통해 각각의 관리 영역을 구분해 줄 수 있을 것이다.

Sales Order(판매오더) - Item - Sales Tab

Order Quantity(오더 수량)

- total 혹은 rounded(반올림) 수량

- 이 아이템에 대한 스케줄 라인이 하나 보다 많으면 총 오더 수량은 스케줄 라인의 rounded quantity 합으로 나타내어 진다.

Denominator(Divisor) for Conversion of Sales Qty into SKU

- 판매 수량을 SKU로 변환하기 위한 분모

- SKU : Stock Keeping Unit, 재고관리 최소 단위를 의미한다.

Numerator (factor) for conversion of sales quantity into SKU

- 판매 수량을 SKU로 변환하기 위한 분자

- 100 bt(분모) <=> 1 ca(분자) 라고 한다면 bt는 sales unit을 의미하고 ca는 같은 양으로 치환한 base unit of measure이다.(자재의 기본 관리 단위), 판매는 bt단위로 하고 다른 재고관리(생산, 구매, 품질검사 등)의 단위는 ca인 경우 사용하는 기능이다.

First Delivery Date 

- Delivery Date(납품일)은 고객이 요구한 날이거나 시스템이 자동적으로 가용성 점검과 출하 스케줄링(delivery scheduling)을 통해 제안된 날짜 중 가장 이른 날이 될 수 있다.

- 시스템은 미리 정의된 Delivery activities(picking이나 packing등)의 시간 추정치를 감안하여 Material Availablity Date(사용 가능일), Loading date(적하일), Goods issude date(출고일), transportation planning date(운송계획일) 등을 결정짓는다.

- 자동적으로 위의 날짜들을 계산하게 하려면 영업 문서를 정의하는 IMG 설정에서 Delivery Scheduling과 Transportation scehduling 필드를 활성화 시켜야 한다.

경로 - Tools --> Customizing, Sales and Distribution --> Basic Functions --> Delivery scheduling and transportation scheduling --> Define scheduling by sales document type

- 스케줄 라인이 여러 개면 시스템은 가장 이른 납품일을 보여준다.

Delivery Time(납품시간)

- 계약이나 견적에서 고객과 합의한 납품 시간

Net Value(정가)

- 문서 통화로 표현된 세금을 제외한 아이템의 정가

International Article Number (EAN/UPC)

- 국제물품번호

Customer Engineering Change Status(고객설계변경상태)

- 설계 변경 요청 상태 번호. 

- 고객이 요구한 설계 변경 번호를 적는 곳. PP와 관련있음

BOM explosion number(BOM 전개 번호)

- 부품 공급업체가 고객이 물품을 출하하고 수령하는 제품의 생산 시리즈를 식별하는 데 사용하는 번호

Usage Indicator(용도 지시자)

- 자재가 어떻게 쓰이는 지 정의. 견본, 교체, 사은품 등

- 같은 자재가 다른 용도로 같은 고객에게 판매될 때 구분할 수 있는 지시자가 된다.

Business Transaction Type for Foreign Trade(해외무역 거래유형)

- SAP에서 Business Transaction Type for Foreign Trade는 무역에 대한 비즈니스 트랜잭션 유형.

- 이는 세관 절차를 식별하는 표준 코드로, 이를 통해 발송/수출 트랜잭션의 해외 무역 통계를 보고합니다

Reason for rejection of quotations and sales orders(견적 및 판매 오더의 거부 사유)

- SD문서의 거부사유를 설정함으로써 후속문서 생성을 막는다.

- Inquiry나 Quotation : 다른 문서의 참조로 쓰이지 못한다.

- Sales Order : 품목의 출하 X

- Contracts : 더 이이상 계약 생성할 수 없다.

- 이 필드에 값을 입력하면 시스템이 자동적으로 MRP를 취소한다.

Sales Document Item Category(영업 문서 품목 범주)

- 아이템의 타입들을 구분하기 위한 분류. 무상품목이나 텍스트품목(고객에게 전달한 메뉴얼이나 내부적으로 사용할 메모 등)

- 무상품목의 경우 시스템이 가격 결정 절차를 생략하도록 지정할 수 있다.

Pricing Reference Material(가격결정 참조 자재)

- 가격 결정에 참조한 자재 코드

Product Hierarchy(제품 계층 구조)

- 다양한 특징들을 묶어서 자재를 그룹화하기 위한 코드

- R/3 시스템에서는 3레벨의 계층구조를 가질 수 있다.

- 1레벨 - 5자리, 2레벨-5자리, 3레벨-8자리

- 이 경우 제품계층구조는 000050000300000001가 된다.

Material Group(자재그룹)

- 몇 가지 특징을 공유하는 자재들을 그룹화할 수 있다.

- 분석 범위(scope of analyese)를 제한하는 데 사용할 수 있다.

- 자재를 검색할 때 사용할 수 있다.

Material group hierarchy 1, 2(자재 그룹 계층 구조)

- 자재 그룹의 그룹을 특정하는 키

Division(제품군)

- 재화와 서비스를 그룹핑하는 방식

- sales area와 business area를 결정하는 데 사용된다.

- SD관점에서는 제품군을 통해 영업 조직에서 특정 제품군의 오더와 서비스를 담당하는 사람이 전문적인 관리영역을 가지도록 특화할 수 있다.(제품군 A는 담당자 A`가 맡는다는 식으로)

Material Pricing Group(자재 가격 결정 그룹)

- 같은 조건을 적용하고 싶은 자재들을 그룹화하는 방식

- 자재 가격 결정 그룹에 대해 조건 레코드를 생성하여 사용할 수 있다.

- 자재 가격 결정 그룹만 사용하는 방식, 고객과 자재 가격 결정 그룹을 사용하는 방식, 가격 그룹과 자재 그룹을 이용한 방식 등으로 조건 레코드를 생성할 수 있다.

Customer Group(고객 그룹)

- 도매/소매 등의 기준으로 나눠진 고객 그룹을 식별한다.

- 가격 결정이나 통계 작성 목적으로 사용될 수 있다.

- 기본적으로 고객 마스터 레코드에서 이 값을 가져오지만 수기로 조정할 수 있다.

Price group(가격 그룹)

- 같은 가격 결정 요구사항을 가진 고객들의 그룹

- 고객 그룹과 마찬가지로 SAP를 사용하는 조직의 니즈에 맞춰 설정하여 사용한다.

- 같은 할인률을 적용하고 싶을 때 사용할 수 있다.

- 고객 마스터 레코드에서 이 값을 가져오지만 역시 수기로 조정할 수 있다.

Price list type(가격 리스트)

- 가격 리스트나 다른 조건 타입(추가금이나 할인금 등)을 식별한다.

- 가격 결정이나 통계를 사용하는데 사용할 수 있다. 조직의 니즈에 맞춰서 세팅하면 된다.

- 고객 마스터 레코드에서 이 값을 가져오지만 역시 수기로 조정 가능하다.

Sales district(판매 구역)

- 지리적으로 나누는 판매 구역

- 조건을 다르게 지정하는 데 사용할 수도 있고 통계를 만드는 기준이 될 수도 있다.

- 역시 고객 마스터에 있지만 수정가능하다.

Sales Order(판매오더) - Item - Shipping Tab

unloading point(하적 지점)

- 자재가 하적하는 지점(화물을 내리는 지점)

Receiving point(입고 지점)

- 주소나 unloading point에 가까운 장소. 각 플랜트마다 여러 입고 지점이 지정될 수 있다.

- 또한 입고 지점은 개별 부서에 할당될 수도 있다.

- 출하문서에 출력되도록 할 수 있다.

Department(부서)

- 연락할 사람이 속한 부서

Delivery Priority(납품 우선순위)

- 품목에 지정된 납품 우선순위

- 특정 자재나 고객/자재 조합에 우선순위를 부여할 수 있다. 집합적으로 납품을 처리할 때 우선순위를 통해 기준을 삼을 수 있다.

- 고객 마스터와 고객/자재 정보 레코드에 있다. 둘 다 값이 존재하면 고객.자제 정보 레코드에서 값을 가져오게 되어 있다.

plant(플랜트)

- plant를 특정한다.

storage location(저장 위치)

- 재고가 저장된 저장 위치를 특정한다.

Shipping point(출하 지점)

- 품목을 출하할 물리적인 위치

- plant, shipping condition, loading group 등의 값을 통해 미리 shipping point와 receiving point를 시스템에 지정해놓을 수 있다.

- 출하 처리를 진행하면서 입고 지점과 출하 지점은 출하를 선택하는 데 중요한 기준이 된다.

- 하나의 납품(출하)은 한 출하 지점에서 혹은 한 한 입고 지점에서 이루어진다.

- 출하 지점에 대한 더 상세한 정보를 제공하고 싶다면 loading point를 특정하면 된다.

- user-speicific하게 출하 지점을 정할 수도 있다(유저 파라미터 VST로 설정).

Partial delivery at item level(품목레벨에서의 분할 납품)

- 고객이 분할 납품을 원하는 지 일괄납품을 원하는 지 설정한다.

- 고객이 분할 납품을 허용한다면 다양한 분할 납품 옵션을 사용할 수 있다.

- 고객 마스터 레코드에 이 값을 가지고 있다.

Route(운송 경로)

- 어떤 경로로 고객에게 자재가 납품되는 지 정할 수 있다.

- 운송 경로를 여러 용도로 사용할 수 있다. 실제 지리적 경로를 나타내거나, 출발지점과 도착지점의 연결을 나타내는 용도로 사용하거나 목표 지점을 나타내는 용도 등으로 사용 가능하다.

- 집합적으로 납품 처리를 하거나 운송 계획에 대한 납품들을 선택할 때 기준으로 사용할 수 있다.

Maximum Number of Partial Deliveries Allowed Per Item(최대 분할 납품 횟수)

- 고객 마스터 레코드에 있으며 고객이 허용하는 최대 분할 납품 횟수를 나타낸다.

Material freight group(자재 운임 그룹)

- 자재들을 묶어 운임 코드나 클래스에 할당하는 코드

- 운임을 결정하는데 사용된다.

- 자재 마스터에 있다.

Order combination indicator(오더 조합 지시자)

- 오더들을 조합할 수 있는지 여부를 체크한다.

- 고객 마스터 레코드에서 값을 가져오며 수기로 값을 변경할 수 있다.

Means-of-Transport type(운송수단 유형)

- 재화가 어떻게 운송되는지를 결정하는 키

- 운송 수단을 결정한다. 

- 트럭, 팔레트, 컨테이너, 배 등 재화를 두는 곳을 뜻하거나 운송을 하는 수단을 뜻한다.

Shipping Type(출하 유형)

- 트럭, 메일, 철도, 바다 등 운송과 관련한 값

- leg determination(운송 경로 결정)에 따라 경로들이 출하 유형에 할당된다.

- leg determination이라는 물류 모듈에서 중요한 절차와 관련이 있다.

Means of Transport(운송 수단)

- 운송 수단 카테고리의 포장 자재에 해당 하는 자재를 입력한다.

Special processing indicator(특별처리 지시자)

- 운송이나 운송 비용에 대해 특별한 취급이 필요한 경우 선택한다

- 예를 들면, 특급 배송이나 특별 관세 등의 처리가 필요한 경우

Relevant for POD processing(POD 관련)

- proof of delivery (POD)  공급망 및 물류 업무에서 주문 또는 배송이 정확하게 이루어졌는지를 증명하는 문서

- 고객 마스터 레코드에 있다.

Net Weight 

- 총 중량

Gross Weight

- 포장 무게를 제외한 중량

Volume

- 부피

overdelivery, underdelivery tolerance limit(초과,미달 납품 한도)

- 납품이 초과 혹은 미달이 얼만큼 나도 허용가능한지 적는 곳.(고객 마스터 레코드에 있음)

원가중심점 회계

마스터데이터

- 원가요소(Cost Element) : 원가계정을 뜻한다.

- 1차 원가(primary cost) : 각 모듈에서 1차적으로 발생하여 관리회계 모듈로 흘러들어온 원가요소. 재무회계모듈의 계정과목표의 비용계정과 일치한다.

- 2차 원가(secondary cost) : 1차 원가를 집계하고 이를 다른 원가대상(cost object)으로 배분하는 원가. 관리회계 모듈 자체에서 사용되는 계정. FI모듈의 계정과목표의 계정과는 무관하다.

- 원가대상(cost object) : 집계된 원가요소를 배분하는 장소

Cost Center(원가중심점)

- 원가를 집계하는 최소 단위. 모든 1차원가가 발생할 때 반드시 발생장소인 Cost Center를 대부분 기록하게 되어 있다. 때로 Internal Order(내부오더)를 사용하는 경우도 있음

- basic view에는 cost center가 속한 profit center, company code, business area, functional area, department 등이 있다.

- 기업의 부가가치를 창출하는 활동(activity)을 제공하는 곳이 cost center.

- 활동 타입(activity type)은 이러한 활동들을 분류한 것이다.

- Cost Center는 Cost Center가 제공하는 Activity Type이 있고 이를 기준으로 Cost Center에 발생된 원가를 배분한다. 위의 표에서 결국 비용(2차원가)으로 Setup time, Labor time, Machine time에 배분된 것을 볼 수 있다.

제품원가관리

제품원가계획(Production Cost Planning)

- 제품의 원가에 대해 사전에 계획을 수립하는 기능. 제품 생산구조가 이미 수립된 수량구조 기반 원가 추정(cost estimate with quantity structure)을 살펴본다.

- 제품생산구조요소 중 가장 중요한 것은 BOM과 Routing

- BOM은 재료비를 결정하고 Routing은 가공비를 결정한다.

- MM03에서 자재 회계1 view에서 Price Control이 S라면 해당 자재는 표준원가를 채택하고 있다는 것을 의미한다.

- MM03의 MRP2 View에서 Prod.stor.location은 제품이 완성된 후 어떤 저장위치에 입고하는가를 지정한다. 지정되어 있지 않으면 완성 후 입고되지 않는다.

- 자재의 원가추정이 이뤄지는 단계는 다음과 같다. 

1. 자재 마스터 생성

2. 자재에 대한 BOM과 Routing생성

3. 원가추정(Cost Estimate)

Production Order

- 일종의 내부오더로 제품의 생산을 지시하고 그 과정과 결과, 그리고 원가계산정보를 포함한다.

- 생산이 이루어진 후에  Master View의 Analysis를 보면 실제원가와 표준원가 정보를 비교하여 볼 수 있다.

- 생산이 시작되면서 자재출고 시 BOM에 해당하는 자재원가들이 실제원가로 입력된다.

- 활동원가는 routing에 따라 cost center로부터 activity를 제공받아 소비하는 과정에서 발생하는 원가이다.

- Final Confirmation으로 생산 오더를 처리하면 제품생산과정에서 소비된 활동 원가의 처리와 완성품입고까지 진행된다.

- 완성품 입고처리는 MM문서, FI문서, CO문서를 각각 생성하게 된다. 

성과평가회계

- CO-PA(수익성분석), EC-PCA(이익중심점회계) 두 가지가 있다.

수익성 분석 (CO-PA)

수익성 분석 데이터의 원천은 주로 각 모듈로부터 넘어오기 때문에 자체적으로 입력되는 데이터가 거의 없다. Sales Order, FI doc, Order Settlement, billing data 등이다. 각 모듈의 활동을 하면서 PA 전표가 자동적으로 생성되어 CO-PA로 넘어오는 것이다.

- PA 전표의 Origin Data에는 그 PA 전표의 원천을 알 수 있는 정보가 포함되어 있다.(Sales Order 같은)

- PA전표의 Charateristics view에는 PA전표의 타입을 결정짓는 특성 정보들이 포함되어 있다. Sales Order로부터 넘어온 PA전표라면 영업조직과 고객에 대한 정보가 입력되어 있다.

*CO는 다른 모듈의 프로세스를 기본적으로 모두 알고 있어야 이해할 수 있다. 특히 PP를 제대로 이해하고 있어야 한다.

STOCK TRANSFER PROCESS란?

• 같은 회사의 플랜트에서 플랜트로 자재가 이동하는 것을 말한다.
• Stock Transfer로 플랜트간 재고 이송을 하는 것 뿐만 아니라 재고의 타입을 바꿀 수도 있다.
• 품질 재고(품질 검사 대상)에서 가용 재고 혹은 보류 재고 등으로 재고의 타입을 바꿀 수 있다.
• 요청에 따라 한 자재의 재고를 다른 자재코드를 가진 비슷한 자재로 재고 이송을 할 수도 있다.
• 위와 같은 트랜잭션을 일으키는 행위를 Stock Transfer라고 부른다.(재고이송)

재고 이송의 유형

• One step
• Two step
• Stock Tranport Order를 통한 재고 이송
• 회사간 재고 이송(intercompany stock transfer process)

One Step Process

MIGO에서 이동유형 301로 처리하는 것이다

Two Step Process

- MIGO에서 이동유형 303으로 처리 후 이동유형 305로 처리하는 것이다.

Stock Transport Order를 통한 재고 이송

- Stock Transport Purchase Order를 생성하여 처리한다.

- 그 다음 PO에 맞추어 재고가 출하된다.

- 그 다음 MIGO에서 이동유형 101로 Good Receipt 처리한다. 

- STO는 재고를 받는 플랜트에서 생성하고 이에 대응하여 재고를 보내는 플랜트는 shipping과 outbound delivery 문서를 생성한다. 이 outbound delivery 문서가 전기(PGI 자재문서 생성)되면 재고가 빠져나간다. 

- 빠져나간 재고는 in-transit stock(운송중 재고)로 상태가 변경된다. 이후 받는 쪽의 플랜트에서 재고를 받고 GRN(Goods receipt Note)를 생성하면 상태가 다시 변경된다. 

- 재고값은 보내는 플랜트에서 PGI를 할 때 자동으로 이미 갱신되었고 이 자재가 받는 플랜트의 재고로 갱신된다.

- 이후 결과는 T-CODE MMBE나 MB5B에서 확인할 수 있다.

회사 간 재고 이송

- 서로 다른 회사 간 재고 이송이 일어나는 경우, A회사의 A플랜트에서 B회사의 B플랜트로 재고 이송이 일어난다.

- 이 경우 같은 회사의 플랜트 간 STO와 다르게 대금청구 행위가 일어난다. A회사는 Selling/Issuing plant, B는 Purchasing/Receiving plant가 된다.

- B플랜트에서 A플랜트를 vendor로 하는 STO를 생성하고 A플랜트에서 Delivery 문서를 생성하고 PGI 전기를 실행한다.

- 출고되어 이송중인 재고는 in-transit cc(corss company) stock으로 MB5T에서 조회가 가능하다.

- GRN이 생성되면 이송중 재고는 감소하고 가용 재고가 갱신될 것이다. 

- 고객회사인 B에 대하여 A는 대금청구를 하게된다. vendor인 A의 billing document(invoice)는 MIRO에서 다른 vendor의 것들과 같이 처리된다. 회사 간 빌링 처리에 대한 설정은 FI 모듈 쪽에서 한다. 

- 위 과정 처럼 입고를 출고 회사의 outbound delivery 문서가 아닌 입고 회사인 B가 생성한 PO를 기반으로 할 수도 있다. 이건 IMG 설정으로 정할 수 있다. 회사의 업무 프로세스에 맞게 변형하여 사용하면 된다.

- 고객일 때(입고 플랜트) 고객코드로 사용할 고객번호를 정할 수 있다.

- 판매일 때 어떤 영업조직으로 판매를 하는 지 미리 정할 수 있다.

STO 더 자세히

- STO는 PO의 한 타입이다.

- ME21N에서 STO를 생성한다.

- Document Type은 UB이다.

- vendor 필드는 PO 화면의 공급플랜트에 따라 바뀐다.

- STO는 공급 받는 플랜트에서 생성된다. 

- PO의 Item Category는 U( Stock Transfer )가 되고 수정할 수 없다.

- Delivery document를 출고 플랜트에서 VL10B를 이용해 생성한다. 

- VL02N으로 delivery document 내용을 수정할 수 있다. (PGI 처리도 여기서 함)

- PGI는 이 Delivery document를 기반으로 처리된다.  => 이후 VF01에서 빌링 처리도 마찬가지

- Pro-forma invoice(견적 송장)는 Delivery Document를 기반으로 생성되는데 FI와 연계없이 처리된다.(회계전표 안 생긴다)

Pro-forma invoice  : https://hyowonsarchive.tistory.com/62 참고

- 운송 중 재고는 MB5T에서 볼 수 있다.

- MIGO에서 Delivery Document를 이용해 GRN을 처리한다.

- 출고되는 자재의 수량과 가치는 PGI가 실행되면서 감소된다.

- PGI가 실행되면 입고되는 플랜트로 출고된 자재의 가치가 운송 중 재고로  갱신된다.

- 기본적으로 가격(condition)은 IMG 세팅에 따라 여러 결정방식을 가질 수 있다. 예를 들어 자재의 판매가에 storage charge(보관료) 일정 부분 더해서 받을 수도 있는 것이다. 기본적으로 단가를 따른다.

- 출하(shipping)탭에 STO에서 가장 중요한 정보들이 담겨있다.

- 출하지점 1114가 출고되는 플랜트이고 이 1114에 매핑된 영업영역이 오른쪽의 영업조직/유통경로/제품군이라 자동으로 매핑되어 입력된다.

- 납품 유형(Delivery Type) NL이 standard이며 회사 간 거래이면 NLCC(회사간 보충)이 standard이다.

- 회사간 STO는 하나의 자재문서에 회계 전표를 2개 발생시킨다. ( 양 쪽 회사 모두 제품/상품 등을 인도/인수 한 것이라면 매출원가 회계전표와 재고 매입 회계 전표가 생긴다)

- 이후 회사A가 회사B에 대금청구문서를 생성하여 매출채권을 가지게되고 B는 A에 대한 송장 수령 및 매입채무를 가지게 된다.

Enquiry(문의)란 고객이 공급자에게 요구사항과 자재에 대해 묻는 것을 말한다. 

- T-CODE VA11 에서 생성한다.

- ITEM CATEGORY가 AFN 과 같은 문의 품목을 선택한다

- 생성된 문의 문서를 바탕으로 VA01에서 판매오더를 생성할 수 있다. (Create with reference)

Quotation(견적)이란 고객 문의나 이전 기록들을 참고하여 고객의 요구사항을 기록하는 것을 말한다.

- T-CODE VA21 에서 생성한다. 

- 지난 Sales Order, Inquiry, 지난 Quotation 등을 참고하여 생성할 수도 있다.

 이 두가지 기능은 현장에서는 잘 사용되지 않는 것 같다. 현재 내가 일하고 있는 회사도 해당 기능을 사용하지 않고 있다.

그래서 굳이 이 기능들을 어디에 활용할 수 있을 지 생각해보면 

1. 문의가 왔으나 견적까지 못간 것들

2. 견적은 냈으나 오더까지는 못 간 것들

3. 문의-견적-오더까지 진행된 것들

 위 3가지의 경우들을 종합해서 여러 가지 경영 분석을 할 수 있지 않을까 한다. 예를 들어, 고객이 문의했지만 회사가 다루지 않는 상품이나 제품이라 견적조차 못내고 거절한 건 수가 많다면 추가 아이템을 만들 수도 있을 것이고, 견적은 냈지만 오더까지 못간 경우가 많다면 회사의 가격정책이나 제품의 품질, 납기 기간 등에 문제가 없는 지 점검하는 데 바탕이 될 자료로 쓰일 수 있을 것이다.

 이런 자료로 사용하기 위해서는 고객 문의/응대 시스템과 SAP간 연동이 필요할 것이다.

SQL문 분석 with 옵티마이저

SQL과 실행 계획

- SQL은 처리 방법(절차)를 기술하지 않는다.(이렇게 저렇게 해라라는 방법에 대한 기술이 없다)

- 대신 옵티마이저(파서)라고 불리는 기능이 실행 계획(plan)이라는 처리 방법을 생성한다. 이 작업은 서버 프로세스의 SQL문 분석에 해당하는 작업이다.

- 실행 계획은 규칙 기반(rule base)과 비용 기반(cost base)라는 알고리즘을 가지고 생성한다. 하지만 규칙 기반은 더 이상 쓰이지 않아 비용 기반만 고려한다.

- 비용 기반이란 '처리 시간이나 I/O 횟수가 가장 적을 것으로 예상되는 처리 방법이 최상'이라는 알고리즘이다. 

- 이 비용을 계산하기 위해서 여러 통계 정보를 사용한다.

- 비용 계산을 위해 데이터 딕셔너리 뷰의 USER_TAB_STATISTICS와 같은 통계 정보를 이용한다.

실행 계획 수립의 한계와 공유 풀(Shared Pool)

 어떤 처리 방법이 가장 좋은지(비용이 적은지)를 판단하기 위해서는 모든 처리 방법의 비용을 비교해야 한다. 모든 처리 방법을 비교한다는 것은 수 많은 경우의 수에 대한 예상치를 계산해야하기 때문에 그 자체로 비용(자원)이 많이 든다. 즉, 분석에 드는 CPU 자원이 아까워지는 현상이 발생할 것이다. 그럼 이 실행 계획을 공유해서 자원 소비를 줄이는 방법을 자연스럽게 생각하게 된다. Ch3에서 이미 캐시와 공유 메모리에 대해 알아보았다. 이 실행계획도 서버 프로세스들이 서로 공유한다면 실행 계획을 수립하는 데 사용되는 자원을 줄일 수 있다. (*또한, 선정된 실행 계획이 무조건 가장 좋은 계획이 아닐 수 있다. 어디까지나 예상이기 때문이다. SQL 튜닝(인덱스 등을 활용한)을 통해 더 나은 실행 계획을 세우도록 유도할 수 있다.)

 공유 풀(Shared Pool)이라는 공간이 공유 메모리 영역(SGA)에 존재한다. 공유 메모리는 대부분 버퍼 캐시로 사용되고 남은 일부가 공유 풀로 사용되어 그 안에 통계 정보나 실행 계획 등의 캐시 데이터가 저장된다.

 실행 계획 등은 라이브러리 캐시(Libary Cache) 공간에 캐싱된다.

같은 SQL은 같은 실행 계획을 사용한다. 그러면 오라클은 어떻게 같은 SQL을 판단할까?

바인드 변수의 사용

SELECT ID, CUST_NAME, TEL_NO
  FROM CUST_INFO
 WHERE ID = '001'

SELECT ID, CUST_NAME, TEL_NO
  FROM CUST_INFO
 WHERE ID = '002'

-- 위 두 가지 SQL은 오라클이 다른 SQL로 취급한다. 오라클은 SQL문을 하나의 문자열로 간주하기 떄문이다.

SELECT ID, CUST_NAME, TEL_NO
  FROM CUST_INFO
 WHERE ID = :P1

SELECT ID, CUST_NAME, TEL_NO
  FROM CUST_INFO
 WHERE ID = :P1

-- 바인드 변수를 사용하여 SQL을 실행하면 오라클은 'P1'에 어떤 값이 담기든 같은 SQL로 간주한다.
-- 같은 SQL이 실행된 것으로 판단하여 이전에 캐시에 저장해둔 실행 계획을 가져와 SQL을 처리한다.

- Hard Parse : 공유 풀에 실행 계획이 없어 실행 계획을 새로 생성. 위 경우에 해당한다. 사용자(Client)는 같은 SQL이라고 생각해도 오라클은 그렇게 판단하지 않는다.

- Soft Parse : 공유 풀에 있는 실행 계획을 재사용. 아래 경우에 해당한다.

 이처럼 공유 풀과 바인드 변수를 사용하여 소프트 파스를 유도하여 실행 계획 수립에 대한 비용을 낮추는 방법이 사용된다.

공유 풀 정보 with statspack report

- Statspack은 오라클의 분석용 도구이다.

- 위 통계를 보고 parse를 위한 CPU사용량 등이 적절한 지에 대한 판단을 할 수 있을 것

정리

- SQL문은 처리 방법에 대한 기술이 없어 분석(parse)을 통해 처리 방법(실행 계획)을 수립한다.

- 실행 계획에도 좋고 나쁨이 있다. 

- 실행 계획을 생성하는 데 사용되는 비용을 줄이기 위해 공유 풀(라이브러리 캐시)에 실행 계획을 캐시해서 재활용.

캐시(Cache)

- 오라클 시스템 구조에서의 캐시를 살펴보기 이전에 컴퓨터 공학에서 사용되는 캐시라는 용어에 대한 일반적인 개념부터 살펴보는 게 좋다

컴퓨터 구조에서의 캐시 개념

https://www.geeksforgeeks.org/cache-memory-in-computer-organization/

Cache Memory is a special very high-speed memory. The cache is a smaller and faster memory that stores copies of the data from frequently used main memory locations. There are various different independent caches in a CPU, which store instructions and data. The most important use of cache memory is that it is used to reduce the average time to access data from the main memory. 

- 캐시는 캐시 메모리라고 불리며 빠른 속도의 메모리이다. 캐시 메모리는 메인 메모리에서 자주 사용되는 데이터를 더 빠르게 접근하기 위해 따로 저장해두는 메모리를 뜻한다.

- 위는 컴퓨터 구조에서의 캐시 개념을 설명한 것이다. 일반적으로 캐시는 '자주 쓰이는 데이터를 더 빠르게 접근하도록 임시보관하는 메모리 공간'이라고 생각하면 된다. 

- 오라클 시스템에서의 캐시를 살펴보기 이전에 일반적인 캐시 개념을 이용해 유추해보자면 시간이 상당히 걸리는 디스크 접근 횟수를 줄이기 위해 자주 쓰이는 데이터를 캐시라는 메모리 공간에 두고 사용하지 않을까라는 추측을 할 수 있다.

오라클의 캐시(데이터 캐시 혹은 버퍼 캐시)

- 오라클의 캐시는 data cache 혹은 buffer cache라고 불린다. 서버 프로세스(클라이언트의 요청을 처리하는 오라클 프로세스)가 원하는 데이터가 캐시에 존재하면 그 데이터에 접근하여 DISK I/O를 줄인다. 즉, SQL의 처리 속도를 높인다.

오라클 캐시의 데이터 관리 단위 : 블록

- 오라클은 'block'이라는 단위로 데이터를 관리한다. 디스크 I/O 및 버퍼 캐시 모두 블록 단위로 관리한다.(OS에도 블록이라는 개념이 있지만 이것과는 다르다)

- 데이터를 한 개만 꺼내오려고 해도 필요한 데이터를 포함한 블록 자체가 캐시에 보관된다. 2KB, 4KB, 8KB, 16KB, 32KB 등 블록 사이즈를 고를 수 있다. 

- 그림과 같이 인덱스가 단계적으로 되어 있을 때 인덱스를 이용해 데이터를 구하기 위해서는 Outer인덱스의 블록에서 데이터를 가져와(DISK IO 1회) Inner 인덱스 블록을 찾으러 다시 디스크에 접근한다(DISK IO 2회). 그리고 나서 데이터의 주소를 가져와 데이터 블록에 다녀온다.(DISK IO 3회). 위와 같은 구조에서는 디스크에 총 3번을 접근해야 원하는 데이터에 접근할 수 있다.

- 이 때, 원하는 데이터가 데이터 캐시(버퍼 캐시)에 존재한다면, DISK에 접근을 한 번도 하지 않고 디스크 접근이라는 물리적인 움직임 없이 전기적인 신호만으로 클라이언트의 요청에 대한 응답이 가능하다. 이것이 캐시를 이용하는 이유이다.

 공유 메모리(SGA;System Global Area)

- 프로세스는 캐시를 공유한다. 기본적으로 다른 프로세스의 메모리를 보는 것을 불가능하다. 데이터에 손상을 입히지 않도록 OS가 제한을 두기 때문이다. DBMS는 이런 불편한 점을 해결하고 다른 프로세스와 데이터를 공유하기 위해 OS의 기능 중 특수한 메모리 기능인 '공유 메모리'를 사용한다. 즉 자신의 캐시를 다른 프로세스도 볼 수 있게 되고 자신 또한 다른 프로세스의 캐시를 볼 수 있게 된다. 이런 공유 메모리 영역을 오라클에서 SGA(System Global Area)라고 불린다. 공유되지 않는 메모리는 PGA(Program Global Area, 이 명칭은 Process가 Program이 실행된 형태를 의미하는 것을 안다면 쉽게 와닿는다)

- 메모리의 데이터를 공유하기 떄문에 데이터에 손상을 가하지 않도록 락을 걸어 배타 제어(exclusive control)을 DBMS가 내부적으로 수행한다. 예를 들어, 동시에 같은 데이터를 변경하려고 하는 등의 시도를 발생하지 않도록 방지하는 것이다.

버퍼 캐시를 정리하는 LRU 알고리즘

- 정보처리기사에서 페이징 처리 알고리즘에서 배웠던 LRU 알고리즘이 버퍼 캐시를 정리하기 위해 쓰인다. 간단하게 최근에 사용하지 않은 데이터부터 캐시 아웃(버리기)하는 것이다.

데이터 변경도 캐시에서 이루어진다

- 데이터를 변경(update)하는 것과 같은 요청 또한 캐시에서 선제적으로 이루어진다. 설명하자면 클라이언트의 데이터 변경(UPDATE)요청 시 서버 프로세스는 디스크에 직접 변경된 데이터를 전달하여 기록하지 않고 버퍼 캐시에 읽어온 데이터를 변경하여 놔둔다. 이러면 디스크 IO없이 UPDATE SQL요청을 빠르게 처리하고 클라이언트에게 작업완료 응답을 보낼 수 있다. 

- 서버 프로세스가 캐시에 변경된 데이터를 두면 백그라운드 프로세스인 DBWR가 캐시에서 변경된 데이터가 버려지기 전에 디스크에 기록한다. 디스크에 부하를 주지 않기위해 정기적으로 수행한다.

모든 것을 버퍼 캐시에 두지는 않는다

- 오라클은 큰 테이블이라고 판단하면 풀 스캔한 것을 버퍼 캐시에 오랜 시간 보관하지 않도록 하고 있다. 일반적으로 풀 스캔 시의 데이터는 버퍼 캐시에 적재되지 않는다고 생각하면 된다.

- 큰 테이블, 작은 테이블 등의 기준은 '_small_table_threshold' 과 같은 설정값을 바꾸어 조정할 수 있다. 

스토리지 캐시와 OS의 가상메모리

스토리지라는 저장장치의 캐시를 이용하면 IO 시간을 줄일 수 있다

- 스토리지의 캐시에만 데이터 CRUD를 하면 OS입장에서는 스토리지가 캐시 데이터를 알아서 디스크에 기록할 테니 작업이 끝난 것으로 간주할 수 있다. 즉, DBMS입장에서도 디스크 IO가 실제로 이루어지지 않고 스토리지의 캐시에만 기록을 적재한 것이지만 디스크 IO가 끝난 것으로 간주하여 응답을 빠르게 할 수 있다.

- 이렇듯 서버 프로세스가 버퍼 캐시를 사용하는 것만이 데이터 처리의 효율성을 증가시키는 것이 아니라 스토리지 레벨에서도 효율성을 증가시키는 방법이 있다는 것을 알 수 있다.

가상 메모리 때문에 버퍼 캐시가 항상 속도를 증가시키는 것이라고 단언할 수 없다.

- 가상 메모리란 메모리에서 사용 빈도가 낮은 데이터를 물리적인 디스크에 보관하고 메모리에 있는 것처럼 간주하는 기술이다. 이는 OS 레벨에서의 기능이기 때문에 DBMS는 이를 고려하지 않을 것이다.

- 그렇다면 버퍼 캐시가 사용 가능한 물리 메모리의 용량보다 크게 설정되어 있다면 어떻게 될까?

- 그렇게 되면 OS는 가상메모리 기술을 사용해 버퍼 캐시가 사용할 초과분의 용량을 디스크에 마련해 이를 메모리처럼 사용하게 할 것이다.

- 그리고 이 가상 메모리 공간에는 버퍼 캐시에서 잘 사용되지 않는 데이터를 보관하게 하는 것이 가장 효율적일 것이다. 그러다 서버 프로세스가 가상 메모리에 있는 데이터를 요청하면 어떻게 될까?

- 가상 메모리는 디스크에 있기 때문에 디스크 IO가 일어날 것이다. 그러면 서버 프로세스 입장에서는 캐시에만 접근해서 데이터를 가져왔는데도 불구하고 디스크 IO가 일어난 것과 같은 속도로 처리되어 캐시를 사용하는 의미가 없어지게 된다. 즉 아무런 효과도 없는 현상이 발생한다. 가상 메모리 개념과 버퍼 캐시의 개념이 서로 상충하기 때문이다.

- 최근에는 메모리 값이 저렴해지고 용량이 커졌기 때문에 가상 메모리를 사용하지 않는 것을 권고한다. 이렇게 OS레벨에서의 기술과 DBMS레벨에서의 기술이 서로 상충되면 문제를 해결하기 어렵기 때문이 아닐까 싶다

*OS의 버퍼 캐시도 고려해야 한다. 

- OS에도 파일 캐시나 페이지 캐시라고 불리는 버퍼 캐시가 있다. 오라클의 버퍼 캐시와 같은 역할을 수행한다. 그렇기 때문에 오라클을 재기동하고 오라클의 버퍼 캐시를 비워도 OS가 재기동되지 않았다면 OS 버퍼 캐시에 데이터가 계속 남아 성능 측정에 오류가 생길 수 있다.(OS의 버퍼 캐시에서 데이터를 가져왔는데 디스크IO한 것이라고 판단할 수가 있다.)

인터널 테이블 명령어

MOVE

CLEAR, REFRESH, FREE

- 헤더 라인이 없으면 3가지 모두 인터널 테이블의 BODY를 삭제한다.

- 헤더 라인이 있으면 CLEAR는 헤더 라인을, REFRESH와 FREE는 바디를 삭제한다.

- CLEAR : 데이터를 지우고 메모리 공간을 반환(RELEASSE)한다.

- REFRESH : 테이블의 내용만 삭제하고 메모리는 가지고 있는다.

- FREE : 메모리 공간을 반환한다.

- 대부분 CLEAR를 쓰고 헤더가 있는 경우 바디를 삭제할 때는 ITAB[]를 사용하여 바디를 명시하면 바디의 데이터를 삭제한다. 

SORT

- SQL의 ORDER BY와 크게 다르지 않다.

- 그냥 SORT 명령을 실행하면 KEY 컬럼인 COL1을 기준으로 정렬을 수행한다.

DESCRIBE : LINES(현재 라인 수), OCCURS(초기 라인수), KIND(종류)

인터널 테이블 데이터 추가

한 라인 씩 추가, 여러 라인 추가

- SORTED TABLE에 INSERT하면 자동으로 정렬을 한다.

- STANDARD TABLE은 APPEND 구문과 같이 테이블 마지막에 삽입된다.

- APPEND는 STANDARD TABLE에만 쓸 수 있다. SORTED에는 순서대로 삽입해준다면 사용 가능하다.

*INDEX 구문을 이용하면 특정 위치에 라인을 삽입할 수도 있다. 잘 쓰이진 않을 듯 하다.

APPEND INITIAL LINE TO ITAB : 빈 공간 미리 생성하여 라인 추가

SORTED BY : 정렬을 수행하고 추가함. SIZE에 한계가 있어도 정렬 후 추가하기 때문에 SIZE가 꽉 찬 후 추가하더라도 순서상 앞에 와야 한다면 기존 데이터를 밀어내고 자리를 차지한다.

COLLECT 구문

- 인터널 테이블의 숫자 타입 칼럼을 합산하는 기능 수행

- KEY 값을 제외한 칼럼들은 Numeric Type(f, i, p)으로 선언되어야 한다. 같은 key 값이 있을 때는 숫자 타입 컬럼을 합산하고 없을 때에는 APPEND한다.

- Key 값이 없는 테이블에 COLLECT를 수행하면 CHAR 타입 컬럼들을 기준으로 같은 작업을 수행한다.

- COLLECT WA INTO ITAB.

DATA : BEGIN OF GS_LINE,

- COL1, COL2 를 기준으로 값이 합산된 것을 확인할 수 있다.

인터널 테이블 데이터 변경

단건 변경

여러 건 변경

AT 구문 정리

- AT FIRST : 인터널 테이블의 첫 번째 값이 실행될 때 수행

- AT NEW F1 : 컬럼 F1에 새로운 값이 들어올 때 수행

- AT END OF F1 : 컬럼 F1의 값이 마지막일 때 수행

- AT LAST  : 인터널 테이블의 마지막 값이 실행될 때 수행

INDEX를 이용해 한 라인 변경

-  위 굵은 표시 구문에서 INDEX SY-TABIX를 지워도 결과는 같다. 즉, 해당 문구가 LOOP 안의 MODIFY에는 항상 생략되어 있다. 

인터널 테이블 데이터 삭제

TABLE KEY를 이용한 한 라인 삭제

- DELETE TABLE ITAB WITH TABLE KEY K1 =  F1 .... KN = FN.

WHERE 조건을 이용한 여러 라인 삭제

- DELETE ITAB WHERE F1 = V1.

INDEX를 이용한 삭제

- DELETE ITAB INDEX N.

ADJACENT DUPLICATE 구문을 이용한 중복 라인 삭제

인터널 테이블 읽기

- 인터널 테이블을 읽을 때는 READ 구문을 사용한다

KEY 값을 이용한 READ

WORK AREA 할당

1. READ 구문의 COMPARING 옵션

2. READ 구문의 TRASNPORTING 옵션

- TRANSPORTING은 READ한 결과를 해당 컬럼만 TARGET에 저장하는 기능을 수행한다.

- COL2에만 값이 삽입된다. GS_LINE을 CLEAR하고 COL2만 TRANSPORTING하는 듯

인덱스 활용 READ구문

READ TABLE GT_ITAB INDEX 1.

READ BINARY SEARCH

- STANDARD TYPE의 인터널 테이블을 READ할 때 이용 가능. 대상 컬럼을 기준으로 SORT한 후 사용하며 READ 속도가 일반 READ 속도보다 따르다.

- 매번 테이블에 접근하지 않고 테이블의 모든 데이터를 인터널 테이블에 저장한 후에 BINARY SEARCH를 이용해 항공사 이름을 할당하여 속도가 더 빠르다. 그 이유는 데이터베이스에 여러번 다녀오지 않고 APPLICATION SERVER에서 인터널 테이블을 활용하기 때문이다.