Talk Lowy(kr)

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

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

SSMS(Sql Server Management Service)툴에서 제공하는 간단한 모니터로 대부분의 성능 이슈를 잡아낼 수 있다.  https://serverfault.com/questions/578533/ms-sql-server-getting-overloading-with-suspended-queries-mostly-reads-any-wa 일단 정리 용... giip :: Free mixed RPA orchestration tool!  https://giipasp.azurewebsites.net/

Insert into ~ on duplicate key update INSERT   INTO  tableA (sn, cateid, catename)  VALUES     ( 101 ,  'A001' ,  'CateA1' ),     ( 102 ,  'B001' ,  'CateB1' ),     ( 103 ,  'C001' ,  'CateC1' ),     ( 104 ,  'C002' ,  'CateC2C' ), ON  DUPLICATE  KEY   UPDATE  catename = ( CASE   WHEN  catename =  'C002'   THEN  catename  ELSE   values (catename)  END ); replace REPLACE   INTO  tableA (sn, cateid, catename)  VALUES     ( 101 ,  'A001' ,  'CateA1' ),     ( 102 ,  'B001' ,  'CateB1' ),     ( 103 ,  'C001' ,  'CateC1' ),     ( 104 ,  'C002' ,  'CateC2C' ); on duplicate key update의 경우 기존 row에서 update를 하지만,  replace in...

DBMS의 튜닝의 70% 이상은 SQL튜닝과 Index튜닝으로 해결 됩니다. 하지만 예외적인게 조금 있지요. 얼마 전에 옆에서 이상하게 속도가 느려진 쿼리가 있어서 봐달라고 쿼리를 보여주었습니다. 힌트를 주어 강제로 인덱스를 태우고 있었습니다. 이 힌트는 왜 주었냐고 물어보니 원래 그렇게 되어 있어서 사용중이었다고 합니다. 아마 초기에 만든 사람이 사라지고 그냥 그 동안 문제 없이 쓰고 있었던 것 같네요. 그냥 잘 모르면 힌트를 없애고 돌려보세요. 라고 가이드를 했더니 3초 이상 걸렸던 쿼리가 0.01초로 끝났습니다. 이유는 뭘까요? 대부분의 인덱스는 초기 개발자가 개발하면서 만든 인덱스 외에는 나중에 추가 되는 경우가 많지 않습니다. 대부분 한 번 만들면 그게 최적이라고 생각하는 경우가 대 부분이고, 지금 처럼 초기에 만든 사람들이 사라지고 물려받은 사람들은 이유를 모르고 사용하는 경우도 있습니다. 테이블 설계시의 예상 데이터 축적량을 보고 아무리 DB 전문가가 Index를 걸어준들 사용자의 성향이나 시대에 따라 데이터는 전혀 달리 쌓이게 되는게 보통입니다. 예를 들어, 한국형 게시판은 대 부분 글이 많고 댓글이 적은 편입니다. 이유는 튀기 좋아하는 한국인들은 자기가 돋보여야 하기 때문에 댓글에 달 글 조차도 글쓰기로 올라와서 많은 사람들이 보게 하길 원하는 경우가 많기 때문이지요. 하지만 이 게시판으로 일본에서 서비스를 해보면 글은 얼마 안올라오는데 댓글이 수천에서 수만개가 쌓입니다. 즉 유저의 성향에 따른 데이터의 편중이 달라지는데, 이 때 게시글 옆에 댓글을 카운트 하는 경우 subquery를 이용해서 카운트 하는 경우도 많고, group by 를 이용해서 한 번 카운트 한 댓글 통계를 join하는 경우도 있습니다. 전자의 경우는 댓글 수가 적은 한국에서는 좋은 쿼리이나, 댓글이 너무 많아진 일본에서는 group by에 비해 많은 양의 카운트를 nested loop로 처리하게 되므로 효율이 많이 떨어집니다. ...

해킹 또는 데이터의 변조등 이상한 문제가 발생했을 때 가장 먼저 훑어보는 System View이다. 이외에도 퍼포먼스 튜닝을 하려는데 개발쪽에서 모든 쿼리를 주지 않은 경우 훑어볼 경우도 사용하곤 한다. 최근에 일어났던 SQL의 내용을 모두 볼 수 있다는 것이 장점이고, SQL을 실행시킨 사람이나 시간을 볼 수 없다는 것이 단점이다. 우선 여기서 의심스러운 쿼리들을 훑어낸 뒤에 이것을 이용하여 Profile을 한다거나 여러가지 액션을 취할 수 있다. 아래는 syscacheobjects뷰의 생성쿼리이다. 기본적으로 생성되어있지만, 참조되는 테이블을 확인할 때 쓰기위해 적어놓는다.