1. 페이지 이동

Widget build(BuildContext context){
	... 코드 ...
	
	onTab: _showOtherPage,
	
	... 코드 ...
}

_showOtherPage(){
	// Navigator.of(context)로 현재 context의 navigator에 접근한다
	// 새 route를 stack에 push하거나 pop할 수 있다
	Navigator.of(context).push(
		MaterialPageRoute(
			// builder 메서드는 항상 context를 취한다
			builder: (context){
				return otherPage();
			}
		),
	);
}

=> Flutter에서 자동으로 Appbar에 뒤로가기 버튼을 leading으로 추가해 준다


2. 페이지 이동 + 리턴값 받기

Widget build(BuildContext context){
	... 코드 ...
	
	onTab: _showOtherPage,
	
	... 코드 ...
}

_showOtherPage(){
	// Navigator.of(context)로 현재 context의 navigator에 접근한다
	// 새 route를 stack에 push하거나 pop할 수 있다
	TestClass newTestObject = await Navigator.of(context).push(
		MaterialPageRoute(
			// builder 메서드는 항상 context를 취한다
			builder: (context){
				return otherPage();
			}
		),
	);
	
	if(newTestObject != null){	
		... 코드 ...
	}
}

https://flutter.dev/docs/cookbook/persistence/sqlite 를 참조하여 작성

1. 모델생성

class ExampleVo { 
  final int id; 
  final String contents; 

  ExampleVo({this.id, this.contents}); 

  // key 부분은 database의 컬럼명이 들어가야 한다 
  Map<String, dynamic> toMap(){ 
    return { 
      'id':id, 
      'contents':contents 
    } 
  } 
} 

2. pubspec.yaml에 패키지 의존성 추가

// sqlite가 아니라 sqflite임에 주의 
dependencides: 
  flutter: 
    sdk: flutter 
  sqflite: any 
  path: any 

3. database 연결 및 테이블 생성

final Future database = openDatabase( 
  // join function을 이용하여 각 platform마다 올바르게 경로를 확인 
  path: join(await getDatabasePath(), 'example_database.db'), 
   
  // onCreate function을 실행하기 위한 version 설정 
  version: 1, 
   
  // create table 구문 실행 
  onCreate: (db, version) { 
    return db.execute( 
      "create table example(id integer, contets text)", 
    ); 
  }, 
); 

4. crud 구현

// create 
Future insertExample (ExampleVo e) async{ 
  final Database db = await database; 
  await db.rawInsert( 
    'insert into example (id, contents) values (?,?)', 
    [${e.id}, ${e.contents}] 
  ); 
  /* 
    await db.insert('example',e.toMap()); 
  */ 
} 
// retreive 
Future selectExample (ExampleVo e) async{ 
  final Database db = await database; 
  return List<Map<String,dynamic>> exampleList  
    = await db.rawQuery('select * from example'); 
  /*  
    return List<Map<String,dynamic>> exampleList  
      = await db.query('example', columns:[id,contents]); 
  */ 
   
  // 추출된 map은 read-only이기 때문에 수정이 필요할 경우 아래와 같이  
  /* 
    Map<String, dynamic> e = mapList.first; 
    return List.generate(mapList.length, (idx) => { 
                return ExampleVo( 
                  id = mapList[idx]['id']; 
                  contents = mapList[idx]['contents']; 
                ); 
              }); 
     
  */ 
} 
// update 
Future updateExample (ExampleVo e) async{ 
  final Database db = await database; 
  await db.rawUpdate( 
    'update example set contents=? where id=?', 
    [${e.contents},${e.id}]; 
  ); 
  /* 
    await db.update('example',e.toMap(), where: 'id=?', whereArgs: [e.id]); 
  */ 
} 
// delete 
Future deleteExample (ExampleVo e) async{ 
  final Database db = await database; 
  await db.rawDelete( 
    'delete from example where id = ?', 
    [${e.id}] 
  ); 
  /* 
    await db.delete('example',where: id=?', whereArgs: [e.id]); 
  */ 
} 

/* 

  final e1 = ExampleVo (id: 0, contents: 'example0'); 
  await insertExample(e1); 
   
  print(await selectExample()): 
   
  final e2 = ExampleVo (id: 0, contents: 'example1'); 
  await updateExample(e2); 
   
  print(await selectExample()): 
   
  await deleteExample(e2); 
   
  print(await selectExample()): 

*/

