1. 내 사랑은 수평선
평등한 관계를 유지하는 것은 두말 하면 잔소리다. 한 사람이 일방적으로 모든 걸 결정하고 주도하는 관계는
언젠가는 삐걱거리게 되어 있다.
"뭐,먹을까?","음,떡볶이는 어떄?" 하고 꼭 물어보자.
또한 상대방이 물어오면 "응,아무거나 먹어." 이런 말 말고 자신의 의견을 바르게 말하자.


2. 소신있고 자신있는 나
귀 얇은 사람들은 연애를 잘 못한다.
왜냐하면 "네 여자친구는 좀그렇더라.","너 남자친구라는게 사실이야? 너하고.." 으로 시작되는 온갖 그들의 주관적인 음해에 천번은 더 맘이 흔들릴 것이다.
그런 말을들으면 여자 친구 혹은 남자 친구를 다시 보게 된다.
내 시선이 아니라, 다른 사람의 시선으로 보게 된다는 말이다.


3. 이걸 보면 얼마나 기뻐할까?
상대방을 행복하게 할수 있는 법을 연구해보자.
좀 머리가 아프겠지만 끊임없이 행복하게 하려는 노력과 결과는 나와 상대방을 감동의 도가니로 몰아간다.
문제는 기발한 이벤트와 선물이 아니라 상대방이 행복해질수 있는 방법을 연구하는 자세인 것이다.


4. 내가 이건 잘못했어
연인들 사이에 싸움은 이상한게 아니다. 무엇보다 중요한 것은 현명하게 화해하는 것이다.
제일 위험한 건 절대 안 싸우는 것이다. 뭔가 부당하다고 생각되는 것이 있으면,싸움을 걸어라. 그래야 문제가 해결된다.
문제는 싸움자체가 아니라 그 뒤에 어떻게 화해하는가 이다.
잘못했다면 먼저 인정하자. 그건 자존심과 아무런 상관이 없다.


5. 가끔은 깜짝쇼도 필요하다
사람이 살아가면서 매일 그냥 그렇고 그런 생활들만이 반복된다면 지루해지기 마련.
이러한 것을 이용해서 상대에게 가벼운 깜짝쇼로 상큼한 활기를 주는 것도 사랑에 한걸음 다가서는 방법이 된다.
깜짝쇼라고 해서 거창할필요는 없다. 그냥 상대방이 피식하고 웃을 정도만 되면 모든 기분은 상쾌함 그 자체이다.
서로를 바라보는 색다른 감정 역시 샘솟을 것이다.


6. 내 감정에 솔직해져야 한다
사랑에 빠진 사람들.특히 짝사랑하는 사람들의 공통점은 자신들의 마음을 속이고 숨기려 하는데 있다.
하지만 사랑은 둘의 마음이 통해야 하룻 있는 것이다. 자신의 마음을 진심으로 상대에게 표현하면 어떤 식으로든 느낌은 통하게 되어있다.
그렇다고 무턱대로 직접적인 고백을 하라는 것이 아니라 하나하나 배려하는 모습과 마음을 보여주면 포근함과 호감을 느낄수 있을 것이다.


7. 상대방의 세계와 비밀지켜주기
같이 있고 싶은 마음은 누구나 같다. 하지만 그러다 보면 자신의 시간은 점점 없어지는 것이다.
자신의 시간이 없어진다는 것은 곧 상대방의 시간도 없어진다는 꼴이 된다.
서로의 시간을 존중해 주는 것만큼 중요한 것은 없다. 서로에 대한 믿음이 밑바탕이 된다면 한 사흘 연락이 없어도 그 사람의 시간과 그의 세계를 인정할 수 있다.


8. 세상이 무너져도 믿는다
오래 연애하는 사람들의 공통점이 바로 이점이다. 서로를 철저하게 믿어주고 신뢰하는 것.
그가 혹은 그녀가 어디에서 무엇을 하는지 엉뚱한 상상으로 스스로를 괴롭히지 말자.
많은 사람들이 사랑이 오래가는 비결!!
그 첫번째가 바로 그 사람의 말을 의심하지 말라는 것이다

'Etc > Scrap' 카테고리의 다른 글

