SIWOO.FREE.SOUL^TM

오라클이 선마이크로시스템스를 깜짝 인수하면서 연 매출 50조원 규모의 공룡 IT 기업이 탄생했다.

20일(현지시각) 오라클은 선을 74억달러(주당 9.50달러)에 인수하기로 최종 합의했다고 발표했다. 이같은 인수 총액은 불과 몇 주전 IBM이 선에 제시했던 인수가 70억달러(주당 9.40달러)에 비해 4억 달러 가량 높아진 것이다. 선의 주가 수준에 비춰보면 42% 가량 프리미엄이 붙은 가격이다.

소프트웨어 기업인 오라클은 서버 및 스토리지를 주축으로 한 하드웨어 기업 선을 전격 통합함으로써 소프트웨어부터 하드웨어 전 부문에 걸친 IT 원스톱 서비스를 제공하는 공룡으로 거듭나게 됐다.

양사의 08년 회계연도 매출을 합치면 총 360억달러(약49조원), 종업원은 총 11만6500명에 달한다. 또 양사의 기업 가치를 합치면 총 1000억달러를 넘어선다.

오라클은 선 인수로 전세계 10억대 가량의 컴퓨터 시스템에서 운영되고 있는 ‘자바 프로그래밍 언어’와 컴퓨터 운용체계(OS)인 ‘솔라리스’에 대한 운영 및 소유권도 확보하게 된다.

또 최근 주가 하락 및 매출 감소로 부진의 늪에 빠진 선은 최근 IBM과의 인수합병 협상 결렬로 ‘독자생존’ 여부조차 불투명했으나 이번 오라클의 인수로 새로운 시너지를 창출할 수 있게 됐다고 외신들은 평가했다.

래리 앨리슨 오라클 최고경영자(CEO)는 “선의 인수로 오라클은 IT 전 부문의 서비스를 신속하고 통합적으로 제공할 수 있게 됐다”고 의미를 부여했다.

오라클의 인수 발표 직후 선의 주가는 20일(현지시각) 오전 주당 2.41달러(36%) 가량 급등, 주당 9.10달러에 거래됐다.

김유경기자 yukyung@etnews.co.kr

Sun and Oracle today announced a definitive agreement for Oracle to acquire Sun for $9.50 per share in cash. The Sun Board of Directors has unanimously approved the transaction. It is anticipated to close this summer.

작년 5월 필리핀 여행대비 구입한 것인데..
바다에서는 별도의 하우징을 사용했음에도 불구하고 결국
사진처럼.. 코팅이 벗겨지기 시작했다.

참으로 난감한 상태인데..
고객센터에 전화했더니.. 본사로 보내야 한단다. 택배로만 가능하고 주소는 용인으로..
더군다나 현대택배로만.. 착불인게 다행..

5월2일이 워런티마감인데..
그이후였으면 참..  생각지도 않은 수리비까지 부담하게 될뻔했다.

일단 내일 편의점 가서 현대택배로 보내보고..
돌아오는 상태를 봐야...

우리나라에는 정말로 많은 섬들이 있습니다. 그 가운데에는 아직까지 정체가 밝혀지지 않은 섬들도 상당히 있는데, 최근에 그동안 신비에 싸여 있던 한 섬이 드디어 베일을 벗으면서 많은 관심이 집중되고 있습니다. 그 섬의 이름은 바로 명박도!

명박도의 자연과 지리

먼저 명박도에는 높이 솟아 있는 두 개의 봉우리가 있습니다. 이 봉우리는 각각 '줄파산'과 '줄도산'으로 명박도의 명물이라 할 수 있습니다. 사람이 살기 위해서는 식수가 필요하게 마련인데, 명박도의 두 봉우리에서는 각각 마르지 않는 식수가 나오고 있습니다. 이 두 식수의 이름은 각각 '어청수'와 '한승수'인데, 주로 '어청수'가 인기가 좋고 '한승수'는 있는 지 없는 지 모르는 사람들도 많습니다. '어청수'가 워낙 유명하다 보니 '어청수'가 나오는 발원지 주변에는 음식점과 술집도 눈에 뜨입니다. 여름에 워낙에 시원해서 많은 사람들이 찾는 대폿집인 '물대포'는 그 중에서도 가장 유명한 곳입니다.

