쁘도리의 블로그

온라임 프로그래밍 튜닝 vs 배치 프로그래밍 튜닝

_온라인 프로그래밍 튜닝은 보통 소량 데이터를 읽고 갱신 하므로, 인덱스를 효과적으로 활용하는 것이 중요. 조인도 대부분 NL 방식을 사용 NL조인은 인덱스를 이용하는 조인 방식 (온라인 환경에서 대량 데이터를 조회 할 때도 아주 빠른 응답 속도를 낼수 있다 )

_배치 프로그래밍 튜닝 항상 전체범위 처리 기준으로 튜닝해야 한다.  처리대상 집합 중 일부를 빠르게 처리하는 것이 아니라 전체를 빠르게 처리하는 것을 목표. 이럴때는 Full scan과 해시 조인이 유리함

** 초대용량 테이블을 full scan 하면 상당히 오래 기다려야 하므로, 배치 프로그램에서는 파티셔닝 활용 전량이 매우 중요한 튜닝요소, 이 책의 저자는 모든 성능 문제를 인덱스로 해결 하려 하면 안되며, 인덱스는 다양한 튜닝 도구 중 하나일 뿐 이라고 한다.

*NL조인, 해시조인 참고 url https://mozi.tistory.com/222

3.1.4 인덱스 컬럼 추가

테이블 액세스 최소화를 위해 가장 일반적으로 사용하는 튜닝 기법은 인덱스에 컬럼을 추가하는 것이다. 

> 인덱스에 컬럼을 추가 할 경우 인덱스 스캔량은 줄지 않지만, 테이블 랜덤 액세스 횟수를 줄여줄수 있다.

3.1.5 인덱스만 읽고 처리

비효율이 없더라도 인덱스 스캔 과정에서 얻은 데이터가 많다면 그만큼 테이블 랜덤 액세스가 많이 발생하므로 성능이 느릴 수 밖에 없다.

이런 경우일때 반드시 성능을 개선해야 한다면, 쿼리에 사용된 컬럼을 모두 인덱스에 추가해서 테이블 액세스가 아예 발생하지 않게 하는 방법을 고려해 볼 수 있다. 이 방법이 효과는 매우 좋을수 있지만, 추가해야 할 컬럼이 많아 실제 적용하기 곤란한 경우가 많다고 한다.

[+] 인덱스만 읽어서 처리하는 쿼리를 'Covered 쿼리'라 부르며, 쿼리에 사용한 인덱스를 'Covered 인덱스'라고 부른다.

Include 인덱스 ( SQL Server 2005 버전에 추가된 유용한 기능 )

인덱스 키 외에 미리 지정한 컬럼을 리프 레벨에 함께 저장하는 기능. 인덱스를 생성할 때 include 옵션을 지정하면 된다. 컬럼은 최대 1,023개 까지 지정할 수 있다. include 인덱스는 순전히 테이블 랜덤 액세스를 줄이는 용도로 개발됐다.

프로토타임 : 어떤 객체의 상위 객체 역할을 하는 객체로 하위 객체에게 자신의 프로퍼티와 메소드를 상속한다.

                      (js는 프로토타입을 기반으로 상속을 구현)

Prototype : 프로토타입 객체로 하위객체에서 자신의 프로퍼티와 메소드를 상속

prototype 프로퍼티 : 생성자 함수의 인스턴스 프로토타입을 가르키는 것

 - 함수 객체가 가지고 있음 (생성자함수로 만들어 지지 않은 화살표함수, 축약메소드는 없다)

 - 생성자 함수가 인스턴스의 프로토타입을 할당하기 위해 사용 (생성자함수가 가능한 객체가 소유하는 프로퍼티)

 - constructor 만이 소유하는 프로퍼티

[[Prototye]] : 프로토타입 객체를 가르키는 내부slot, 모든 객체가 가진 내부slot으로 프로토타입 객체를 가리킨다.

                    proto는 프로토타입 객체에 접근하기 위해 사용하는 접근자 프로퍼티

__proto__ : 프로토타입에 접근하기 위한 접근자 프로퍼티 [[Prototype]] 내부 slot에 간접적으로 접근,

                   Object.prototype의 접근자 프로퍼티 모든 객체는 proto를 통해 자신의 프로토타입에 접근 가능하다.

Object.prototype :

모든 객체는 프로토타입 체인에 묶여있는데 js엔진은 객체의 프로퍼티에 접근할 때 해당 값이 없으면 __proto__ 접근자 프로퍼티가 가리키는 참조를 따라 자신의 부보 역할을 하는 객체의 프로토타입을 탐색함

