Talk Lowy(kr)

영상버전 :  https://youtu.be/iTmkJ2iWJuU 지금 프로젝트에서 개발자들이 프로시저를 만들다보니  개발자의 의식의 흐름대로 데이터 처리를 만들다보니 커서를 이용해서 테이블 변수에 넣고  그걸.  변수로 다른 테이블에서 조회하는 식으로 짜놨네요..  튜닝할 때 항상 하는 이야기 이죠.. Trigger와 커서는 절대 쓰지 말라구요..  이것처럼 속도를 저하시키고 락을 유발 시키는 장치는 없거든요..   트리거는 트리거링 포인트가 되었을 때 대상 테이블을 락을 건 뒤에 트리거 처리를 하고 나서 락을 해제 하기 때문에 아무리 빨리 끝나도 동시에 들어오는 쿼리에 따라서는 데드락에 빠질 가능성도 있습니다.   마찬가지로 커서 역시 테이블을 열고 커서를 만들어 처리하기 때문에 그 모든 처리가 끝날 때까지 락이 걸린 상태가 됩니다. 데이터가 변동하면 안되니까요..  그래서 트리거와 커서를 사용하면 기본 서너배는 느려집니다.  커서랑 트리거만 없어도 50만명 받을 서비스가 15만명도 못받게 되는거죠.. 경우에 따라서는 수백배 느리게 짤 수도 있는게 커서와 트리거 입니다. 그냥 서비스를 떨구든 말든 자기 편한대로 만들겠다는 생각이 있지 않는한 커서는 피하셔야 합니다.   개발자들이 커서를 많이 이용하는 이유는 커서를 이용해서 만들면 복잡한 처리를 할 때 별로 생각하지 않고 개발 코드처럼 만들어도 가능하기 때문이죠  이번 쿼리도 커서를 사용해서 아주 길게 만들어놨네요..   한 줄 읽어서 상태에 따라서 데이터를 매핑해서 테이블 변수에 넣고를 쭈욱 한 뒤에  그 테이블 변수를 다시 읽어서 다른 테이블의 값을 가져오는데..   튜닝을 잘하려면 이 모든 데이터가 머리속에 연결구조를 그려서   하나의 비정규화 된 배열을 만들 수 있어야 합니다.   매번 이야...

영상버전 :  https://youtu.be/VO7eNgFAGDA 2주 째에 들어왔습니다.  업무시간 8시간 중에 거의 5~6시간은 화상회의를 켜놓고 하게 되네요.  너무 지치는군요..  지난 번 프로젝트가 너무 널럴해서 그랬나봐요..^^;;;  한국과 조금 다른 것은  모두들 발언을 신중히 하기 때문에 말은 많지 않으나,  그 사람들의 말이 정말 이런 이유인지 아니면 다른 원인으로 인한 것인지를 찾는데 신경을 쓰다보니  더 빨리 피곤해지는데요..  지금은 TiDB 잘한다는 사람이 앞단의 교통정리를 헤주고 있으니 잘 하겠죠.  정말 잘할지는 모르겠으나 월권은 귀찮으니.. 하다가 폭탄 만들면 프로젝트를 뜨는 걸로..  SES는 SI와는 달리 프로젝트가 맘에 안들면 언제든 뜰 수 있는게 부담 없어 좋습니다.  리더를 해도 내가 합당한 이유를 우리쪽 영업에게 이야기 하면 빼주거든요..  요즘처럼 사람이 부족한 시기는 고를게 많아서  아무리 비수기라 해도 사람이 부족해 뒤늦게 가격 올려서 구인 하는 경우도 있어요.    첫주엔 27분기 총회가 있어서 참여를…  잊어먹고, 나중에 녹화방송을 봤습니다.  사원은 지금 마구 뽑아서 200명이 되었는데.. 3년 전에 수십억엔 매출이 2년전에 850억, 작년에 1850억엔이었네요..  레드오션이라는 화장품 시장에서 스타트업이 이 정도 수직상승이 가능…하네요..  여기 정사원들은 나중에 스톡 받겠네요…좋겠다…^^;;;  그건 그렇고..  이번주에 기억나는게 두 가지 있었는데요..  하나는 sql server의 리플리케이션이 끊어져 다시 걸어달라는 내용이었습니다.  얘네들은 부하가 너무 커져서 8대의 리플리케이션용 디스트리뷰터 조차 따로 두어서 마스터의 부하를 최소한으로 운영한건 좋었는데.. 마스터의 HA구성으로 대기용 ...