그런데 명박도에는 물이 한 가지 더 있습니다. 그 물의 이름은 '강만수'인데, 워낙에 수질이 나빠서 사람은 도저히 먹을 수 없을 정도입니다. 하지만 일부 사람들은 이 물이 마셔도 문제가 없다면서 끼고 살기도 합니다. 심지어는 이 물에서 물고기가 살고 있다면서 이 물고기를 잡아서 뜬 회인 '소망교회'를 즐기는 사람들도 있습니다. '강만수'를 잘도 마시고 사는 이 종족은 'F족'이라고 부르는데, 늘 자신을 일컬어 'I am F'라고 부르는 버릇에서 유래되었다고 합니다. 최근 이 종족이 세력을 넓히고 있어서 명박도 주민들에게 위협이 되고 있습니다. 특히 'F족'은 최근 들어서 신형총탄인 '경제파탄'을 개발한 것으로 알려져서 더욱 위협이 되고 있습니다. 'F족'에게는 또다른 별명이 있는데 키가 아주 작고 장난을 좋아하는 개구쟁이라서 '개구쟁이 스와프'라고도 부릅니다.

하지만 전설에 따르면 명박도에는 이런 물보다 훨씬 질이 좋은 물이 흐르는 강인 '주가 3천'이라는 강이 있다고 합니다. 그러나 그저 말로만 존재할 뿐, 정말 '주가 3천'이 있는지는 도통 찾을 수가 없어서 역사학계에서는 아무래도 뻥인 것 같다는 쪽으로 정리되고 있습니다. 일설에는 수질이 영 나빠서 물고기도 살지 않는 강인 '비핵개방 3천'하고 헷갈리는 것 아니냐는 주장도 있습니다.

한편 명박도에는 천연자원도 상당히 매장되어 있는 것으로 알려져 있습니다. 특히 금의 일종인 '쌀직불금'은 많은 사람들 사이에 보물찾기 열풍을 불러 일으키면서 공무원이고 부자들이고 마지막 한 알까지 모조리 쓸어가 버렸다고 할 정도로 값비싼 귀금속이었다고 합니다. 또한 옥의 일종인 '전여옥'도 있는데 이상하게도 이 '전여옥'으로 구슬을 만들어서 은쟁반에 굴려 보면 은쟁반에 옥구슬 굴러가는 소리는 커녕 육식동물 풀 뜯어먹는 듣기 싫은 소리만 나서 별 인기가 없습니다.

명박도의 농업

명박도에는 '유인촌'이라는 마을이 있는데, 이 마을은 명마의 주산지로 유명해서 특산물인 '찍지마'는 많은 인기를 누리고 있습니다. 특히 보통 말들은 '이랴' 하고 외쳐야 뛰지만 이 '찍지마'는 '씨바'라고 외쳐야 성질이 뻗쳐서 뛰는 특이한 습성으로도 유명합니다.

명박도에서는 목축업이 발달해서 고품질의 달걀이 나오는 것으로도 유명한데, 특히 알이 큼직큼직하기로 소문난 '취업대란'이 요즘 들어서 인기를 누리고 있습니다. 게다가 양봉업도 상당히 발달해서 명박도의 자랑거리인 '재벌'이 만들어내는 꿀은 주요 특산물 가운데 하나입니다. 그런데 이 '재벌'은 조금 독특한 식습관이 있습니다. 평소에서는 꽃 사이를 돌아다니면서 꿀을 채집하지만 꽃이 시들어서 상황이 나쁠 때에는 물고기도 즐겨 먹는다는 것입니다. 특히 '재벌'이 좋아하는 물고기는 '휠체어'로서 '재벌'들이 '휠체어' 위에 올라타서 살점을 맛있게 먹는 모습을 종종 볼 수 있습니다.

명박도의 식생활

명박도에서 유명한 요리라고 하면 후라이드 치킨을 들 수 있습니다. 특히 명박도 명물 'BBK'는 상당히 높은 인기를 누려서 왕족들도 즐겼고, 심지어는 자신이 명박도에 'BBK' 체인점을 차렸다고 주장하는 왕족도 있었습니다만 뭐가 틀어졌는지 왕족의 미움을 받아서 결국 최근 문을 닫았다는 안타까운 사연도 있습니다. 또한 명박도에서 한때 인기가 높았던 빙과였던 하드 '미네르바' 역시도 명박도 왕족의 미움을 받는 바람에 판매 금지되었습니다. 당시 판매 금지 이유로 든 것은 '정부가 미네르바 가격 인상을 지시하는 공문을 보냈는데 실제로는 요청만 했지 공문을 보내지 않았다는' 조금 석연치 않은 내용이어서 많은 의혹을 불러 일으키고 있습니다.