지적인 사람, 창조적인 사람, 지혜로운 사람  (1) 2010.05.11
내 남자친구가 될 사람은  (1) 2010.05.06
흙도 부드러워야 좋다  (1) 2010.05.04
비교  (1) 2010.04.29
날씬한 허벅지 만들기  (0) 2010.04.28


오늘 점심을 홍대에서 먹을려고 갔는데..
역시 어린이 날이라 그런지.. 중딩들부터가.. ㅋㅋ

홍대에서.. 1,2년 전에 먹었던 밀면으로 점심
밀면은 냉면이랑 동일한데 면이 다른걸로 만든게 아니라 밀가루로 만들어서 밀면..
나도 생각을 못했었는데.. 밀면은 부산에서만 봤다는거...
부산 음식이였다.
예전 부산에 살 때 종종 먹었는데..
부산과 완전 동일하다고는 못해도 그래도 맛있었다.
만두는 피도 얇고.. 가격도 홍대 한 가운데에 있는거 치고는 저렴하고...
홍대 놀이터 쪽에 있으니 관심 있는 분들은 한번 쯤 가보시길...
담에는 사진을 올려주겠어!! 먹기 바빠서 그냥 뭐.. ㅋㅋ
2시쯤 먹은 관계로.. ㅡㅡ^

근데.. 우린 밀면2그릇과 만두 하나 먹고.. 부른 배를 부어잡고 있었는데..
옆 테이블에서는 여자 셋이서 밀면3그릇과 만두 4인분을 해치우는 광경을 보고...
우린 정말 새발의 피라는 생각이... 뭐.. 덩치가 쪼금. 있긴해도.. 만두.. 4인분... 촘.. 헉 했다. ㅋ

배불러서 돌아다녔는데...
날씨가 여름 날씨.. 역시 봄은 없어지고 겨울에서 바로 여름으로 넘어가는 군..
예상은 했었지.
배가 불러도 먹고 싶은 아이스크림 베스킨 한사발 또하고..

슬슬 종로로 넘어가서 커플링.. ;;;
백일이 다가오는 시점에서 그날 커플링을 껴야한다고 해서 미리 맞추러 종로 반지가게가 밀집한 곳으로..
첨 간집은 무슨. 40마넌? 반지가 좋아보이긴 했어도 왠지.. 그렇게 까지야.. 무슨 결혼 예물도 아니고..
그냥 패스.. 두번째 집에서는 심플하니.. 그래도 촘 저렴하니.. ㅋㅋ
둘이 눈치보다가 그냥 낙찰... ㅋㅋㅋ
백일이 14일인데.. 13일날에 나온다고 하니... 뭔가 인연이 있나?
아님 우리가 잘 간건가? ㅡㅡ^

그렇게 주문하고 종로에 온 김에 인사동 슬쩍 돌아다니다...
이 넘에 먹어야할 때는 왜 일케 빨리 오는지..
아직 소화도 안됐는데.. ㅋㅋㅋ

또 밥먹으러...
저기가 이름은 생각이 안나는데.. 곡주도 있고 정식 종류도 있고...
우린 낙지 정식을 먹었는데...
맛도 깔끔하고 반찬도 괜찮고.. 가격도 뭐.. 7천원 정도면.. ㅋㅋㅋ
그렇게 또 배를 부어잡고.. 먹었음...
종일 먹고 걷고 먹고 걷고..
나중에는 다리가 기둥이 되지 않을까? ㅋㅋㅋㅋ

'Story > Diary' 카테고리의 다른 글

수영 두번째 날  (0) 2010.05.06
광안대교.. 부산 가고 싶어지네  (0) 2010.05.06
수영...  (0) 2010.05.04
일요일에는 보라매... 공원?  (2) 2010.05.02
귀접힌 고양이~  (0) 2010.05.01
Oracle Server
- Database + Instance = Oracle Server


Listener
- Oracle Server 의 구성요소는 아니다.
- Oracle Server 자체에 없는 기능인, 외부에서 접속을 위한 프로세스
- User process 가 접속을 시도할 때 올바른 접속인지 확인하고 서버프로세스와 직접연결을 해준다


