본문 바로가기
반응형

TechNical/Oracle47

누적형 코드 데이터를 계층으로 조회 대중소 코드가 누적되어서 들어가 있는 코드 분류체계라면 connect by 를 통해서 계층형으로 조회하는 SQL은 아래와 같이 만들 수 있다,WITH TBL_DATA AS (SELECT 'L' AS DEP, '1' AS CD, '동물' AS CD_NM FROM DUALUNION SELECT 'M' AS DEP, '10' AS CD, '포유류' AS CD_NM FROM DUALUNION SELECT 'M' AS DEP, '11' AS CD, ' 어류' AS CD_NM FROM DUALUNION SELECT 'S' AS DEP, '1001' AS CD, '곰' AS CD_NM FROM DUALUNION SELECT 'S' AS DEP, '1101' AS CD, '고등어' AS CD_NM FROM DUALUN.. 2025. 4. 8.
최근 날짜를 가진 목록 조회하기 최근 날짜를 가진 목록을 조회하려면 MAX 날짜를 가져와야 한다.DATE1에 인덱스가 있다면 아래와 같이 하면 되지만 SELECT * FROM TABLE1WHERE (KEY1, DATE1) IN (SELECT KEY1, MAX(DATE1) FROM TABLE1 WHERE COND1 = :cond1 GROUP BY KEY1) 인덱스가 없으면 상당히 속도가 느리다.그럴때는 RANK 로 가져오는게 성능이 더 좋다. SELECT * FROM ( .. 2025. 3. 30.
[튜닝] 불필요한 정렬 제거 페이징 처리로 조회되는 SQL이 데이터 양에 따라서 속도가 심하게 차이가 날때는 order by가 PK로 정렬하고 있다면 제거하면 엄청 빨라진다. 조인 걸리는 PK가 인덱스가 기본적으로 정렬이 되기 때문에 PK순서로 보고자 한다면 빼도 같은 순서로 나온다. 건수가 적은 테이블이 먼저 걸리지 않는다면 작은 순서대로 가져오게 /*+ LEADING(A) */ 힌트를 붙여 주자. 2019. 5. 24.
오라클 DBLINK 하면 ORA-01017: invalid username/password; logon denied 오류 충격적인 걸 알려주마.. 뭐 알고 있다면 아주 간단한 문제겠지만 모르면 정말 황당하다 못 해 짜증이 날 만한 문제. 오라클 9i에서 11g로 DBLINK를 걸때 이런 문제가 발생해요. 기존에 쓰던 DBLINK가 있습니다. 상대방 시스템이 업그레이드 되면서 버전업이 되었지요. IP는 변경됐지만 기존에 쓰던 DB 계정의 패스워드는 그대로 입니다. tnsping 때려 보면 아주 잘 날아 갑니다. DBLINK를 생성할때도 아주 잘 생성 됩니다. sqlplus로 붙어도 매우 잘 붙습니다. 근데 막상 DBLINK를 사용 하려고 하면 이런 오류를 뱉어 냅니다. > select * tab@test_dblink ORA-01017: invalid username/password; logon denied ....??? 이게.. 2011. 9. 18.
MERGE INTO 를 사용해 봅시다. 테이블을 조회해서 해당 조건으로 데이터가 존재하면 업데이트 하고 없으면 쑤셔 넣는다는 똑똑한 녀석이다. 실제 쿼리문에서 테이블명이랑 컬럼명만 임의로 막 변경한 거라서 대충 흐름만 보도록 하자. 잘 보다보니 이 놈을 이용해서 시퀀스 넘버도 가져와서 넣을 수 있다. 좋다. ON 부분에는 다중 조건을 쓸 수 있다. UPDATE나 INSERT를 할때 USING 문에서 뽑아온 값으로 넣을 수도 있다. MERGE INTO seq_table f USING ( select col1, col2, col3, col4, col5 , (select max(sqno) + 1 from seq_table x where t.col1 = x.col1 and t.col2 = x.col2 ) as seqno from base_table .. 2010. 9. 17.
각 그룹 금액의 합의 비율금액의 합계 쿼리.... 뭐야 -_-;; 여차저차 하여 비율에 따라 그룹의 합을 구하고 각각 그룹의 금액 * 비율 한 금액의 합을 구하는데 그 총계만 가져와야 할 일이 생겼었다. 비율 금액 10 100 10 200 10 300 20 100 20 300 이런 데이터라면 10 600 20 400 이렇게 그룹이 지어지고 600 * 0.1 = 60 400 * 0.2 = 80 요거의 합 60 + 80 = 140 이렇게 나와야 하는 경우다. 혹자는 이렇게 의문을 가질 수도 있다. 각각의 비율 금액을 계산해서 걍 더하면 되지 않느냐고..?? 좋다. 근데 이게 소수점을 안 가지고 있고 절사 금액 이라면 1, 10 단위의 오차가 발생한다. 뭐... 어떤 용도로 사용하고 계산법은 어떻게 나와야 하느냐에 따른 문제지만 참 거지 같다 -_- 그래서 이런 쿼리가 나왔.. 2010. 9. 17.
distinct 때메 생긴 그지같은 오라클 쿼리 에러 -_- select 절에 컬럼 하나를 더 가져오게 변경을 했다. 그랬더니 이런 에러가 뜬다... ORA-01791: SELECT 식이 부적합합니다 .... 어쩌라고 -_- 참 난감하고도 난감한 에러다. 조회 컬럼을 distinct를 제외하고 * 로 바꾸니까 order by 절에 태클을 건다.. 음.. 근데 이상하군. 테이블의 컬럼이 아닌 별칭을 걸어 논 것이 었다.. 그렇군. 각설하고 결론은 distinct를 사용 했을 경우 order by 절에 기술된 컬럼이 select 절에 나와야 한다는 것이더라. 만약에 별칭을 사용 했다면 그 별칭을 order by 절에 써 주면 된다. 끝!!! .. 야심한 밤에 이게 뭔 짓이야.. 아.. 슬프다 -_- 2010. 8. 27.
GROUP BY 절에 DECODE로 된걸 SELECT 절에서 스칼라로 써 먹을 순 없나? group by 에 decode로 들어 간걸 select 절에서 스칼라 쿼리로 써 먹을 수 음나? 라는 문제에 봉착하게 됐다.. 말이 상당히 난해하다. 예제를 보도록 하자. WITH tb1 AS ( SELECT 'A' AS c1 , '1' AS c2 FROM DUAL UNION ALL SELECT 'A' AS c1 , '1' AS c2 FROM DUAL UNION ALL SELECT 'B' AS c1 , '1' AS c2 FROM DUAL UNION ALL SELECT 'C' AS c1 , '1' AS c2 FROM DUAL ), tb2 AS ( SELECT 'A' AS c1 , '곰' AS c2 FROM DUAL UNION ALL SELECT 'B' AS c1 , '개' AS c2 FROM DUAL U.. 2010. 4. 29.
LEFT OUTER JOIN 성능. 꼭 필요할 떄만 쓰자~ LEFT OUTER JOIN을 동일한 테이블을 조건만 다르게 해서 여러게 붙여 놓은 쿼리가 있었다. 속도가 겁니 느려서 분산된 LEFT OUTER JOIN 을 하나로 빼고 해당 테이블에서 다른 조건들은 SELECT 문에서 DECODE나 CASE문으로 빼니까 성능이 좋아진 경우가 있었다. 플렌을 떴을 경우 별 차이는 없었지만 실제 실행 속도는 차이가 많았다. 이에 따라 LEFT OUTER JOIN 의 성능이 어떤가 하고 찾아보니 아래와 같은 TIP을 발견 했다. If you have a query that uses a LEFT OUTER JOIN, check it carefully to be sure that is the type of join you really want to use. As you may.. 2010. 3. 17.
WITH 문에서 테이블을 두개 맹글어 보자. 원래 WITH문 이게 메인이 아닌데.. GROUP BY에 대한 고찰이었음.. =ㅅ= 마땅한 제목이 없어서. ㅋㅋㅋㅋㅋ 1. 테스트 테이블 생성 WITH tb1 AS ( select 'A' as k1 , 1 as qty from dual union all select 'B', 2 from dual union all select 'B', 3 from dual union all select 'C', 1 from dual ), tb2 AS ( select 'A' as b1 , '나무' as b2 from dual union all select 'B', '문어바' from dual union all select 'B', '꼬라바' from dual union all select 'C', '거북이' from dua.. 2009. 3. 13.
거지같은 CLOB 이랑 안면 트기... VARCHAR2 타입은 최대 길이가 4000byte 로 정해져 있다. 데이터가 4000바이트가 넘어가면 에러를 뱉어 낸다. 그런데 데이터라는 것이 4000 바이트로 성이 찰 리가 없다. 그래서 생겨난것이 CLOB 타입 인데... 4000 바이트를 넘어가니까 어쩔 수 없이 CLOB을 쓰긴 써야 되는데 이놈이 여간 거지 같은게 아니다. CLOB은 다른 애들이랑 어울리길 거부한다. 당연한 것이.. 타입이 틀리니까 .. NUMVER랑 CHAR랑 틀린거.. 뭐 똑같은 거다.. 근데 문제는 .. 이 놈은 타입케스팅이 거지 같다는 거다. 내가 잘 몰라서 그러겠지만.. 안 되는거 같다.. TO_LOB... 개나 줘라 그래 ㅡㅡ NVL은 되면서 DECODE, COALESCE는 까칠하게 싫다고 한다.. WHERE 절에 들.. 2008. 12. 8.
한 테이블의 모든 컬럼 업데이트 칠 때 오늘은 엄청 어려운 걸 해 볼 작정이다. 하하하하하 TEST 테이블에 NAME 컬럼 값이 있다고 치자. 이 놈이 원래는 char 형 타입이라서 10자리로 고정이 되어 있었다. 근데 이 놈을 마이그레이션 하면서 varchar2 타입으로 바꿔서 넘겼다. 아니 글쎄 그랬더니 이 놈이 우측에 공백이 다 붙어 있는 것이 아닌가!! 그래서 조회를 할 때 name = search_value 이런 식으로 찾으면 매치가 안 되는 것 이다. 그도 그럴 것이 공백도 문자로 인식하니까 안 맞을 수 밖에.... 얄팍하게 like 'search_value%' 이런식으로 찾을 수 있겠지만.. 이건 아무리 봐도 허접하다. 데이터는 무조건 맞춰야 한다. 자.. 그럼 update문을 어떻게 작성할 것 인가?!?!?!?!?!? 쉬울 것 .. 2008. 11. 24.
반응형