« Previous : 1 : 2 : 3 : 4 : 5 : ... 8 : Next »

요즘 MS-SQL이나 Oracle로 구축된 사이트의 경우 개발언어가 무엇이든간에 DB성능상의 이유로 Prepared Statement 를 사용해서 구축된다. 이럴때는 SQL에 변수를 바인딩하기 때문에 SQL Injection 공격을 당할 소지 자체가 원천적으로 사라진다.

하지만 mysql의 경우 Prepared Statement를 이상한 형태로 지원한다. MySQL은 SQL문의 실행계획을 DB레벨이 아니라 Connection레벨에서 유지한다. 즉, 커넥션 끊어버리면 실행계획이 다 날아간다. 따라서 Permanent Connection 이나 Connection Pooling을 사용할 때나 실행계획 재사용이라는 Prepared Statement의 이점을 누릴 수 있다. 하지만 php 개발하는데 누가 커넥션 풀링을 사용하나? (간혹 있는데 대부분의 중소 사이트는 그렇지 않다.) 따라서 자연스럽게 Prepared Statement를 하지 않고 Text로 SQL을 조립하는 방향으로 개발하게 된다. 10년전.. MSSQL이나 Oracle세계에서 쓰던 방식이 되겠다... 하아....

결과적으로, 변수받아서 SQL을 조립할 때 SQL Injection 방지를 위한 별도의 처리를 해주지 않으면 해커들에게 "날 잡아잡수쇼~" 하는게 되는 것이다.

모든 변수에다가 별도처리해주려면 그야말로 환장을 한다. 어흐흐흐. mysql은 빨리 제대로 된 Prepared Statement 를 지원하라!!!!!!!! -_-;;;;;;;;;

Posted by maceo

12 4, 2009 17:33 12 4, 2009 17:33
, ,
Response
No Trackback , No Comment
RSS :
http://merritt.co.kr/tt/rss/response/137

mysql에서 그룹별 TOP n 뽑아오기

오라클에서는 무식하게 하면 row_number() over (partition by) 로
MS-SQL에서는 좀 더 세련되게 cross apply 로 해결할 수 있는데
(오라클에서 cross join 으로 cross apply 를 비슷하게 흉내내는 기법이 있는데 까먹었다. 도저히 생각이 안난다 ㅠ_ㅠ 또는... MULTISET 으로 scalar subquery 가 여러개의 행을 리턴할 때도 문제없이 처리하는 방법이 있다.)

mysql에서 쩔쩔 매다가 아래를 발견!!!

http://blackbull.tistory.com/43

이 생각을 못하다니. 바보 -_-;;;;

Posted by maceo

11 9, 2009 16:19 11 9, 2009 16:19
Response
No Trackback , No Comment
RSS :
http://merritt.co.kr/tt/rss/response/136

MySQL 8개월 사용 소감

NC로 옮겨와서 새로운 서비스를 만들고 있는데 여기서는 mysql 을 사용하고 있다.

아휴.. 이거 뭐, MS-SQL로 시작해서 Oracle에 MySQL까지.. 우물을 세개나 파다니 어질어질하기도 하지만 세개의 DB가 전체적으로 비교가 되어서 좋기도 하다.

결론부터 말하자면 MySQL 이거 아주 장래가 촉망되는 물건이다. 거대 상용 DB들에 대한 disruptive innovation 이랄 수 있다. 아직 Hash join, Parallel Query라는 거대한 산을 넘어야 하는 이슈가 있긴 하지만, OLTP에만 쓴다면 이런거 필요없다. DW에도 어느정도 사용할 수도 있는 것이, Infobright 라는 column 기반 스토리지 엔진을 사용하면 DW/OLAP도 커버가능하다고 한다 (어느정도까지겠지... ㅎㅎㅎ) 중요한거는 소스가 공개되어 있고 스토리지 엔진을 따로따로 가져갈 수 있어서 이러한 변종까지 등장할 정도로 유연하다는게 장점이다.