영상버전 :  https://youtu.be/OaDuZvE1ViQ 7월 1일부터 참여한 젊은 화장품 판매 기업의 DB이전 프로젝트 입니다.  연매출 2000억엔에  오프라인 제휴 매장 포함 26개 라던가요? 사원은 200명..  온라인 구치코미를 분석해서 잘팔리는 제품의 순환이  이 기업의 핵심가치 같네요.  때문에 가장 중요한 것은 구치코미 데이터인 듯 합니다.  여기서  구치 는 입이고  코미는 코뮤니티의 앞글자 입니다.  그래서  사람들의 말을 모아놓은 커뮤니티를 말하는 것이지요.  우리말로 하면 평점 같은 느낌이려나요? 일본의 구치코미는 한국만큼 오염되진 않아서 돈으로 매수한 것도 좀 있긴 하지만,  지나치지 않게 하는 것 같습니다.  때문에 구치코미에 대한 신뢰는 아주 크구요.  이 프로젝트의 가장 큰 문제는  회의가 너무 많다!  그냥 하루에 세 번 미팅은 기본이고,  전 서너번이 보통인데,  정사원들은 작업 시간이 하루에 한 두시간이고  나머진 전부 미팅인 거 같네요..  그리고 티켓 시스템이 다섯 종류..  각 부서마다 자기네 티켓 시스템을 따로 쓰기 때문에  레드마인에서 처음보는 시스템까지 골고루 사용 중입니다.  가장 크리티컬한 것은..  SQL 서버를 사용하고 TiDB 이관을 하기로 했는데,  모든 멤버가 SQL 서버와 TiDB를 잘 모르는 것입니다.  유저의 급증으로 인해 SQL서버가 자주 뻗는대요..  그래서 TiDB로 변경하면 대규모 OLSP랑 OLAP 처리가 가능하다는 영업(?)에 넘어가서  TiDB TF팀을 결성해서 순차적으로 이동 중이라고 합니다.  현재 가장 부하가 적은 MySQL의 테이블 두 개를 이동하고,  조금 용량이 큰 데이터를 이동 중에 성능 이슈가...

영상버전 :  https://youtu.be/yrYdv_4vy6Y 데이터베이스 튜닝에 자신 있으신 분들은 한 번 보시고 자신의 위치라던가,  제가 잘못 알고 있다고 생각하는 분들은 자유롭게 태클 부탁 드립니다.  오히려 제가 모르는 튜닝 기법을 가르쳐주시는 분들은 대환영입니다.  세상에는 저도 손을 절레절레하는 레벨의 튜닝도 있더라구요..  세상은 넓고 고수는 많은 것 같습니다.  데이터베이스 튜닝은 쿼리 튜닝 및 Index tuning만으로 약 70%가 해결됩니다.  그리고 나머지 25%가 전문가라 불리는 사람들이 자신만의 노우하우로 튜닝하는 영역이구요,  마지막 5%가 하드웨어나 OS의 기저 레벨에서 튜닝하는 영역이라고 보시면 됩니다.   그러므로 대부분의 튜닝은 70%에서 거의 해결하기 때문에  실력의 차이가 많이 나지 않습니다.  우선 70%에 해당하는 기초적인 튜닝을 조금 언급하고,  그 나머지 30%의 튜닝에 대해서는 재미난 일화를 중심으로 다루어보겠으니  많은 정보를 받아가시기 바랍니다.  튜닝의 기초 부터 시작해 봅니다. 1. 쿼리튜닝 및 Index 튜닝 쿼리튜닝이나 Index tuning은 많은 영상에서 다루는 듯 하지만 그 다루는 분들과 다른  영역을 위주로 알려드리겠습니다.  대부분 쿼리 튜닝이나 인덱스 튜닝을 위해서는 어디부터 보시나요?  저의 경우는 프로파일 또는 쿼리 캐시 영역을 들춰봅니다.  보통 리얼타임 프로파일링에서는 1년에 한 번 또는 비주기로 던지는 복잡한 쿼리는 보이지 않는 경우가 많습니다.  RDBMS는 쿼리 통계를 기반으로 인덱스를 자동으로 타기 때문에 이를 위해서 RDBMS가 쿼리 캐시 영역이란 것을 가지고 있는데, 그 곳을 털면 이 RDBMS에서 사용하는 대부분의 쿼리를 알 수 있습니다.  심지어는 해커가 Query Injectio...