flutter에서 db에 저장할 때나 http 요청 등에 많이 쓰이는 Future에 대해 간략히 정리한다.

Future, async, await

flutter의 Future는 javascript의 promise와 유사하다. 미래의 어느 시점에 사용간으한 value를 표현하기 위해 사용한다.

http package에서 get, post 등의 method를 통해 받는 response라든가 new Future 생상자를 통해서 Future Object를 얻을 수 있다.

Future에 관한 대략적인 정보는 아래와 같다.

- Future Object의 상태

pending: 프로세스가 진행중

complete: 프로세스 완료, 세부적으로 complete with value와 complete with error로 분류된다

- Future.then  * try

Future가 complete 되었을 때 callback을 추가하기 위해 사용되는 method다

var future = ... return future object ...

future.then((value){

print('success');

}, onError: (error){

print('error');

}

});

- Future.catchError  * catch

future.then의 onError는 해당 Future 의 error만 처리한다. future가 체이닝되어 발생할 때 한번에 잡기 위해서는 catchError를 사용해야 한다.

new Future.value(1).then(v)({

return Future.error('error');

}).then((v){

return Future.value(v);

})catchError((error){

print('error');

});

- Future.whenCompelete  * finally

var future = ... return future object ...

future.then(print).catchError(print).whenCompelete((){

print('done');

});

- Future.timeout

timeout에서 설정한 시간이 지난 후에 TimeoutException을 발생시킨다

future.delayed(Duration(seconds: 5), (){

return '1';

}).timeout(Duration(seconds: 2)).then(print).catchError(print);

또는 시간이 지난 후 기본값 리턴

future.delayed(Duration(seconds: 5), (){

return '1';

}).timeout(Duration(seconds: 2), onTimeout:(){

return 'default value';

}).then(print).catchError(print);

- async, await

Future가 chain을 이룰 경우 코드가 더러워지기 때문에 async와 await을 사용한다.

Future를 동기처리 코드처럼 사용하게 된다.

void main() async {

var future = Future.delayed(Duration(seconds: 3), () => {return 1});

// await은 Future의 결과를 기다린다

var rslt = await future;

print(rslt);  // rslt 는 1

}

async, await 사용시 error 처리는 try ~ catch ~ finally 구문을 사용한다.

void main() async {

var future = Future.delayed(Duration(seconds: 3), () => {return Future.error('error')});

try{

var rslt = await future;

print(rslt);

}catch(e){

print(e);

}finally{

print('done');

}

}

Future 체이닝이 이루어지는 경우 async, await을 사용하면 callback hell을 방지할 수 있다.

void main() async{

var f1 = (int value) async => v+1;

var f2 = (int value) async => v+2;

var f3 = (int value) async => v+3;

var value=100;

value = await f1(value);

value = await f2(value);

value = await f3(value);

print(value);

}

** 참고: https://flutter-academy.com/async-in-flutter-futures/

몇 년 전 데이터웨어하우스 업무를 처음 맡게 되면서, 개념을 잡기 위해 정리했던 내용을 발견했다. 여기에 다시 포스팅해둔다.

□ DW(DataWarehouse) 란?


○ 정의

사용자의 의사결정에 도움을 주기 위하여, 기간시스템의 데이터베이스에 축적된 데이터를 공통의 형식으로 변환해서 관리하는 데이터베이스

○ 특성

- 주제 지향성(subject-orientation): 데이터를 주제별로 구성함으로써 전산에 약한 사용자라도 이해하기 쉬움(운영계 DB는 어플리케이션 중심)

- 통합성(integration): 데이터가 DW에 들어갈 때는 일관적인 형태(명명법, 변수 측정, 코드화 구조 등)로 변환

- 시계열성(time-variancy): 과거의 데이터를 보관함(운영계 DB가 항상 최근의 데이터만 가지고 있는 것과 다름)

- 비휘발성(nonvolatilization): DW에 데이터가 적재되면 일괄처리(batch)에 의한 갱신 외에는 Insert나 Delete 등의 변경이 수행되지 않음