최근 Amazon Relational Data Service 가 나왔는데 이게 MySQL을 근간으로 하고 있다. 아마존 SimpleDB라는게 있긴 했지만 이젠 본격적인 RDB 클라우드 서비스를 제공해주는 셈.

이제는 이론적으로는 이런 그림이 가능하다.

1. OLTP는 amazon RDS 로 운영
2. 이미지, 첨부파일은 amazon S3 에 저장
3. DW/OLAP등 분석계 작업은 amazon SimpleDB
(내부적으로 MapReduce같은거 지원하지 않을까?? 없으면 분명히 나올거다)

에서 수행하면, 거대한 서버 인프라가 전혀 필요가 없게된다.

10년후를 바라보면, 이런 클라우드 자체를 운영하는 Job이 각광을 받을 수도 있겠다.
아 물론 지금 Linux 때문에 HP-UX/IBM AIX 엔지니어들이 다 굶어죽은거 아니고 tomcat때문에 WebLogic 엔지니어들 다 굶어죽은거 아니다 .하지만 DB서버 바로 앞단까지 Linux가 침투한 현실을 고려하면, 10년후에는 MySQL의 위상이 굉장히 많이 올라갈 듯 하다. 아마도 Linux가 걸은 길을 그대로 걷지 않을까 싶다.



@그런데 시중에는 제대로된 MySQL 백업 & 리커버리 가이드 책도 없는 실정이다. 오라클 7.0 시절의 관련 도서 시장과 비슷한 분위기랄까? 쓸만한 책 번역해서 내놓으면 꾸준히 팔릴 것 같다 -_-;;;;;;;;;

Posted by maceo

11 9, 2009 16:11 11 9, 2009 16:11
,
Response
No Trackback , No Comment
RSS :
http://merritt.co.kr/tt/rss/response/135

G마켓


떠난지 이제 2년이 다 되어가는 시점에서, 이베이의 G마켓 인수 발표를 보면서 이런 저런 생각이 든다. 두서없이 나열해보자면,

G마켓이 옥션을 이긴 이유?

1. 차별화된 전략 + 기막힌 카테고리 선정
옥션이 경매만할 때 오픈마켓에 고정가 판매를 도입했다.  지금와서는 당연한듯 여겨지지만 그 당시에 그런 중대한 결정을 내리고 밀어붙였다는 사실 자체가 진짜 대단한거다. 게다가 온라인에선 안된다고 하던 의류를 공략했다. 얼마나 반대가 심했겠나? 벤처기업은 한번의 전략적 의사결정 미스는 바로 폐업으로 이어진다. 그야말로 외줄타기. 외줄타기 몇년을 한 끝에 시총 1조원짜리 나스닥 상장기업까지 되었으니 얼마나 대단한가.

2. 미칠듯한 스피드의 실행력
SKT/11번가에 1년 반정도 있다보니 알겠더라. G마켓이 얼마나 일을 잘하는 조직인지. 좀 투박한 면이 있긴 하지만 일을 되게 하는 측면에서는 단연코 옥션/11번가와 비교가 안된다. 똑같은 일을 하더라도 2~3배 정도의 스피드가 난다. 의사 결정자가 워낙 판단을 빨리 하기 때문인 점이 가장 크다. 정확한 판단을 한답시고 이래저래 자료 뽑고 격식 갖춰 보고 올리고 그럴 시간에 빨리 뭔가를 해보고 아니다 싶으면 잽싸게 방향 수정한다. (후발주자인 11번가가 이게 엄청 심하다. 이래가지고 어떻게 1위 따라잡겠다고... 하지만 윗선이 그런 문화에 젖어있는 사람들이라 아마 못바꿀거다)