Database 구성 파일
Data File
- 테이블 뷰등 오브젝트들의 실제 값들을 갖고있는다.
- 디스크 I/O 를 줄이기 위하여 파일을 분할
- Backup 의 대상
- 다중화의 의미가 없다 (리도로그파일과 데이터백업파일을 다중화 하므로)

- 시스템용 파일
  SYSTEM file : Data Dictionary 들의 정보 포함하는 파일
  SYSAUX file : 10g에서 추가된 테이블스페이스용 파일.
- 비시스템용 파일
  UNDO file
  TEMP file
  USER file : 일반유저들이 사용하는 파일
< 관련 View >
V$DATAFILE
V$LOGFILE
V$CONTROLFILE
V$TEMPFILE

Redo Log FIle
- Online Redo Log File + Offline Redo Log File(Archived Redo Log File) [Archive Log Mode시]
- 모든 행위의 흔적을 코드화하여 저장 (원문그대로가 아니다)
- 백업된 파일의 시점 이후의 값을복원하기위해 사용된다
- 최소 2개이상의 파일(멤버)필요
- 안정성을 위해 2개 이상의 그룹으로 다중화의 대상이 된다.
- Online Redo Log File 의 집단을 Thread
< 관련 View >
V$LOG
V$THREAD
V$ARCHIVED_FILE

Control File
- Instance 와 연결된 파일(Data File, On/Offline Redo Log File)들의 위치등의 정보 포함
- 때문에 Control File 에러시 Startup 이 제대로되지 않는다. (치명적)
- Startup 시 ORACLE_HOME/dbs/매개변수 파일안에 Control File 의 위치를 참조한다
- 다중화의 대상
< 관련 View >
V$CONTROL_FILE


Instance
- 도구, 수단의 역할
- SGA
- BGP

cf.
 Instance 도 이름이 있고, Database 도 이름이 있으나 일반적으로같게 한다
.


SGA 구성
- Shared Pool
- Data Dictionary Cache (Row Cache) : Database Buffer Cache 에 블럭단위복사된 것중 사용되는 값을 Row 단위로 저장
- Library Cache : 파싱된 SQL 문들이 체인으로 연결디어 저장되어있음. (해시값으로 우선 체인을 택하고 이름으로 동일문장 존재여부 확인)
< 관련 View >
V$BH
V$SQLAREA

- Database Buffer Cache : Meta Data Buffer 와 User Data Buffer 이 존재
- Redo Log Buffer
< 관련 View >
V$SGA
V$SGASTAT


BGP (Background Process) 구성
- DBWn : Data Buffer Cache 의 내용을 내려쓴다
사용가능 메모리를 확보하기위해, 혹은 다양한 발생에 의해
Database Buffer Cache의 Dirty Buffer 를 Data FIle 로 내려쓴다
모아쓰기, 내려쓰기 지원

- LGWR : Redo Log Buffer 의 내용을 내려쓴다
사용가능 메모리를 확보하기위해, 혹은 다양한 발생에 의해
Redo Log Buffer 를 Redo Log File 에 기록한다
모아쓰기, 내려쓰기 지원

- CKPT : Control File 과 Data File 을 업데이트
Checkpoint 란 DBWR 가 Dirty Buffer 를 내려쓰는 행위 (CKPT라는 Process 명과는 다른 의미)
DBWR 이 내려쓰기를 수행해야 할 때를 알려준다
Control File 과 Data File 의 Header 에 표시

- PMON : 프로세스의 비정상 종료시 처리
- SMON : 에러가 났을 경우 인스턴스의 복구
- ARCn : Online Redo Log FIle 을 복사(백업)한다
cf.
필수 Process 의 경우 하나라도 Kill 당할 경우 강제 종료된다.


cf.
FGP (Foreground Process)= Server Process = Shadow Process


접속방법
- 내부접속
export ORACLE_SID=instance_name
sqlplus ID/PASSWD

- 외부접속
sqlplus ID/PASSWD@listener_addr/instance_name



Structure
- Storage
- Logical : Tablespace, Segment, Extents, Block
- Physical
- Database File : Control File, Data File, Offline Redo Log File
- Other Key File : Parameter FIle, Diagnostic File,
- Process
- User Process
- Server Process (Foreground Process)
- Background Process
- 기타 : Listener, iSQL*Plus, DBConsle
- Memory
- PGA
- SGA