명박도의 역사

명박도의 역사에 대해서는 별로 알려진 것은 없습니다. 다만 최근 고고학자들에 의해 금속 도구를 사용하기 이전 돌을 이용한 도구를 만들어 쓰던 '김석기'시대가 있었던 것으로 밝혀졌습니다. 특히 명박도의 야트막한 산인 '용산'에서는 이 '김석기'시대의 여러 가지 도구들이 발견되어 화제가 되고 있으며 특히 대형 컨테이너는 역사적 가치가 높은 유물로 '김석기'시대의 생활상을 연구하기 위해 고고학으로 유명한 대학인 '경찰특공대'에서 많은 연구가 진행되고 있습니다. 또한 이 비슷한 시대에 외적의 침입을 막기 위해서 세운 '명박산성'이라는 성 유적이 발굴되어서 역사학계의 관심을 끌고 있습니다.

물론 명박도의 각종 역사를 기록한 역사책이나 소설도 전해져 내려 옵니다. 특히 중국의 '삼국지'에 필적한다는 '어륀지'는 명박도 최고의 역사 소설로 그 이름을 드높이고 있으며 먼 옛날 동이족의 상고사까지 다루고 있는 역사책인 '한단고기'를 능가한다는 '미국쇠고기'도 역시 학계의 비상한 관심을 모으고 있습니다.

명박도의 문화

명박도는 상당한 수준의 문화를 자랑하고 있습니다. 먼저 명박도 사람들이 널리 믿고 있던 종교에 대해서 많은 학자들은 기독교라고 생각해 왔습니다만 놀랍게도 명박도의 종교는 불교였다는 사실이 밝혀졌습니다. 특히 명박도의 불교를 중흥시켰던 주역에 대한 전설이 최근 밝혀졌는데, 그는 스스로 '스님'이라는 존칭을 거부하고 '중'이라는 이름을 쓰기를 자청했던 고승 '최시중'이었다고 합니다. '최시중'은 특히 음악에 탁월한 재능이 있어서 명박도의 고유한 음악 장르인 '방송장악'을 제창한 것으로 알려져 있습니다. 그런데 이 음악을 연주하기 위해서는 말하기가 좀 거시기합니다만 생식기 주변의 털을 필요로 했다고 합니다. 그래서 최근 명박도에서는 '방송장악 음모'라는 악기가 발굴되어 학계의 비상한 관심을 모으고 있습니다.

비록 '방송장악'이 명박도의 전통 음악이긴 하지만 역시 젊은층에게는 락 음악이 큰 인기를 누리고 있습니다. 특히 최근 명박도에서 유행하고 있는 락 음악인 '주가폭락'은 폭발적인 반향을 얻고 있습니다. 그래서 최근 명박도의 젊은이들은 인기 차종인 '사이드카' 안에다가 '주가폭락'을 엄청나게 큰 볼륨으로 틀어대면서 과속 질주를 하는 게 유행이라서 이러한 고성방가가 새로운 사회 문제로 대두되고 있습니다.

아직까지 명박도는 많은 부분이 베일에 싸여 있는 신비의 섬입니다. 앞으로 더 많은 연구를 통해서 명박도에 대한 더 많은 사실들이 밝혀질 것이라 믿으면서, 관심 있는 분들의 많은 연구를 바랍니다.