3. 1위 업체의 방심
옥션 창업 멤버 출신의 11번가 임원 어느 분이 이런 말을 했다. "옥션이 이베이에 인수된 후 특유의 문화를 잃어버리고 관료화되고 조직이 활력을 잃었다. 그리고 당시 압도적인 1위 자리에 도취되었다. 그래서 G마켓이 무섭게 크는 것을 방관하다가 당했다."
그 분말고 옥션에 8년정도 다닌 다른 분은 이미 2004년 2005년 경에 이베이 본사에서 G마켓이 무섭게 크고 있는걸 알고 있었고, 어떻게 다른지 분석한 자료도 다 가지고 있었다고 한다. 그 자료 나한테도 보여준 적이 있다. 그런데도 저러다 망하겠지.. 하고 방심했다고 한다. 2004년 2005년만해도 옥션의 오픈마켓 시장 점유율이 70% 는 되었으니까.

과거는 저렇게 설명이 되겠는데, 미래는 어떨까?

이베이는 G마켓 모델로 아시아권을 뚫겠다고 하는데 저 모델은 옥션도 이미 하고 있다. 11번가도 하고 있다. 이제 한국에서는 표준이 되다시피한 모델이다. 이 모델의 핵심은 "셀러영업" 이다. 이베이처럼 고상하게 경매 시스템 열어놓고 놔둔다고 해서 척척 돌아가는 그런 모델이 전혀 아니다. 엄청 잔손이 많이 가는 BM인 것이다. G마켓 샀다고 해서 일본/중국에서의 셀러 영업력이 바로 생기는건 당연히 아니다. G마켓 일본 사이트가 1년정도 되었는데 셀러 영업에 난항을 겪고 있다고 한다.

http://itnews.inews24.com/php/news_view.php?g_serial=398123&g_menu=020300

이게 뭘 말하는건가?

일본은 완전히 다른 세상이고, G마켓 모델이 통할지 전혀 알 수 없다. 옥션이 이미 하고 있는 BM인데다 G마켓 재팬이 어려움을 겪고 있는데 이베이는 도대체 왜 샀을까? 일설에 의하면, 이재현 이베이 아태대표와 박주만 사장의 정치적 의도가 작용했다는 이야기도 있다. 두 사람의 임기가 얼마 안남은 상황인데 옥션은 G마켓에 1위 자리를 내줬고, 영업 이익도 분기별 적자까지 봤다. 이런 상황을 타개할만한 회심의 카드로 본사에 G마켓 인수를 설득했다는 그런 얘기다. 인수를 했으면 일단 그거 가지고 어찌어찌하면서 몇 년은 더 갈 수 있을테니.

난 G마켓이 옥션이 그랬던 것처럼 지극히 관료화되진 않을까 그게 제일 우려스럽다. G마켓 BM의 핵심은 셀러 관리, 스피드인데... 관료화된 조직에서 그걸 예전처럼 잘 할 수 있을지, 의욕적으로 새로운 상품 카테고리를 발굴해나갈 수 있을지.. 그런 생각이 든다. 게다가 여기저기서 떨어질 낙하산들(예전의 옥션이 그랬듯...) 신-구 세력간의 갈등 등등... G마켓은 구영배 1인 카리스마가 지배하는 회사에서 조직간 분열-갈등이 생길 일이 없었는데 이제 낙하산들 떨어지면 회사가 어찌될지. 그 사람들이 보기에 구 사장은 대주주도 아니며,  피인수기업의 대표(패장?) 일 뿐이라고 생각될테니...



@G마켓이 관료화/내부갈등 등으로 특유의 활력을 잃어버린다면 11번가엔 기회가 될지도 모르겠다. 하지만 11번가는 태생부터가 관료적인 문화여서 그 기회를 얼마나 잘 이용할지...

