Talk Lowy(kr)

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 into 는 delete + insert이기 때문에 default 필드 또는 auto_increment 필드는 신규 로우를 추가한 것과 같은 영향을 받음. giip :: Free mixed RPA orchestration tool!  https://giipasp.azurewebsites.net/

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

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