듣기 버전 :  https://youtu.be/gee37PXME2E?si=F3hsUPq9ptJ-Uidz DB 전문가가 이야기 하는 DBMS선택 방법..  많은 개발자 분들이 DBMS선택 방법에 대해서 동영상을 올려드리는데,  DBMS엔진에 대해 정확하게 알지 못하는 상태에서 개략적인 정보만으로 올리시는 분들이 많은 것 같아서 오히려 DBMS를 선택하는데까지의 충분한 도움이 안되는 것 같아서 DB전문가가 DB를 선택하는 방법을 알려드리겠습니다.  만약 DB전문가라는 사람이 당연히 오라클이죠.. 라던가 MySQL만큼 좋은게 없어요 라던가 하나만 밀고 있는 사람이라면 그 사람은 DB전문가가 아니라 그 제품 하나만 알고 있는 평범한 사람이라고 보시면 됩니다.  다양한 RDBMS의 특징을 모르면 뭐가 왜 좋은지 알 수 없잖아요.. 그리고 상황 및 데이터 타입 등등 다양한 환경에 따라 달라지는데 하나만 최고가 될 수가 있나요?  제가 있던 시절의 RDBMS는 DBase(HBase아님), Cybase, Infomix등등 다양한 RDBMS가 판치던 시절이었습니다.  이 때에는 Index 알고리즘도 B-Tree index뿐만 아니라 Bitmap index도 있었지요.  Bitmap index는 Cardinality가 낮은 데이터, 즉 1 이나 0 처럼 종류가 적을 수록 속도가 빠른 인덱스도 있었으나,  대부분의 데이터가 Cardinality가 높은 경우가 많아져 SQL Server도 6.5부터는 B-Tree index를 사용하게 되었지요.  그래서 MySQL, SQL Server, ORACLE등의 메이저 RDBMS의 엔진 성능도 엇비슷해 진 듯이 보입니다..  많은 곳에서 MySQL이 최고라면서 증거를 들이밀고, SQL서버가 최고라면서 데이터를 들이미는 곳이 있는가 하면 ORACLE이 최고라면서 발표하기도 합니다.  다들 거짓말을 하는 걸까요?  아닙니다! 그들이...

Oracle의 관리 툴은 대부분 비용이 비싸서 가급적 무료툴로 관리를 한다. 그러다보면 기능들이 부족해서 SQL로 해결해야 하는 것들이 생기는데, 그 중에서 많이는 사용하지 않으나 있으면 관리하기 편한 하나가 바로 테이블이나 Procedure의 생성쿼리 이다. Oracle에서는 기본으로 제공해주는 쿼리이므로 주기적으로 select * from all_tables where owner = '<owner>' 로 테이블 명을 가져와서 아래 쿼리로 테이블 생성 쿼리를 업데이트 해주면 변경이력 관리가 필요없게 된다. select dbms_metadata . get_ddl ( ' TABLE ' , ' TableName ' , ' Owner ' ) from dual; select dbms_metadata . get_ddl ( ' Procedure ' , ' ProcedureName ' , ' Owner ' ) from dual; 추가로 Procedure작성쿼리도 추가함.. select * from all_objects 로 검색해서 Procedure나 Function도 가져오면 편할 듯.. Do not login your server any more! giip :: Free server management tool! https://giipasp.azurewebsites.net/

처음에 시작된 것은 NFS로 연결된 REDO LOG파일이 사라진 것인데.. 왜 REDO LOG를 NFS마운트에 올렸는지도 궁금하지만.. (아마 용량이 부족해서 이렇게 일시적으로 한 듯..) NFS는 끊어졌는데 그 원천 서버의 디스크가 날라가서 OS재설치하면서 REDO LOG파일이 사라졌다. 더 큰 문제는 REDO LOG 파일이 CURRENT로 지정된 데다가 파일이 하나밖에 설정되어 있지 않다. 이로서 불가능한 옵션은 ALTER DATABASE ADD LOGFILE MEMBER '/mnt/sdb1/redolog/redo05.log' TO GROUP 5; 기존 파일이 없댄다.. ALTER   DATABASE   DROP  LOGFILE GROUP  5 ; 파일이 없어서 삭제 안된단다.. ALTER   DATABASE  ADD LOGFILE GROUP  6 ; 신규로 그룹을 추가 했다.. 성공.. 이제 바꾸고 싶다.. alter  system  archive  log  current; 안된단다.. select  *  from  v$logfile; 이걸로 없어진 파일은 보이는데.. 이걸 빼고 다른걸로 바꿀 방법이 없다. ALTER DATABASE    RENAME FILE '/NFS/app/oracle/oradata/smartdb/redo05.log'            TO '/mnt/sdb1/redolog/redo05.log'; 이렇게 이름을 바꾸어 봤다. 이름은 바뀐다....