@@11번가의 가장 문제는 G마켓이 그랬던 것처럼 차별화된 BM을 만들지 못하고 있다는데 있다. 11번가의 책임자급 이상은 차별화가 얼마나 중요한지 잘 알고 있다. 하지만 가장 큰 문제이자 비극은 그걸 해본 사람이 없다는데 있다. -_-;;; 그걸 해본 사람이 있었다면 진작에 G마켓을 위협하는 업체가 하나 생겼겠지. 어차피 그 업계에서 흘러들어온 사람들인데. G마켓의 경우 중요한 전략적 아이디어와 서비스들이 사장 머리에서 나왔고 그 때문에 그걸 뚝심있게 밀어붙일 수 있었다. 11번가는 뭐.. 전형적인 대기업 관리자 타입이다. 외주 업체 쪼던 것처럼 실무 팀장급들한테 "차별화된 아이디어를 가져오란 말이야~!" 하고 쫄 뿐이다. 이런게 기량의 차이겠지. (누구나 아는 차별화란게 그만큼 어렵다는 반증이기도 하고...)


Posted by maceo

04 16, 2009 20:16 04 16, 2009 20:16
, , , ,
Response
No Trackback , 5 Comments
RSS :
http://merritt.co.kr/tt/rss/response/134

http://forums.oracle.com/forums/thread.jspa?threadID=664391&tstart=0

http://www.oracle-base.com/articles/10g/Services10g.php#jobs_and_services

11g 에서는 instance_id 가 추가된다고는 하지만..10g에서는 꽁수로 가능함



Posted by maceo

01 1, 2009 14:50 01 1, 2009 14:50
, ,
Response
No Trackback , No Comment
RSS :
http://merritt.co.kr/tt/rss/response/129

10.2.0.4 패치에서 workload capture 까지는 지원하나 capture파일의 재생은 11g에서만 가능하다고 하는군. 젠장 -_-;;;;

http://www.dbta.com/e-edition/Dec08/13-column_kumar.html

혹시 모르니 오라클에 물어나볼까나....

Posted by maceo

12 29, 2008 01:26 12 29, 2008 01:26
, ,
Response
No Trackback , No Comment
RSS :
http://merritt.co.kr/tt/rss/response/128

IO 부하 경감을 위한 KEEP Pool의 활용


여러 사람들의 이야기를 들어보니 Oracle의 Multi Buffer Pool 기능을 잘 사용하지 않는다고들 한다. 그런데 우리 사이트처럼 상당한 량의 Online Transaction과 Batch가 함께 도는 사이트에서는 Multi Buffer Pool이 유용하게 쓰일 수 있다.

일반적으로 KEEP Pool은 항상 read가 일어나야 하는 조그만 테이블들을 KEEP하는 용도라고 알려져 있다. 하지만 우리 사이트에서는 다르게 사용한다. 

Batch와 Online에서 다 같이 많이 쓰는 "큰" 테이블/인덱스들을 KEEP에 올려놓는다.