프로토타입 객체

- 모든 객체가 가진 것

- 하위 객체에게 사위 객체의 공유 프로퍼티(메소드) 공유

- 상속의 개념을 구현

프로토타입 체인 : 객체의 프로퍼티나 메소드에 접근할 때 없으면 프로토타입 체인을 따라 프로토타입의 프로퍼티와 메소

                            드를 차례로 검색하게 됨. (JS엔진이 객체의 프로퍼티를 찾을때 해당 객체에 찾는 프로퍼티가 없으면,

                            접근자 proto를 따라서 부모의 프로토타입의 프로퍼티를 순차적으로 검색하는 구조)

출처 : https://rrecoder.tistory.com/176?category=947948

예시]

JSP 

<input type="checkBox" id="chk1" name="chk1" />
<input type="checkBox" id="chk2" name="chk2" />
<input type="checkBox" id="chk3" name="chk3" />
<input type="checkBox" id="chk4" name="chk4" />
<input type="checkBox" id="chk5" name="chk5" />

$('[name^=chk]').prop('checked', true);

: chk로 된 체크박스 name input태그들 전부 checked true 처리 

저장 프로시저 (Stored Procedure, SP)

"저장 프로시저 또는 스토어드 프로시저(stored procedure)는
일련의 쿼리를 마치 하나의 함수처럼 실행하기 위한 쿼리의 집합이다."

_위키백과

"데이터베이스에 대한 일련의 작업을 정리한 절차를
관계형 데이터베이스 관리 시스템에 저장한(지속성) 것으로,
영구저장모듈(Persistent Storage Module)이라고도 불린다."

장점 -

네트워크 부하 감소

처리 시간 감소

데이터 무결성 유지

편리한 유지보수 및 개발 업무와의 구분

절차적 기능 구현 가능

단점 -

불편한 유지보수 ( 개발적 역량으로 인해 )

DB 확장 어려움

1. (인수없는) 프로시저 생성방법

CREATE OR REPLACE PROCEDURE 프로시저이름 

IS

[

변수이름 데이터타입;  -- 프로시저내에서 사용할 변수선언

변수이름 데이터타입;

변수이름 데이터타입;

..

]

BEGIN

 기능 구현;

END;

2. (인수있는) 프로시저 생성방법

CREATE OR REPLACE PROCEDURE 프로시저이름(

변수이름 IN 데이터타입, 변수이름 IN 데이터타입, .... --IN 생략가능

)

IS

[

변수이름 데이터타입;  -- 프로시저내에서 사용할 변수선언

..

]

BEGIN

기능 구현;

END;

3. 프로시져 호출방법

 - EXEC 프로시져이름 ;  -- 인수없는 경우 호출

 - EXEC 프로시져이름(값, 값,....); -- 인수있는 경우 호출;

4. 프로시저 output 매개변수 사용하기

 - 웹개발 하면서 프로시저 결과 핸들링을 위해 많이 사용 했다.

 - 프로시저를 실행하여 특정결과값을 out변수에 저장하여 보낸다.(프로시저에서 실행환경으로 값을 반환)

 - out있는 프로시저 작성방법

CREATE OR REPLACE PROCEDURE 프로시저이름 (

변수이름 IN 데이터타입, 변수이름 IN 데이터타입, .... --in 생략가능

변수이름 OUT 데이터타입, 변수이름 OUT 데이터타입 ... --프로시저를 호출하는곳으로 값을 보낸다.

)

IS

[

변수이름 데이터타입;  -- 프로시저내에서 사용할 변수선언

..

]

BEGIN

기능 구현;

END;

-----

프로시저 문법

DECLARE

> 변수는 선언 시에 기본값을 지정할 수 있습니다. 만약 지정하지 않는다면 그 변수의 값은 NULL 값을 갖게 됩니다.

v_ :  내부 변수로서 프로시저 내에서 사용할 변수에 대해 주로 v라는 표현을 붙여 사용한다.

p_ :  위에서 cmd 창에서 입력을 받던 대체 변수들에 대해  p라는 표현을 붙였던 것을 기억할 것이다.

상수(constant)

> 상수는 변수와 다르게 한번 값이 정해지면 변경할 수 없다는 차이가 있습니다. 상수를 선언하는 방식은 변수의 선언처럼 DECLARE 구문 뒤에서 이루어지며, 상수 이름과 타입 사이에 CONSTANT라고 지정하면 됩니다.