(http://blanc.kr/1155에서 펌)

 

ROLLBACK SEGMENT의 MINEXTENTS를 20 이상으로 하면 좋은 이유
=========================================================

PURPOSE

---

이 자료는 다음과 같은 주제에 대하여 소개하는 자료이다.
이 문서는 database application의 요구 사항을 충족시키기 위해 고려되어
져야 할 rollback segment tablespace 구성에 관한 내용을 담고 있다.

Creating, Optimizing, and Understanding Rollback Segments

---

-Rollback Segment 구성과 기록 방식
-Transaction에 Rollback Segment를 할당하는 Oracle 내부 메커니즘
-Rollback Segment 크기와 갯수
-Rollback Segment의 크기와 갯수 결정을 위한 테스트
-Rollback Segment extent의 크기와 갯수
-Rollback Segment의 minextents를 20 이상으로 하면 좋은 이유?
-Rollback Segment의 Optimal storage parameter와 Shrink

Explanation

---

Rollback Segment 구성과 기록 방식

---

Rollback segment는 extent라 불리는 연속적인 여러 개의 block으로 구성된다.
Rollback segment는 ordered circular 방식으로 extent를 쓰게 되는데,
current extent가 full이 되면 next extent로 옮겨 가며 사용하게 된다.
Transaction은 rollback segment 내의 current location에 record를 쓴 다음,
record의 size 만큼 current pointer를 옮겨 간다.
Rollback segment에 현재 record가 쓰여지고 있는 위치를 "Head"라고 한다.
또한, "Tail"이란 용어는 rollback segment에서 가장 오래된 active
transaction record의 시작 위치가 되는 부분을 말한다.

Transaction에 Rollback Segment를 할당하는 Oracle 내부 메커니즘

---

새로운 transaction이 rollback segment 를 요청하면, 각 rollback segment
를 이용하고 있는 active transaction 갯수를 확인하여 가장 적은 갯수의
active transaction 을 가진 rollback segment를 할당하게 된다.
Rollback segment는 transaction load를 처리하기에 충분한 크기를 가져야
하고, 필요한 만큼의 rollback segment를 사용할 수 있도록 적당한 갯수의
rollback segment를 가져야 한다.

1. 한 transaction은 단 하나의 rollback segment만을 사용할 수 있다.
2. 같은 extent에 여러 transaction이 기록할 수 있다.
3. Rollback segment의 Head는 Tail에 의해 현재 사용 중인 extent를
침범하지 않는다.
4. 링 형태로 구성되어 있는 rollback segment의 extent들은 다음 extent를
찾을 때 절대 건너 뛰는 일이 없으며, 순서를 뒤바꾸어 사용하지도 않는다.
5. Head가 next extent를 찾지 못하면, 새로운 extent를 추가로 할당하고,
그 extent를 링 안에 포함시킨다.

위와 같은 원리를 감안할 때, transaction size 뿐만 아니라 transaction
time도 상당히 중요한 고려 사항이라는 것을 알 수 있다.

Rollback Segment 크기와 갯수

---

Rollback segment size가 충분한지 판단하는 기준은 transaction activity에
직접적으로 영향을 받는다. 주로 일어나는 transaction activity에 근거하여
rollback segment size를 결정하여야 하고, 잘 일어나지 않는 특수한 경우의
큰 transaction이 문제라면 별도의 rollback segment로 관리되어야 한다.
Transaction 발생 중 Head가 너무 빨리 wrap around 시켜서 tail을 catch하
지 않도록 하여야 하며, 자주 변경되는 data에 대해 long-running query가
수행되었을 경우 read-consistency가 유지될 수 있도록 rollback segment
가 wrap around되지 않아야 한다.

Rollback segment 갯수를 적당히 잡아야 하는 이유는 process들 간에
contention을 방지하기 위함이고, V$WAITSTAT, V$ROLLSTAT, V$ROLLNAME
view를 통해서 contention을 확인할 수 있으며, 조회문은 다음과 같다.

sqlplus system/manager

select rn.name, (rs.waits/rs.gets) rbs_header_wait_ratio
from v$rollstat rs, v$rollname rn
where rs.usn = rn.usn
order by 1;

위의 query에 의해 조회된 rbs_header_wait_ratio 가 0.01 보다 크면,
rollback segment 갯수를 추가한다.

Rollback Segment의 크기와 갯수 결정을 위한 테스트

---

1. Rollback segment tablespace 생성
2. 테스트하기 위해 생성할 Rollback segment 갯수 결정
3. 같은 크기의 extent로 rollback segment 생성
extent 갯수는 최대 확장 시 10 - 30 개 정도가 되도록 extent 크기를 결정
4. Rollback segment의 minextents는 2이다.
5. 테스트할 rollback segment와 system rollback segment만 online 상태로 한다.
6. Transaction을 수행하고, 필요하면 application을 load한다.
7. Rollback segment contention을 확인한다.
8. Rollback segment가 최대 얼마까지 확장하는지 모니터링한다.

Rollback Segment extent의 크기와 갯수

---

Rollback segment가 자라나는 최대 사이즈를 알 수 있는데, 이 수치를
"minimum coverage size"라 한다. 만약, contention이 발생한다면 rollback
segment 갯수를 늘려 가면 테스트를 반복한다. 또한, extent 갯수가 10개
미만이나 30개 이상이 될 필요가 있다면 extent 크기를 늘리거나 줄이면서
테스트를 반복해 나가면 된다.
Rollback segment의 extent 크기를 정할 때, 각 extent는 모두 같은 크기로
생성할 것을 recommend한다.
Rollback tablespace의 크기는 extent size의 배수로 지정한다.
최적의 성능을 위한 rollback segment의 minextents는 20 이상이어야 한다.

Rollback Segment의 minextents를 20 이상으로 하면 좋은 이유?

---

Rollback segment는 dynamic하게 allocate되고, 더 이상 필요 없게 되었을 때
(만약, Optimal parameter가 셋팅되어 있으면) 모두 commit된 extent에
대해서는 optimal size 만큼만 남기고 release(deallocate)된다.
Rollback segment가 적은 수의 extent를 가질 수록, space 할당/해제 시
extent 수가 많을 때보다 큰 사이즈의 space가 할당되고, 해제된다.

다음과 같은 예를 들어 보자.
200M 정도의 rollback segment가 있는데, 100M 짜리 2개의 extent로 이루어져
있다고 가정해보자. 이 rollback segment에 추가로 space를 할당해야 할 일이
생겼을 때, 모든 rollback segment extent는 같은 크기를 가져야 한다는 점을
감안할 때, 100M 짜리 extent를 하나 더 할당해야 할 것이다.
이 결과 직전의 rollback segment 크기에 비하여 50% 만큼의 크기 증가분이
생겨나게 된 것인데, 실제 필요로 하는 space보다 더 많은 space가 할당되었을
것이다.

이와 반대로, 10M 짜리 extent 20개로 구성된 200M 짜리 rollback segment를
생각해보자.
여기에 추가로 space를 할당해야 할 일이 생겼을 때, 10M 짜리 extent 하나만
추가되면 되는 것이다.
Rollback segment가 20개 또는 그 이상의 extent로 구성되어 있다면 extent가
하나 더 증가할 경우가 생겼을 때, rollback segment의 전체 크기가 5% 이상은
늘어나지 않는다는 것이다.
즉, space의 할당과 해제 작업이 보다 유연하고 쉽게 일어날 수 있다.

요약하면, rollback segment의 extent 갯수를 20 이상으로 잡으면 space
할당과 해제가 "보다" 수월해진다.
실제로 extent 갯수를 20 이상으로 잡았을 때, 처리 속도가 훨씬 빨라진다는
사실이 많은 테스트 결과 밝혀졌다.
한가지 확실한 사실은, space를 할당하고 해제하는 작업은 cost가 적게 드는
작업이 아니라는 사실이다.
실제로 extent가 할당/해제되는 작업이 일어날 때, performance가 저하되는
일이 발생한다는 것이다.
Extent 하나에 대한 cost는 별 문제가 안 된다고 할지라도, rollback segment
는 끊임없이 space를 할당하고 해제하는 작업을 반복하기 때문에 작은 크기의
extent를 갖는 것이 cost 측면에서 훨씬 효율적이라는 결론이다.

Rollback Segment의 Optimal storage parameter와 Shrink

---

Optimal은 deallocate 시에 rollback segment 내에 optimal size 만큼의
extents를 유지하기 위해 사용하는 rollback segment storage parameter이다.
다음과 같은 명령으로 사용한다.


Optimal size는 storage 절 안에서 기술되어야 한다.
Optimal size 이상이 되면, 모두 commit된 extent에 대해서는 optimal size
만큼만 남기고 release된다.
즉, optimal에서 지정한 크기 만큼만 rollback segment를 유지하겠다는
뜻이며, 일정한 크기로 늘어났다가 다음번 tx이 해당 rbs를 취할 경우
optimal size만큼 resize하는 option이다.

rbs의 가장 최근에 사용된 extent가 다 차서 다른 extent를 요구할 때
이 optimal size와 rbs size를 비교하게 되며, 만약 rbs size가 더 크다면
active tx에 관여하지 않는 tail extent에 대하여 deallocation이 이루어진다.
특정 rollback segment가 너무 큰 space를 차지해서 다른 rollback segment가
extent를 발생할 수 있는 여유 공간을 부족하게 만들기 때문에 이를 극복하기
위해서 optimal size를 지정할 필요가 있다.
즉, optimal parameter를 지정하면 space availability 측면에서 효율적이다.

다음과 같이 shrink 명령을 수행하는데, size를 지정하지 않으면 optimal
size 만큼 shrink된다.


Shrink 명령 수행 후, 바로 줄어들지 않는 경우가 있는데,
transaction이 있는 경우는 줄어들지 않고, transaction이 종료되면 줄어든다.
Optimal이 적용되는 시간은 session이 빠져 나가고 약 5~10 분 정도 걸린다.

적당한 OPTIMAL SIZE?
=> 20 ~ 30 extents 정도가 적당한데, batch job의 성격에 따라 size는 달라
지며 각 optimal의 합이 datafile의 size를 넘어도 전혀 상관없다.
Optimal size를 initial, next와 같게 주면 extent가 발생하는 매번 shrink가
일어나므로 좋지 않다.
RBS들의 평균 크기를 구하여 이것을 optimal 크기로 지정하여 사용하는 것을
권한다.

다음의 query를 이용하여 peak time에 rollback segment들의 평균 크기를 구한다.

select initial_extent + next_extent * (extents-1) "Rollback_size", extents
from dba_segments
where segment_type ='ROLLBACK';

이 크기의 평균값(bytes)을 rollback segment들의 optimal size로 사용할 수
있다.
주의할 사항은 너무 자주 shrink된다거나 optimal 값을 너무 작게 주면
ora-1555 : snapshot too old error가 발생할 확률이 높아지므로,
사용하지 않는 것이 좋을 수도 있고, 되도록 큰 값으로 셋팅해야 한다.

Rollback segment의 optimal size를 확인할 수 있는 view는 V$ROLLSTAT
이라는 dynamic view로서 OPTSIZE column에서 확인이 가능하다.

Example

---

none

Reference Documents

 출처 : OTN Discussion Forum

spfile로 운영시

sysdba로 login
DB shutdown, DB mount
(shutdown immediate -> startup mount)

alter system set log_archive_start=true scope=spfile;
alter system set log_archive_dest_1='아카이브 파일이 저장될 경로' scope=spfile;
alter system set log_archive_format='파일이름_%t_%s_%r.arc' scope=spfile;
alter database archivelog;
alter database open;

Archive log mode 확인

select log_mode from v$database;

-> Archive log mode로 되어있을시, ARCHIVELOG라고 나온다.

pfile로 운영시

pfile에 다음항목 추가

log_archive_dest_1 = "location=아카이브 파일이 저장될 경로"
log_archive_format = arch_%t_%s_%r.arc (아카이브 파일 포맷)

sysdba로 login

DB shutdown, DB mount
alter database archivelog;
archive log list;
alter database open;

Post from http://nasty.tistory.com/82

1. jqac
 - jQuery를 활용한 Auto-complete/suggest javascript 라이브러리
 - 다운로드 : http://code.google.com/p/jqac/downloads/list
 - 데모 : http://www.cs.bgu.ac.il/~ygleyzer/files/utils/jqac/jqac_example.html

2. AutoComplete 1.2
 - prototype과 scriptaculous를 활용한 Auto-complete javascript 라이브러리
 - 다운로드 : http://www.beauscott.com/examples/autocomplete/autocomplete.zip
 - 데모 : http://www.beauscott.com/examples/autocomplete/doc/examples.html
 
3. AutoCompleter(mootools)
 - MooTools를 활용한 Auto-complete javascript 라이브러리
 - 다운로드 : http://digitarald.de/project/autocompleter/#download
 - 데모 : http://digitarald.de/project/autocompleter/1-1/showcase/delicious-tags/, http://digitarald.de/project/autocompleter/1-1/showcase/local/

4. AJAX AutoComplete
 - Jim Roos가 자체로 만든 Ajax framework
 - 다운로드 : http://jimroos.com/AutoComplete.zip
 - 데모 : http://www.jimroos.com/2007/05/ajax-autocomplete.html

5. YUI Autocomplete
 - Yahoo! UI Library로 만든 Auto-complete
 - 다운로드 : http://brandspankingnew.net/download.php?file=autosuggest_v2.zip
 - 데모 : http://developer.yahoo.com/yui/examples/autocomplete/index.html

6. AutoSuggest
 - 심플한 Javascript를 활용한 Auto-complete
 - 다운로드 : http://www.brandspankingnew.net/specials/ajax_autosuggest/ajax_autosuggest_autocomplete.html
 - 데모 : http://www.brandspankingnew.net/specials/ajax_autosuggest/ajax_autosuggest_autocomplete.html

7. dhtmlxCombo
 - 콤보형 Auto-complete
 - 다운로드 : http://www.dhtmlx.com/docs/download/dhtmlxCombo.zip
 - 데모 : http://dhtmlx.com/docs/products/dhtmlxCombo/index.shtml

8. AutoComplete (mootools)
 - scriptaculous를 활용한 Auto-complete
 - 다운로드 : http://script.aculo.us/
 - 데모 : http://demo.script.aculo.us/ajax/autocompleter

지난 7일 서울 여의도 한국방송 별관 스튜디오. <스펀지 2.0>(이하 스펀지) 촬영이 한창이다. ‘실험’만을 위해 두 평 남짓한 세트가 마련돼 있다. 지난해 11월 말 식품첨가물의 실상을 살펴보고자 시작한 스펀지의 작은 꼭지 ‘알아야 산다’의 실험실이다. 세트 바깥의 스무 평 넘는 스튜디오엔 온갖 식기구와 전자레인지 등 가전 제품들이 가득하다. 이날 실험 대상은 ‘명란젓’과 ‘단무지’. 시중 명란젓 20여 종이 커다란 상자 두통에 넘친다. 단무지 두 상자도 대기 중이다.

‘알아야 산다’가 최근 방송가의 주목 대상으로 떠올랐다. 햄·껌·두부 등 실생활과 밀접한 먹을거리들로 실험을 진행하면서 격려와 함께 “그래서 먹지 말라는 거냐” “어차피 먹어야 하는 데 위험성만 조장하는 것 아니냐” 등의 날선 항의가 게시판을 달궜다. “알고 먹자는 것”이란 제작진의 해명에도 논란이 끊이지 않는다.

■ 정보 전달이냐? 고발이냐? 현장 실험을 맡은 김석범 피디는 “좀더 객관적인 정보를 전하자는 의도지만, 현장 고발로 비칠 수도 있을 것 같다”고 했다. “결론적으로 몰랐던 사실을 전달한다는 측면에서는 (고발과) 동일하다”는 얘기다.

명란젓 제작 실험이 시작됐다. 한쪽에는 천일염·흑설탕 등이 단출하게 놓였고, 다른 한쪽에는 솔리톨·아질산나트륨·엘글루타민산나트륨(일명 엠에스지)·색소 등이 빼곡하게 놓였다. 재료를 섞기 시작한 지 5분여가 지나 김 피디가 직접 맛을 봤다. 다른 제작진들도 함께 따라 한다. “정확한 계량은 물론이고, 비교 실험이니 참가자들이 과장된 표정을 짓지 않는지 등을 확인하기 위해 직접 맛을 봅니다.”

화제가 된 지난 두부 실험 당시엔 실수로 첨가물이 제대로 들어가지 않은 두부를 먹고 배탈이 나기도 했다. 실험을 함께 준비하고 진행하는 ㈔한국생협연대 쪽에서는 현장 고발보다 더 낫다고 반기고 있다. 실험을 직접 진행하던 김종실 부천시민생협 운영위원장은 “문화방송 <불만제로>, 한국방송 <소비자 고발> 등과 공조해서 위생이 극도로 불량하거나 첨가물을 지나치게 많이 넣는 현장을 고발한 경우도 있었지만, 직접 고발은 시간이 지나면 다시 원점이 된다”며 “보통 업계에서 첨가물로 먹을거리를 만드는 실험을 차분하게 보여주면서 정보를 전달하는 게 옳다는 판단”이라고 말했다.

■ 불안 조장? 냉담한 업계 시청률을 올리려고 불안을 부추기는 것 아니냐는 시선이 있다. 하지만, 제작진의 반응은 담담했다. 김 피디는 “‘최대한 자극적이지 않게’ ‘업체 가운데 선의의 피해자가 생기지 않도록’이란 원칙 아래 정확한 실험을 진행하는 게 할 수 있는 최대치”라고 말한다. 그는 “햄을 편식했던 아이들에게 그것만 먹는 건 몸에 좋지 않다는 인식을 준다면 족하다”고 했다. 제작진은 자극적 영상을 내보내지 않기 위해 세 차례의 편집을 거친다고 한다. 현장 제작피디가 1차로 편집하면, 책임 피디가 함께 보며 의견을 나눈 뒤 2차 편집을 하고, 전체 팀원들에게 시사를 한 다음 최종적으로 3차 편집을 한다는 것이다.

‘위험할 수 있다’는 가능성만 두고 위험을 단정하는 것 아니냐는 질문에도 제작진은 막힘이 없다. 제작에 공동 참여하는 아이쿱 생협연대의 박진웅 주임은 “식품첨가물에 대한 국내 식품 안전지수가 낮은 편”이라며 “미국처럼 공식적으로 법안에 영향을 끼치는 곳에서도 식품첨가물의 위험성이 입증되지 않아 식용으로 판단하는 경우도 있다”고 말했다. 박 주임은 그런 사례로 뒤늦게 일일허용량 기준이 나온 감미료 아스파탐을 꼽았다.

하지만 식품업계의 반응은 의외로 냉담하다. 한 대형업체 관계자는 “스스로 고품격 정보 프로그램이라면서 공포감을 조성해 시청률을 올리려는 의도가 엿보인다”며 “방송 내용은 대개 90년대 초반 한 번씩 나왔던 문제들로 지금도 확실한 유해성이 입증되지 않았고, 마땅한 대책도 없는 상황”이라고 말했다. 그는 이어 “지난 번 방송된 두부의 경우 유해 성분은 결국 나오지 않았다는 결론이 되는데, 제품이나 회사 이미지 손상은 어떻게 할 것이냐”라고 목소리를 높였다.

글 하어영 이정연 기자 haha@hani.co.kr
사진 김명진 기자 littleprince@hani.co.kr

[oracle@localhost ~] $ rman target /

# database에 full backup을 수행한다.
RMAN> BACKUP AS COMPRESSED BACKUPSET INCREMENTAL LEVEL 0 DATABASE
   2  TAG rman_db_full
   3  FORMAT '/home/oracle/backup/%d.%T.%u.dbfull.rman';

# level 0 full backup 수행이후의 증분에 대해 incremental backup을 수행한다.
RMAN> BACKUP AS COMPRESSED BACKUPSET INCREMENTAL LEVEL 1 DATABASE
   2  TAG rman_db_inc
   3  FORMAT '/home/oracle/backup/%d.%T.%u.dbinc.rman';

#### archive log를 백업한다.
# 현재의 redolog 파일을 아카이브화 시킨다.
RMAN> SQL 'ALTER SYSTEM ARCHIVE LOG CURRENT';
# archive log를 백업하고, 원본 archive log는 삭제한다.
RMAN> BACKUP AS COMPRESSED BACKUPSET ARCHIVELOG ALL DELETE INPUT
   2  TAG rman_arc
   3  FORMAT '/home/oracle/backup/%d.%T.%u.arc.rman';

# 컨트롤 파일 백업.
# 컨트롤 파일이 없다면 컨트롤 파일 장애시 복구 할 수 없을 것이다.
RMAN> BACKUP AS COMPRESSED BACKUPSET CURRENT CONTROLFILE
   2  TAG rman_ctl
   3  FORMAT '/home/oracle/backup/%d.%T.%u.ctl.rman';

# 과거 백업본중 만료된 백업본 삭제.
RMAN> DELETE NOPROMPT EXPIRED BACKUP;
RMAN> DELETE NOPROMPT EXPIRED COPY;

# 과거 백업본 중 지금의 백업에 의해 필요없어진 백업본 삭제.
RMAN> DELETE NOPROMPT OBSOLETE;

# 실제 archivelog 목록과 DB상에 기록된 archivelog 목록을 비교 검사한다.
RMAN> CROSSCHECK ARCHIVELOG ALL;

# archivelog를 삭제한다.
# NOPROMPT 옵션이 있을경우 Y/N를 묻지 않는다.
RMAN> DELETE [NOPROMPT] ARCHIVELOG ALL;