1. table full scan 으로 테이블을 읽으면 touch count도 올라가지 않을 뿐 아니라 buffer cache의 끝부분에 올라갈 가능성이 높다. (http://ukja.tistory.com/133 참조) 하지만 상대적으로 여유가 많은 KEEP으로 보내게 되면 메모리에 좀 더 오래 머물러 있을 가능성이 높다.

2. 이 테이블을 online에서도 다양한 파라미터로 index range scan하거나 table access by rowid를 할 때 해당 블럭들은 touch count가 높아지면서 KEEP에 좀 더 오래 머물러 있을 가능성이 높아진다. 

KEEP사이즈보다 더 크게 오브젝트를 KEEP해도 무방하다.
KEEP도 기본 버퍼풀과 동일한 알고리즘으로 움직인다. 모자라다고 해서 에러를 내지는 않는다. 오히려 이렇게 하는게 더 좋은 것 같다. full scan이 발생하는 테이블이라고 해서 언제나 모든 블럭이 메모리에 있어야 하는 것은 아니다. 그 중에서 range scan이 많이 들어오는 블럭들은 KEEP에도 오래 머물것이고, 다른 테이블에 대한 full scan이 들어올때는 touch count 가 높아져 있는 블럭들을 제외한 나머지 블럭들은 영역을 내줘도 괜찮은 것 같다.

Recyle Pool 에는 사이즈 크고 가끔 쓰는 테이블들을 올려놓는다.
이를테면 email 발송 솔루션의 발송 대상 테이블 같은 것들이다. (원래는 박스 자체를 분리해야하나..-_-)

정리하자면,

online과 batch가 함께 도는 환경에서는
1. onoline/batch에서 다 같이 자주 쓰는 "큰" 테이블은 KEEP
2. batch에서만 가끔 쓰는 테이블은 Recycle에 넣어서 full scan의 영향도를 최소화하자.

(KEEP에 큰 테이블을 넣는 것은 사실 상식에 반하는 것인데.. 좀 더 검증이 필요하다. KEEP에 넣는 오브젝트들을 다양하게 조절하면서 v$buffer_pool_statistics, v$db_cache_advice의 변화를 계속 관찰하자.)


Posted by maceo

12 27, 2008 02:11 12 27, 2008 02:11
, , ,
Response
No Trackback , a comment
RSS :
http://merritt.co.kr/tt/rss/response/127

IOT 에서 redo log 를 조심하자

Oracle 에서는 IOT를 잘 쓰질 않는다. SQL Server 에서는 Clustered Index를 습관적으로 사용하는데 비해서 오라클에서는 확실히 분위기가 좀 다른 것 같다. 잘만 쓰면 여러모로 좋은 점이 많을텐데 습관의 벽을 잘 넘어서지 않는 것 같다는 생각이 든다.

이번에 통계DB 테이블을 IOT 전환하면서 알아낸 몇가지..

테스트 내역
날짜 + 분류코드로 PK가 잡힌 5억건의 일반 테이블을 IOT로 전환

테스트 결과 요약

  1. 일반적인CTAS nologging 으로 하면 redo, undo가 발생하지 말아야 하지만 IOT 면 redo가 발생한다.
    보통의 IOT테이블에는 direct INSERT가 안먹는다.
  2. 대상 IOT가 Partitioned IOT 면 Direct-INSERT 가능하다.
    11g 에는 매뉴얼에 그렇게 나와있는데 10g R2 매뉴얼에는 IOT 에는 direct insert 가 안된다고 나왔다. 실제 테스트해보면 그렇지 않다. 10g R2 에서 Partitioned IOT 에 CTAS하면 redo 가 최소화된다. 10g R2 매뉴얼에 오류가 있는 것으로 보임.
  3. Including , overflow를 조심해서 쓰자.
    여기에 포함된 컬럼 때문에 redo가 대량으로 생길 수 있다. 조심하자
  4. Insert /*+ append */ 를 쓰지 말고 CTAS를 쓰자.
    Partitioned IOT를 미리 만들어놓고 Insert /*+ append */ 하면 최종 commit 때문에 CTAS보다 redo가 훨씬 많이 발생한다. DML이라서 그렇다. CTAS는 DDL이므로 redo같은게 없음.

결론
일반 테이블을 IOT 전환시 redo 발생을 최소화하기 위하여 Partitoned IOT 를 CTAS nologging 으로 생성하자.

추가 테스트 필요 사항
heap table / IOT table / Partitioned IOT 에 DML (insert/update/delete모두) 을 발생시킬 때 redo/undo 의 양


Posted by maceo

12 26, 2008 18:18 12 26, 2008 18:18
Response
No Trackback , No Comment
RSS :
http://merritt.co.kr/tt/rss/response/126

PX COORDINATOR FORCED SERIAL 이 뜰 경우

병렬 쿼리에서 FORCED SERIAL 이 뜨면서 병렬로 실행이 못되는 경우가 있다.

이럴 때는 쿼리에서 쓰인 Stored Function 을 의심해보자.

Function 중에 parallel_enable 이 되어 있지 않은 놈이 있다면 parallel_enable 을 붙여준다!

자세한 것은 포이어슈타인의 오라클 PL/SQL 프로그래밍을 참조!!!


Plan Table                                                                 
----------------------------------------------------------------------------
| Operation                                 | Name                         |
----------------------------------------------------------------------------
|  PX COORDINATOR FORCED SERIAL             |                              |
|   PX SEND QC (RANDOM)                     |:TQ10010                      |
|    FILTER                                 |                              |
|     HASH GROUP BY                         |                              |
|      PX RECEIVE                           |                              |
|       PX SEND HASH                        |:TQ10009                      |
|        HASH GROUP BY                      |                              |
|         HASH JOIN RIGHT OUTER             |                              |
|          BUFFER SORT                      |                              |
|           PX RECEIVE                      |                              |
|            PX SEND BROADCAST              |:TQ10000                      |
|             VIEW                          |                              |
|              SORT GROUP BY                |                              |
|               TABLE ACCESS BY GLOBAL INDEX|TR_ORD_PRD                    |
|                INDEX RANGE SCAN           |IX5_TR_ORD_PRD                |
|          VIEW                             |                              |
|           HASH GROUP BY                   |                              |
|            PX RECEIVE                     |                              |
|             PX SEND HASH                  |:TQ10008                      |
|              HASH GROUP BY                |                              |
|               HASH JOIN RIGHT OUTER       |                              |
|                PX RECEIVE                 |                              |
|                 PX SEND HASH              |:TQ10006                      |
|                  PX BLOCK ITERATOR        |                              |
|                   TABLE ACCESS FULL       |MB_PRVT_MEM                   |
|                PX RECEIVE                 |                              |
|                 PX SEND HASH              |:TQ10007                      |
|                  HASH JOIN RIGHT OUTER BUF|                              |
|                   PX RECEIVE              |                              |
|                    PX SEND HASH           |:TQ10004                      |
|                     PX BLOCK ITERATOR     |                              |
|                      TABLE ACCESS FULL    |MB_MEM_MG_GR                  |
|                   PX RECEIVE              |                              |
|                    PX SEND HASH           |:TQ10005                      |
|                     HASH JOIN RIGHT OUTER |                              |
|                      PX RECEIVE           |                              |
|                       PX SEND HASH        |:TQ10002                      |
|                        VIEW               |                              |
|                         HASH UNIQUE       |                              |
|                          WINDOW SORT      |                              |
|                           PX RECEIVE      |                              |
|                            PX SEND HASH   |:TQ10001                      |
|                             PX BLOCK ITERA|                              |
|                              TABLE ACCESS |MB_MEM_HIST                   |
|                      PX RECEIVE           |                              |
|                       PX SEND HASH        |:TQ10003                      |
|                        PX BLOCK ITERATOR  |                              |
|                         TABLE ACCESS FULL |MB_MEM                        |
----------------------------------------------------------------------------

Posted by maceo

12 18, 2008 22:22 12 18, 2008 22:22
, ,
Response
No Trackback , No Comment
RSS :
http://merritt.co.kr/tt/rss/response/124

pga_aggregate_target은 limit 이 아님


아무리 pga_aggregate_target 을 정해놓더라도 빡센거 돌면 그거 넘어서서 PGA 할당한다.
over allocation 가능하다는 말씀. 그러면 얼마나 할당할 수 있느냐? Oracle 버전에 따라 다르다. 아래 링크 참고

http://www.pythian.com/documents/Working_with_Automatic_PGA.ppt

Five Tuning Tips For Your Data Warehouse 

기타 여러가지 좋은 팁들이 많다...

Posted by maceo

12 18, 2008 19:49 12 18, 2008 19:49
,
Response
No Trackback , No Comment
RSS :
http://merritt.co.kr/tt/rss/response/123

« Previous : 1 : 2 : 3 : 4 : 5 : ... 8 : Next »

블로그 이미지

가늘어도 긴놈이 장땡

- maceo

Archives

Authors

  1. maceo

Calendar

«   3 2010   »
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31      

Site Stats

Total hits:
170287
Today:
31
Yesterday:
47