Logical and Physical Database Structure


DATABASE : 하나의 단위로 취급된다
TABLESPACE : Container. 하나이상의 Data File 로 구성된다.
SEGMENT : 공간을 차지하는 Object (TABLE, INDEX..) cf. VIEW, SYNONYM Objec 이지만 Segment 는 아니다
EXTENT : 연속된 Block 의 집합
DATA BLOCK : 저장소 및 I/O 의 최소단위

< 관련 View >
DBA_TABLESPACES
DBA_FREE_SPACE // 사용가능한(사용되지않은) Extents
DBA_EXTENTS      // 사용한 Extents
DBA_SEGMENTS
DBA_DATA_FILES
DBA_TEMP_FILES

cf 1.
두개의 파일로 구성된 Tablespace를 만들고 어떤 작업도하지 않았을 경우 Segment 의 개수는 0, Extent 의 개수는 2개이다

cf 2.
PGA와 SGA 의 크기 설정은 작업의 종류에 따라 달라진다 (어느쪽이 크거나 작아야 할 필요가 없다)
예를들어, OLTP 와 OLAP 환경 의 시스템 셋팅은 서로 다를 것 이다.




Buffer
- Database Buffecr Cache 의 단위
<Buffer 의 종류>
FREE
: 한번도 쓴적이 없는 Buffer (FREE 와 CLEAN Buffer 를 합쳐서 사용하기도한다)
PINNED : 사용(R,W)하고 있는 Buffer (다른 사람이 사용 못하게 Lock 을 생성한다)
CLEAN : SELECT 의 내용을 담은 Buffer, 재사용 가능 (다른사람이 사용 할 수 있다), CR Buffer 도 포함
DIRTY : 읽은 후 수정된 Buffer, 원본과 내용이 다른 Buffer 재사용 불가능

cf 1.
SELECT : PINNED->CLEAN
Non-SELECT : PINNED->DIRTY->CLEAN

cf 2.
Fast Commit
확정짓고, 락을 푼 후 Redo Log 를 내려쓴다. 실제로 데이터가 내려쓰여지는 것은 아니다.

Commit 시 바로 Data File 에 내려쓰지 않고 Redo Log 를 우선수행하는 이유는 I/O를 줄이기 위해서다


Instance Recovery
  1. Startup
  2. ORACLE_SID 확인
  3. spfileSID.ora
  4. Instance 구성
  5. Control File Read
  6. Datafile, Redo log file read
  7. INSTANCE RECOVERY
  8. Open


SQL (SELECT) 문의 처리 방식
1. PARSE
- 동일문장찾기
SQL 문을 ASCII 값으로 변환 후
해싱함수를 적용하여 해시키값을 생성한다
해시키값이 같은 체인에 대하여 같은 해싱값들을 체이닝 한다 [라이브러리캐시에서 일어남]
이때 각 해시값들의 이름은 SELECT 문의경우 문장전체를, PROCEDURE 의 경우 프로시저의 이름을 사용한다
후에, 다음의 SQL 문이 사용될때 해시값을 이용해 같은 해시값이 존재하는지 검색한 후
같은 해시값이 존재한다면 다음단계로 이름을 비교하여 해당 SQL이 메모리에 존재하는지 판별한다.
이때 대소문자와 스페이스등을 다른문자로 취급하기떄문(ASCII 값이 다름) 다른문장으로 인식한다.
그러므로 코딩 규약을 지키는게 필요하다

- Syntax 검사
키워드의 오타검사

- Sementics 검사
권한, 객체유무 검사
이러한 검사를위해 오라클에 의한 Data Dictionary Cache 에 대하여 Recursive SQL 자동 발생
이때 자주 사용되는 Data Dictionary Table 의 경우 Database Buffer Cache에 블럭단위로 저장되고
검색의 내용에 해당하는 블럭은 Database Buffer Cache 에만 저장된다
또한 이 중 사용된 Data Dictionary Table 의 Row는 Dictionary Cache(Row Cache) 에 저장된다

- Execution Plan
여러 경우의 실행 계획들의 Cost 를 산출하고
옵티마이저에 의해 Cost 가 가장낮은 실행 계획을 선택한다

