'2013/08/10'에 해당되는 글 2건

  1. 2013.08.10 의약품 Refill
  2. 2013.08.10 오라클 DB에서 테이블마다 용량 구하기

율이 출산 이후에 병원에서 처방전 받아서 먹고 있던 비타민제가 떨어 졌다.
예전에 병원에 비타민 떨어지면 전화 하면 된다고 해서 병원에 전화 해서 처방전을 다시 받고 싶다고 했더니 ,
처방전이 1년짜리이기 때문에 전에 약을 사갔던 약국에 전화를 해서 Refill 신청하면 된다고 한다.

CVS에 전화를 했더니 약통에 있는 RX#를 알려 달라 했는데...
마침 혹시 몰라 약통을 찍어 놨던 사진에 RX#가 있기에 약을 다시 Refill 할 수 있었다.

그동안 Vitamin이 떨어 지면 그냥 다시 병원 가서 처방전 받기 전까지는 못 사는 줄 알았는데..
다행히 그건 아니었다는...

결국 약국도 한 곳을 지정해서 다녀야 여러 모로 편하다는 걸 알게 됐고..
처방전 관리 등을 쉽게 하는 걸 생각해 보니
CVS, Rite Aid 같은 약국 프랜차이즈가 대형화 해서 영업하는 이유도 조금은 알것 같았다..

근데. 참 어의 없는 건..
미국 사망률 2위에 해당하는 게 약물 오남용이고
처방전을 받아서 복용한 약에 의한 케이스도 많다는 얘기에 좀 이해가 안 갔는데..
1년 짜리 처방전이 쉽게 끊어 지고 ( 물론 이 경우는 비타민 이기는 하지만.)
쉽게 Refill 되는 걸 보니...
조금은 원인을 알 수 있을 것 같았다.

의료 비용이 워낙 비싸니..
처방전 받겠다고 병원 가기도 힘들 것이고...

여러모로 합리적인 부분이 많은 미국 이지만..
의료부분을 보면..
한국의 의료보험 모델을 많이 배워야 겠다는 생각이 든다..
( 근데 그렇게 바꾸기 위한 노력이 경제 자유주의와 세금 측면에서 공격 받고 있는 걸 보면
  참 한숨이 나온다는...)

근데.. 그런 좋은 제도를 미국식으로 바꾸겠다는 생각을 하는 한국의 위정자들은 대체 무슨 생각을 하는 건지..
( 여러 모로 존경하는 노무현 전 대통령이지만..
  이 부분과 삼성감싸기 만큼은 노무현 전 대통령한테 좀 실망한 부분이다.
  뭐.. 민영 의료보험도 삼성쪽에서 추진 했던 걸로 기억하니..
  결국은 삼성이 문제 였던 건가...)

'사는이야기 > 미국생활' 카테고리의 다른 글

Verizon to Comcast  (0) 2013.12.02
3년 그리고 새로운 3년  (1) 2013.10.15
반딧불이  (0) 2013.07.05
영미누나... 열정....  (0) 2013.01.12
  (0) 2012.12.31
Posted by headiron
,
SELECT SEGMENT_TYPE, SEGMENT_NAME, TABLESPACE_NAME, TRUNC((SUM(BYTES)/1024)/1024,2) as "용량(MB)"
FROM DBA_SEGMENTS   
WHERE SEGMENT_TYPE IN ('TABLE', 'INDEX', 'TABLE PARTITION', 'TABLE SUBPARTITION')
AND OWNER = '사용자명'
GROUP BY SEGMENT_TYPE , SEGMENT_NAME, TABLESPACE_NAME
ORDER BY 1 desc, "용량(MB)" desc;
출처 : http://koreantramp.tistory.com/216

기존에 개발해 놓았던 LOG 분석 시스템에서
동시 요청 정보를 확인해 보고 싶어서 작업을 돌려 봤더니 세월아 .. 내월아...
체크해 보니.. 시간이 Overlap 되는 정보를 확인하려면 시간 정보에 index가 있어야 하는데.. Index가 없어서 실행 계획이 엉망인것이다.

그래서 Index를 생성해 보았더니.. 이 Index가 생성되는데.. 세월아 .. 내월아..
다행이 예전에 back ground로 query 돌리던 script가 있어서 실행해 보았더니,
한참 돌다가.. TEMP 테이블스페이스가 용량이 부족해서 에러 발생...
https://forums.oracle.com/thread/369703
결국 TEMP 테이블 스페이스 용량을 추가 한 후 정상 생성..
그런데.. Index 생성하는데.. 하루 이상 걸렸다...

뭐.. 그래도 Index 생성했더니... 전에 보다는 몇 백배는 빨라 졌다.
근데.. 동시 요청 정보를 Account Level로 Check했더니 특정 User의 동시 사용 정보 때문에 다른 sequential 요청도 동시 요청으로 잡히는 문제 점 확인...

결국 코드를 수정했더니.. 전엔 Index access로만 데이터를 처리할 수 있었던 Query가
테이블 access가 발생하면서 다시 느려지는...

결국 User 정보를 Index가 다시 추가하는데...
속도는 느리고.. 또 Index 생성하다가 용량 부족으로 에러 나고... -.-

주말내내 Index 생성되는 걸 기다려야 할 듯 하다..

근데 Index 테이블 생성하고.. 위 Query로 체크해 보니..
Index가 테이블 사이즈 보다 훨 커져 버렸다.

말로만 듯던.. ( 어찌보면 분석 시스템에서는 필연적인..) 인덱스가 테이블보다 더 커지는 현상...

예전에 여러 회사에서 시스템 운영하면서 한번도 격어 보지 못했던..
대용량 DB 시스템 관련 이슈를 개인용 ( 물론 업무적으로 개발한거지만.. ) 분석툴에서 겪게 될 쭐이야....

좀 중구 난방 으로 개발 운영하여서 누더기 갇기는 하지만..
그동안 겪어 보고 싶던 대용량 데이터를 다루는 기쁨이라고 나 할 까...


'개발자세상 > Database관련' 카테고리의 다른 글

listagg function and ORA-01489  (0) 2014.01.09
Oracle TEMP 파일 삭제  (0) 2013.09.23
Overlap 데이터 구하기  (0) 2013.08.04
Stored Procedure 개발 / 실행  (0) 2012.12.08
오라클 실행계획 보기  (0) 2010.03.03
Posted by headiron
,