(출처:https://ko.wikipedia.org/wiki/%EB%8D%B0%EC%9D%B4%ED%84%B0_%EC%9B%A8%EC%96%B4%ED%95%98%EC%9A%B0%EC%8A%A4)

○ 아키텍쳐

DW마다 다르나 통상 아래와 같은 Layer들을 포함

  

- Data Source Layer: DW에 들어갈 다양한 타입(운영데이터, 웹서버 로그, 리서치자료 등), 다양한 포맷(텍스트파일, DB, 엑셀 등)의 데이터소스

- Data Extraction Layer: DM에 들어갈 데이터를 추출하며, 최소한의 데이터 정리 가능성이 있음

- Staging Area:  이후 DW 혹은 DM에서 이루어질 데이터 처리, 통합을 쉽게 하기 위해 존재하는 공간

- ETL Layer: 데이터에 분석 로직이 더해져 정보화되며, 데이터 정리가 이루어짐. ETL tool이 주로 이 단계에서 사용됨

- Data Storage Layer: 변형 및 정제된 데이터가 위치하는 Layer. Scope와 기능에 따라 3가지 타입의 개체가 존재(DataWarehouse, DataMart, OperationalDataStore(ODS))

- Data Logic Layer: Business rules가 저장되는 Layer. 데이터 변환에는 영향을 주지 않지만, 보고서의 형태에 영향을 줌

- Data Presentation Layer: 정보가 사용자들에게 보여지는 단계. OLAP tool이나 Reporting tool 이 단계에서 사용됨

- Metadata Layer: 메타데이터가 저장되는 Layer. 메타데이터 관리를 위해 Metadata tool을 사용함

- System Operations Layer: ETL job status, 시스템 성능, 유저 접속 로그 등 DW시스템 운영과 관련된 정보가 포함된 Layer







(출처:https://www.1keydata.com/datawarehousing/data-warehouse-architecture.html)

자바에서는 new 키워드를 이용해서 객체를 생성한다. 고로 한번만 생성하면 될 객체를 여러번 생성하게 되면 그만큼 메모리에 낭비가 생길 수가 밖에 없다. 때문에 싱글톤 패턴을 적용하여 객체를 한 번만 생성하도록 하는 경우가 있다. 

위 예제에서 n1과 n2는 각기 다른 객체다. 반면, s1과 s2는 같은 객체라는 점을 알 수 있다. 

문제(?)는 내가 지금까지 알던 이 패턴에 허점이 있다는 것. 첫째는 해당 인스턴스를 사용할 필요가 없을 때도 생성한다는 점(Lazy implementation으로 해결 가능), 둘째는 직렬화 시에는 또 다시 새로운 객체가 생성된다는 점이고(readResolve() 메서드를 구현해서 해결 가능), 셋째는 아래 코드와 같이 reflection을 이용하면 기껏 만들어 놓은 싱글톤 패턴을 무시할 수 있다는 것이다.

import java.lang.reflect.Constructor;

public class Test {

public static void main(String[] args) {

Singleton s3 = Singleton.getInstance();

Singleton s4 = null;

try {

Constructor<?>[] constructors = 

                                    Singleton.class.getDeclaredConstructors();

for ( Constructor<?> constructor : constructors ) {

constructor.setAccessible(true);

s4 = (Singleton)constructor.newInstance();

}

} catch (Exception ex) {

System.out.println(ex);

}

System.out.println(s3 == s4); // false

}

}

class Singleton {

private static final Singleton INSTANCE= new Singleton();

private Singleton() {} 

public static Singleton getInstance() {

return INSTANCE;

}

}

그래서 어떻게 하면 되느냐, enum을 사용하면 된다. 아래 처럼

public class Test {

public static void main(String[] args) {

Singleton s3 = Singleton.INSTANCE;

Singleton s4 = Singleton.INSTANCE;

System.out.println(s3==s4);  // true

}

public enum Singleton {

INSTANCE;

}     

        * 예시라서 이렇게 썼지만 실제로 이 부분은 다른 어딘가에 있을 것이다

        * 그 외에 변수나 메서드 등등 필요한게 있을 것이다

}

매우 심플해지지 않았는가? 직렬화 구현도 필요 없고, reflection으로부터도 안전하며, 객체가 여러개 생기는 문제도 없는 해결책이다. 

(단, 직렬화시 멤버변수는 잃게 된다고 한다....https://docs.oracle.com/javase/6/docs/platform/serialization/spec/serial-arch.html#6469)

참고: https://dzone.com/articles/java-singletons-using-enum

Java8부터 도입된 람다표현식. 회사에서는 Java6를 쓰고 있다보니 쓸 일이 없어서 무관심 하다가, 신규 서버로 전환 후 일괄 버전업이 되어 이제 쓸 수 있게 되었다. 내친 김에 간단히 정리해본다.

람다표현식이 중요한게 아니라 함수형 프로그래밍의 사상을 아는게 더 중요하다고 생각되는데, 귀찮으니까 링크로 대체...

위키피디아: 함수형프로그래밍 설명

https://ko.wikipedia.org/wiki/%ED%95%A8%EC%88%98%ED%98%95_%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D

람다식을 이용하지 않고 인터페이스를 구현하는 경우, 원래는 아래처럼 사용했었다.

클래스로 implements한 뒤 사용하거나, 일회성이라면 익명함수로 바로 구현하거나.

public class Test {

public static void main(String[] args) {

Food food0 = new Banana();

food0.eat("banana");

Food food1 = new Food() {

@Override

public void eat(String target) {

System.out.println("eat:"+target);

}

};

food1.eat("banana");

}

}

interface Food {

void eat(String target);

}

class Banana implements Food{

@Override

public void eat(String target) {

System.out.println("eat:"+target);

}

}

그런데 자바8 이후 람다식이 가능해지면서 더 간단하게 표현이 가능해졌다. 아래와 같이... (익명함수 구현시 7줄이던게 2줄로)

public class Test {

public static void main(String[] args) {

Food food3 = (target) -> System.out.println("eat:"+target);

food3.eat("banana");

}

}

@FunctionalInterface

interface Food {

void eat(String target);

}

이것이 어떻게 가능한고 하니... 자바가 함수형 프로그래밍 언어가 아니다보니 람다를 도입하기 위해 함수형 인터페이스, 즉 '단 하나의 추상 메서드만 가진' 인터페이스라는 개념을 만들었다. 

이 때문에 다음과 같은 추론이 가능하게 된다. (위 예시 기준)

1. new Food() 가 필요 없다. Food 타입을 구현하려는 것이 명확하기 때문에 생략 가능하다.

2. eat()가 필요 없다. Food 인터페이스에는 단 하나의 메서드만이 있기 때문에 구현하고자 하는 메서드가 해당 메서드임이 분명하다.

3. String이 필요 없다. 메서드가 하나이므로, 해당 메서드가 받는 파라미터 수와 타입이 정해져있어 파라미터타입 명시가 불필요하다.

확실히 편해졌다. 그런데 인터페이스에 항상 한 메서드만 있어야 한다는데... 처음 구현할 때야 그렇다 치지만, 나중에 누군가 메서드를 추가하면 어떻게 될까? 물론 컴파일이 되지 않고 에러가 난다. 하지만 좀 더 명확히 하기 위해 해당 인터페이스에 @FunctionalInterface 어노테이션을 붙여주자.

람다식과 함께 새롭게 등장한 녀석중 Stream이 있는데, 람다로 인해 이 API가 빛을 발한다. 이건 나중에 포스팅.

□ RM(Resource Manager)이란?

○ 정의

비효율적인 OS 관리로 초래된 문제들(자원의 부적절한 할당, 비효율적인 스케쥴링 등)을 해결하기 위해 Oracle DB server가 자원 관리 결정을 더 잘 하도록 하는 것

○ RM 기능

- 사용자 수나 시스템 부하에 관계없이 사용자에게 자원처리 최소량 보증

- 각각 다른 사용자나 응용프로그램에 CPU time 비율을 할당하여 가용 자원 분배. DW에서는 Batch job보다ROLAP 응용프로그램에 높은 비율이 주어짐

- 사용자 그룹(DB사용자를 리소스 그룹별로 그루핑)이 수행하는 작업의 병행성 수준을 제한

- Active Session Pool(동시에 활성화 되는 세션의 최대치로 구성) 생성. 최대치를 넘어서는 세션은 대기하며,해당 세션에 대해 소멸시간 설정가능

- 관리자 정의 기준에 따라 사용자를 다른 그룹으로 자동 전환 가능(특정 사용자 그룹이 지정된 시간보다 긴 세션을 수행할 경우, 해당 세션을 다른 사용자 그룹으로 옮길 수 있음)

- Optimizer가 추정한 특정 작업(규정된 시간제한을 넘어서는 작업)의 수행 방지

- Undo Pool 생성(한 그룹의 사용자들이 이용하는 undo 스페이스의 양으로 구성)

- session idle time의 양을 제한

- 자원할당을 위한 특정 메서드를 사용하기 위해 instance를 설정instance의 재시작이나 종료 없이 daytime이나 nighttime 설정으로 메서드 변경 가능)

- long-running session 이나 long-running SQL statement 취소를 허용

○ RM 요소

○ Resource Plan 이해

- 기본형태

(출처: http://docs.oracle.com/cd/B19306_01/server.102/b14231/dbrm.htm#i1007556)

하나의 플랜에 따라 각 Resource consumer group이 할당받는 CPU자원이 다름. 만약 SALES group이 자원을 사용하지 않으면 다른 group이 자원을 사용하도록 허용해야함.

- Subplan이 있는 형태

하나의 플랜 아래 Subplan을 두는 것이 가능하며, 이 플랜에 Resource consumer grouop을 세분하할 수 있음. Subplan이나 Resource consumer grouop은 하나 이상의 부모(플랜)을 가질 수 있음. ex) 위 그림에서GREAT_BREAD 플랜이 DAY plan과 NIGHT plan으로 나누어졌을 경우 두 플랜 모두 SALES_TEAM Subplan을 멤버로 두는 것이 가능

* 위 그림에는 없으나 항상 Default로 OTHER_GROUPS가 설정되어 있어야 함

○ DBMS_RESOURCE_MANAGER 패키지

데이터베이스 RM을 관리할 수 있는 시스템 권한(ADMINISTER_RESOURCE_MANAGER)이 있어야 함. 주로 DBA가 ADMIN 옵션으로 해당 권한을 가지고 있음. 권한 획득 후에는 DBMS_RESOURCE_MANAGER 패키지에 있는 프로시져 사용 가능

* 플랜 정보 보는 법

  - Viewing plan information:

select plan, comments from dba_rsrc_plans;

  - Viewing current consumer group for sessions:

select sid, serial#, resource_consumer_group from v$session;

  - Viewing the currently active plans:

alert system set resource_manager_plan = 플랜명;

select name, IS_TOP_PLAN from v$rsrc_plan;

  - Viewing consumer group Granted to user or role:

select * from dba-rsrc_consumer_group_privs;

  - Viewing directive:

select plan, max_est_exec_time, comments, type from dba_rsrc_plan_directives;

○ Pending Area

현재 수행중인 어플리케이션에 영향을 주지 않고 플랜을 만들거나 변경하거나 삭제할 수 있도록 하는 staging area. pending area에서 변경을 한 뒤에는 변경사항을 데이터사전에 적용하기 위해서 pending arear를validate하고 submit해야 함(pending area 없이 플랜을 생성하거나 변경, 삭제 하는 경우 에러 메시지 리턴).

clear_pending_area 프로시져를 통해 pending area로부터 모든 변경사항을 비우고, pending area를 비활성화시킬 수 있으며, 해당 프로시져 다음에는 반드시 다른 변경 시도를 위해서 pending area를 생성해야 함.

○ DBMS_SCHEDULER 패키지

PL/SQL 프로그램에서 호출될 수 있는 스케쥴링 프로시져 패키지. subprogram 중 window를 통해 플랜들을 각각 다른 시간에 자동으로 활성화되게 할 수 있음.

- CREATE_WINDOW Procedure 사용법:

DBMS_SCHEDULER.CREATE_WINDOW (

window_name IN VARCHAR2(윈도우 명),

resource_plan   IN VARCHAR2(리소스 플랜명),

start_date    IN TIMESTAMP WITH TIME ZONE DEFAULT NULL(시작시간),

repeat_interval IN VARCHAR2(반복 간격, Calendaring Syntax로 작성),

end_date      IN TIMESTAMP WITH TIME ZONE DEFAULT NULL(종료 시간),

duration   IN INTERVAL DAY TO SECOND(지속시간, numtodsinterval로 설정),

window_priority IN VARCHAR2(두 window가 겹칠 때 우선순위) DEFAULT 'LOW',

comments      IN VARCHAR2              DEFAULT NULL);

* Calendaring Syntax:

(http://docs.oracle.com/cd/B19306_01/appdev.102/b14258/d_sched.htm#BABFBCEF)

* numtodsinterval: numtodsinterval(n, 'interval unit') 형태로 사용

'interval unit'에는 'DAY', 'HOUR', 'MINUTE', 'SECOND' 가능

- DROP_WINDOW Procedure 사용법:

DBMS_SCHEDULER.DROP_WINDOW (

window_name IN VARCHAR2(윈도우 명),

force           IN BOOLEAN(윈도우 활성에 관계없이 실행 여부) DEFAULT FALSE);

* 윈도우 정보 보는 법

  - Viewing window and resource plan information:

select * from dba_schedular_windows;

□ 파티셔닝(Partitioning)

○ 개요

하나의 테이블이나 인덱스를 동일한 논리적 속성을 가진 여러 단위로 나누어 각각이 별도의 물리적 속성을 갖게 하는 것

○ 장점

- 데이터 접근시 스캔 범위를 줄여 성능 향상

- 데이터 훼손 가능성 저하 및 데이터 가용성 향상

- 각 파티션별 백업 및 복구작업 가능

- 테이블 파티션 단위로 디스크 I/O를 분산하여 부하 저하

○ 파티셔닝 종류(오라클 기준)

- 레인지 파티셔닝(Range Partitioning)

· 특정 컬럼 값을 기준으로 분할

· 주로 순차적인 데이터(historical data)를 관리하는 테이블에 사용

 ex) '가입계약관리' 테이블에서는 통상 최근 1~2년치만 접근

· 각 범위에 따라 데이터 분포도가 일정치 않음

· DDL 스크립트

CREATE TABLE TEST_TABLE

(I_YYYYMMDD VARCHAR2(8), I_CUSTOMER VARCHAR2(9), …… )

TABLESPACE TBS1

STORAGE (INITIAL 2M NEXT 2M PCTINCREASE 0)

PARTITION BY RANGE (I_YYYYMMDD)  <- 파티셔닝 컬럼(16개 까지 지정 가능)

(PARTITION PAR_200307 VALUES LESS THAN (‘20030801’),

PARTITION PAR_200308 VALUES LESS THAN (‘20030901’), …… )

- 해시 파티셔닝(Hash Partitioning)

· 특정 컬럼 값에 해시 함수를 적용해 분할(데이터 관리보다 성능향상에 중점)

· 분포도를 정의하기 어려운 테이블을 파티셔닝할 때 많이 사용(균등한 분포도를 가질 수 있도록 조율, 주로 2의 배수로 파티셔닝)

· 해시 파티셔닝으로 구분된 파티션들은 동일한 논리, 물리 속성을 가지며 파티션에 지정된 값들을 DMBS가 결정하기때문에 각 파티션에 어떤 값이 들어있는지 알 수 없음

· DDL 스크립트

CREATE TABLE TEST_TALBE

( SERIAL NUMBER, CODE VARCHAR2(4), ……)

TABLESPACE TBS1

STORAGE (INITIAL 2M NEXT 2M PCTINCREASE 0)

PARTITION BY HASH(SERIAL)

(PARTITION PAR_HASH_1 TABLESPACE TBS2,

PARTITION PAR_HASH_2 TABLESPACE TBS3, ……)

- 리스트 파티셔닝(List Partitioning)

· 특정 컬럼의 특정 값을 기준으로 파티셔닝

· 주로 이질적인 값이 많지 않고 분포도가 비슷하며 해당 컬럼의 조건이 많이 들어오는 경우에 사용

 ex) '서비스 계약' 테이블에서 서비스 가입 대리점을 A, 서비스 변경 대리점을 B라고 할 때, 모든 서비스 처리 데이터에는 대리점 타입이 두 가지 존재하고 대부분 조회 패턴에는 두 대리점을 구분하는 값이 주어지게 됨

· DDL 스크립트

CREATE TABLE SERVICE_CONTRACT

(I_YYYYMMDD VARCHAR2(8), I_CUSTOMER VARCHAR2(6),

I_DLR_IND VARCHAR2(2), I_DEALER VARCHAR2(6), …….)

TABLESPACE TBS1

STORAGE (INITIAL 2M NEXT 2M PCTINCREASE 0)

PARTITION BY LIST (I_DLR_IND)

(PARTITION PAR_A VALUES (‘A’), PARTITION PAR_S VALUES (‘S’))

- 레인지-해시 컴포지트 파티셔닝(Range-Hash Composite Partitioning)

· 레인지 방식으로 데이터를 파티셔닝하고 각 파티션 내에서 해시 방식으로 서브 파티셔닝을 적용하는 방식 → 서브 파티션이 독립된 세그먼트가 되는 것이 특징

· 레인지 파티셔닝으로 관리와 성능 이슈 향상, 해쉬 파티셔닝으로 데이터 균등 배치와 병렬화, 서브 파티션에 특정 테이블 스페이스 지정가능, 서브 파티션별 풀 스캔을 할 수 있어 스캔 범위 줄이는 효과

· DDL 스크립트

CREATE TABE TB_RANGE_HASH

(I_YYYYMMDD VARCHAR2(8), I_SERIAL NUMBER, SALE_PRICE NUMBER, ……)

TABLESPACE TBS1

STORAGE (INITIAL 2M NEXT 2M PCTINCREASE 0)

PARTITION BY RANGE (I_YYYYMMDD)

SUBPARTITION BY HASH (I_SERIAL)

(PARTITION SALES_1997 VALUES LESS THAN (‘19980101’)

(SUBPARTITION SALES_1997_Q1 TABLESPACE TBS2,

SUBPARTITION SALES_1997_Q2 TABLESPACE TBS3), ……)

운영 중인 시스템 서버 / 스위치 등 장비 교체후  멀티캐스트 통신이 안되는 문제가 발생했다. 문제는 멀티캐스트의 일부 대역대를 스위치 장비에서 해당 제조사의 기능활용을 위해 예약해두어서 발생했다. 해당 기능 설정을 off하고 정상화했다. 문제해결하는 김에 멀티캐스트가 무엇인지 정리했다.

Multicast란?

○ 정의

Multicast group에 소속된 특정 다수에게 데이터를 전송하는 기법

○ 특징

- Multicast group 단위로 묶어 해당 그룹 host들은 동시에 데이터 수신

- UDP 사용(신뢰성 보장 x)

- Client에서 Multicast를 사용하는 어플리케이션을 시작하면 Multicast IP 주소와 Multicast MAC 주소를 라우터에 등록하여 Multicast group에 등록

- 하나의 Client에서 여러 Multicast 주소를 수용 가능

 (여러 Multicast 데이터 수신 가능)

- Server가 Multicast 주소로 데이터 전송 중에 있을 경우,

 중간에 Client가 끼어들어도 처음부터 데이터를 받을 수 없고

 중간부터 받게 됨

○ IP 주소체계(D class IP주소)

* 224.0.0.1 : 현재 서브넷에 존재하는 Mulicast가 가능한 모든 host를 지칭

* 224.0.0.2 : 현재 서브넷에 존재하는 Multicast가 가능한 모든 라우터를 지칭

○ 프로토콜

어떤 장비와 Multicast 정보를 교환하느냐에 따라 프로토콜 구분

- IGMP: host와 라우터 간

- CGMP, IGMP Snooping: 라우터와 스위치간

- Multicasting Routing Protocol: 라우터와 라우터간

○ Unicast / Broadcast / Multicast 차이

- Unicast: 하나의 송신자가 다른 하나의 수신자로 데이터를 전송하는 방식 (일반적인 인터넷 응용프로그램이 채택)

- Broadcast: 하나의 송신자가 같은 서브네트워크 상의 모든 수신자에게 데이터를 전송하는 방식

- Multicast: 하나 이상의 송신자들이 특정한 하나 이상의 수신자들에게 데이터를 전송하는 방식(인터넷 화상 회의 등)

 => 다중 수신자에게 동일한 데이터를 전송할 경우 유니캐스트 사용시 데이터패킷을 다수 사용자에게 여러 번 전송하기 때문에 회선부담, 브로드캐스트 사용시 하나의 트래픽으로 보내지만 No Reciever 입장에서는 불필요 트래픽 수신

(참고: http://www.terms.co.kr/multicast.htm

http://unabated.tistory.com/entry/Multicast-1-%EA%B8%B0%EB%B3%B8-%EC%9D%B4%EB%A1%A0

https://wiki.kldp.org/wiki.php/LinuxdocSgml/Multicast-HOWTO)

회귀분석에서 T통계량과 F통계량을 사용하는 이유

https://m.blog.naver.com/PostView.nhn?blogId=vnf3751&logNo=220841363022&proxyReferer=https%3A%2F%2Fwww.google.co.kr%2F