2. EXECUTE
Memory(Logical) Read : Cache Hit
File(Physical) Read : Cache Miss

3. FETCH
SELECT 에서만 일어나는 작업
메모리(혹은 디스크)에 올려진 결과를 PGA 로 가져와서 정렬등의 작업을 수행


SQL (UPDATE,DELETE) 문의 처리 방식
- Undo Table : Rollback 과 읽기 일관성을 위한 영역
- Redo : 현재과정들을 백업해놓는것뿐이다
1. PARSE
SELECT 문의 PARSE 단계와 동일하다

2. EXECUTE
1. 변경될 Data Block 및 빈(여유)Undo Block 을 Database Buffer Cache(메모리) 로 Read
2. 읽어올린 Block 을 Row Level Lock 을 설정한다
3. PGA에 저장된 Change Vector 들을사용해서  Online Redo Log File 에 Redo Entry 를 만든다 (안전을위해)
4. Undo Data(Block) 에 변경될 내용 기록 (안전을위해)
5. User Data(Block) 수정
===> 결과 출력 : 1 Row Updated.
===> 업데이트 과정에서 조회된 변경데이터는 CR Block 을 조회한다.


cf.
WAL (Write Ahead Log)
1. 버퍼에서의 자료 변경전 항상 리도버퍼에 먼저 기록을하고
2. DBWR에의해 data file 로 내려쓰기 전에 LGWR 에 의해 항상 내려쓰여지므로
모든 데이터는 항상 로그기록을 먼저 남기게 된다


http://wiki.ex-em.com/index.php/Transaction
http://www.urbantree.wo.tc/46
다이어트의 목적과 함께 수영을 배워보고자 일주일에 3번. 화,목,토...

오늘은 그 첫날...
사실 오늘은 별꺼 할꺼 같지도 않고 해서..
또 내일은 올해 몇일 안되는 빨간날이라.. 패스하고 놀려고 했다.
그런데 뭐.. 가볍게 누구한테 바람 맞아주시고.. ㅡㅡ+
그래서 결국 수영이나 하자 해서 수영장으로.. ㅋ

첫날이니 뭐.. 시설을 어떻게 쓰는지도 모르겠고.. 난감..
5분 일찍 갔다고 입장도 안시켜주고... 오늘은.. 날이 아니야.. ㅜㅜ
지하가서 결국 수영복 입고.. 뻘쭘하니.. 서서.. 기다리는데.. 
기초반이려니 생각하고.. 발차기나 좀 하다 가야지 했는데..
이거 왠일.. 여긴 기초반이라고 따로 모집이아니라.. 
왕창 모집해서 그자리에서.. 나누는.. ㅠㅠ

뭐.. 자유형정도까지는 배웠다구 했더니.. 바로 자유형 시작하라며.. 
아하하... 수영한지.. 2년도 더 된거 같은데.. 그게.. 어떻게했더라.. 하면서... 
물도 살짝 먹어주고.. 키작은 나로써는 물도 깊고.. ㅜㅜ
반정도 갔는데.. 호흡은 죽겠고..
팔다리도.. 힘들고.. ㅋㅋㅋㅋ
결국 안전보드 들고 하고.. 내 뒷사람은 자꾸 나한테 부딪치고.. ㅋㅋㅋ
체.. 력이.. 아주.. 저질인 상태인듯... 
1시간동안 몇바퀴를 돌았는지.. 
수영장을 나오니 다리가 후들.. ㅋㅋㅋ

촘 더 열심히 해서 체력을 길러야지..
살 빠지는게 문제가 아니라 다크써클이 팬더가 될듯.. ㅋㅋㅋ

뭐... 수영도 배우고.. 살.. 이 아니라.. 체력도 기르고.. 아.. 하하하하... ㅠㅠ 

'Story > Diary' 카테고리의 다른 글

광안대교.. 부산 가고 싶어지네  (0) 2010.05.06
나도 어린이... 어린이날~  (0) 2010.05.05
일요일에는 보라매... 공원?  (2) 2010.05.02
귀접힌 고양이~  (0) 2010.05.01
새로 입양한 스니커즈..  (0) 2010.04.30

+ Recent posts