CALL

> 저장 프로시저 호출 

Call 문의 저장 프로시저에서 반환되는 유일한 지원되는 형식은 행 집합입니다. 행 집합 직렬화는 XML for Analysis에 의해 정의됩니다. Call 문의 저장 프로시저가 다른 형식을 반환하는 경우 무시되고 호출 애플리케이션에 XML로 반환되지 않습니다 - https://docs.microsoft.com/

EXCEPTION 

> 예외처리, 프로시저가 예외처리가 없는 경우 프로시저에서 강제적으로 종료되고 오류 메시지가 출력된다고 한다.

GET DIAGNOSTICS

> GET DIAGNOSTICS 명령문은 실행된 이전 SQL문에 대한 정보를 얻습니다.

CURRENT 또는 STACKED액세스할 진단 영역을 지정합니다.

• CURRENT 첫 번째 진단 영역에 액세스하도록 지정합니다. 실행되었고 GET DIAGNOSTICS 명령문이 아닌 이전 SQL문에 해당합니다. 이 값이 기본값입니다.
• STACKED 두 번째 진단 영역에 액세스하도록 지정합니다. 두 번째 진단 영역은 핸들러 내에서만 사용 가능합니다. 핸들러가 입력되기 전에 실행되었고 GET DIAGNOSTICS 명령문이 아닌 이전 SQL문에 해당합니다. GET DIAGNOSTICS 명령문이 핸들러 내 첫 번째 명령문인 경우, 첫 번째 진단 영역과 두 번째 진단 영역은 동일한 진단 정보를 포함합니다.

RAISE NOTICE

> 해당 변수들을 원하는 문자열로 포맷으로 구성한 것을 PL/pgSQL의 실행환경에서 표시하는 코드입니다.

-----

프로시저 삭제

DROP PROCEDURE [프로시저 명] ;

출처:

http://www.gisdeveloper.co.kr/?p=4573 

https://www.ibm.com/docs/ko/i/7.3?topic=statements-get-diagnostics 

https://goddaehee.tistory.com/163 

https://siahn95.tistory.com/entry/DBMSSQL-%EC%A0%80%EC%9E%A5-%ED%94%84%EB%A1%9C%EC%8B%9C%EC%A0%80Stored-Procedure%EB%9E%80

Eclipse Commit Error svn: E204900

해결 방법은 아래 와 같은 경우도 있으나,

https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=deeperain&logNo=221447075864

출처 : https://m.blog.naver.com/PostList.naver?blogId=deeperain [네이버/ 요리하는 개발자]

글쓴이 같은 경우에는 다른이유보다 SVN 저장경로가 용량이 꽉 차서 해당 오류가 발생하였다.

3.1 테이블 액세스 최소화

- 테이블 랜덤 액세스 

인덱스를 스캔하는 이유는, 검색 조건을 만족하는 소량의 데이터를 인덱스에서 빨리 찾고 거기서 테이블 레코드를 찾아가기 위한 주소값, 즉 ROWID를 얻으려는데 있다.

(ROWID는 물리적 주소보다 논리적 주소에 가깝다고 볼수있다고 한다. 추가적으로 정리하자면, 디스크 상에서 테이블 레코드를 찾아가기 위한 위치 정보를 담기 때문..)

_ 메인 메모리DB와 비교

디스크를 경유하지 않고 대부분 데이터를 메모리에서 읽음. (메인 메모리 DB만큼 빠르지는 않다.)

인스턴스를 기동하면 디스크에 저장된 데이터를 버퍼캐시로 로딩하고 이어서 인덱스를 생성한다. 메모리상의 주소정보, 즉 포인터를 갖는다. 따라서 인덱스를 경유해 테이블을 액세스하는 비용이 오라클과 비교할수 없을정도로 낮다고 한다.

_ I/O 매커니즘복습

DBA(= 데이터파일번호 + 블록번호)는 디스크 상에서 블록을 찾기 위한 주소 정보이다.

I/O 성능을 높이려면 버퍼캐시를 활용해야 한다. 해싱 알고리즘으로 버퍼 헤더를 찾고, 거기서 얻은 포인터로 버퍼 블록을 찾는다.

 인덱스로 테이블 블록을 액세스할 때는 리프 블록에서 읽은 ROWID를 분해해서 DBA정보를 얻고, 테이블을 Full Scan 할 때는 익스텐트 맵을 통해 읽을 블록들의 DBA 정보를 얻는다. 

* 인덱스 ROWID는 포인터가 아니다! ( 디스크 상에서 테이블 레코드를 찾아가기 위한 논리적인 주소 정보!!!)

_ 인덱스 ROWID는 우편주소

- 인덱스 클러스터링 팩터

 클러스터링 팩터(Clustering Factor, 이하 'CF')는 군집성 계수로 변역할 수 있는 용어로 [ 특정 컬럼을 기준으로 같은 값을 갖는 데이터가 서로 모여있는 정도를 의미함.]

_CF가 좋은 컬럼에 생성한 인덱스는 검색 효율이 매우 좋다.

// 인덱스 클러스터링 팩터 효과

CF가 좋은 컬럼에 생성한 인덱스가 검색 효율이 좋다는것은, 테이블 액세스량에 비해 블록I/O가 적게 발생함을 의미한다. (추후 설명보충)

- 인덱스 손익분기점

인덱스 ROWID를 이용한 테이블 액세스는 생각보다 고비용 구조. 따라서, 읽어야 할 데이터가 일정량을 넘는 순간, 테이블 전체를 스캔하는(Full Scan)보다 오히려 더 느려진다. 이 느려지는 지점을 흔히 '인덱스 손익분기점' 이라고 한다.

인덱스를 이용한 테이블 액세스가 Table Full Scan보다 느려지게 만드는 가장 핵심적인 두가지 요인은 아래와 같다.

1. Table Full Scan은 시퀀셜 액세스인 반면, 인덱스 ROWID를 이용한 테이블 액세스는 랜덤 액세스 방식

2. Table Full Scan은 Multiblock I/O인 반면, 인덱스 ROWID를 이용한 테이블 액세스는 Single Block I/O방식.

위 와 같은 요인에 의해 인덱스 손익분기점은 보통 5~20% 낮은 수준에서 결정된다. CF가 나쁘면 손익 분기점은 5% 미만에서 결정되며, 심할때는 (BCHR이 매우 안 좋을때) 1% 미만으로 낮아진다. 반대로 CF가 아주 좋을때는 손익분기점이 90% 수준까지 올라가기도 한다.

* 인덱스 손익분기점과 버퍼캐시 히트율

인덱스를 스캔하면서 테이블을 액세스하다 보면 어느 순간부터 대부분 테이블 블록을 캐시에서 찾게된다. 

만 건만 넘어도 시퀀셜 액세스와 Multiblock I/O방식, 즉 Table Full Scan 방식으로 읽는게 빠를 수 있다.

주의) 저자가 말하길 인덱스가 항상 좋을수 없음을 설명하려고 손익분기점이란 개념을 사용했을뿐, 이를 높이기 위해 어떤 조치를 해야 한다는 뜻으로 오해하지 말길 바라며, 테이블 스캔이 항상 나쁜것은 아니며, 반대로 인덱스 스캔이 항상 좋은 것도 아니라는 사시을 설명하는데 목적이 있다고 한다. 

su - 변경할계정 / Switching User 가 안되는 경우 또는 아무 반응이 없을경우.

1. vi /etc/passwd 확인

bin/false로 되어 있다면 로그인이 불가능한 계정 

대안 > su - username -s /bin/sh 스위칭으로 우회방법을 이용하여 사용자 계정변경을 한다. 

2. bash 부여가 안된경우

  usermod -s /bin/bash username 명령어로 변경할 사용자계정의 bash를 부여한다.

주의: 개인적인 경험이므로 정확한 옳바른 해결방법은 아닐수도 있습니다.

참고사이트

https://sup2is.tistory.com/65

ALTER TABLE 테이블명 OWNER TO 소유자명;

ALTER TABLE 테이블명 SET SCHEMA 새로운_스키마명;

특정 유저 소유자의 전체 오브젝트들을 다른 유저 소속으로 변경할경우

REASSIGN OWNED BY 현재 소유자명 TO 새로운 소유자명;

Description: change the ownership of database objects owned by a database role
Syntax:
REASSIGN OWNED BY { old_role | CURRENT_USER | SESSION_USER } [, ...]
TO { new_role | CURRENT_USER | SESSION_USER }

출처: https://orcl.tistory.com/entry/postgresql-테이블의-스키마와-owner-변경하기 

儉而不陋 華而不侈 검이불루 화이불치

검소하지만 누추하지 않았고 화려하지만 사치스럽지 않았다