오라클 SYSTIMESTAMP 사용시 버그 일까요?

Question

BEGINSELECT CASE WHEN V_OPTN_VAL &#61; 'BR' THEN'C' || TO_CHAR(SYSTIMESTAMP,'YYYYMMDDHH24MI') || LPAD(SEQ_GUINUM.NEXTVAL,5,'0') WHEN V_OPTN_VAL &#61; 'SL' THEN'C' || TO_CHAR(SYSTIMESTAMP,'YYYYMMDDHH24MI') || LPAD(SEQ_GUINUM.NEXTVAL,5,'0') WHEN V_OPTN_VAL &#61; 'PC' THEN'C' || TO_CHAR(SYSTIMESTAMP,'YYYYMMDDHH24MI') || LPAD(SEQ_GUINUM.NEXTVAL,5,'0')ELSE'C' || TO_CHAR(SYSTIMESTAMP,'YYYYMMDDHH24MI') || LPAD(SEQ_GUINUM.NEXTVAL,5,'0')ENDINTO V_GUINUMFROM DUAL ;END;주문 번호를 채번하는 프로시저 일부 입니다.여기서 문제인데요... 년월 시분 SEQC20231114 2119 66915C20231114 2120 6690366903 이 먼저 주문을 했는데 시간을 보면 21시20분 으로 66915 보다 늦게 주문한 것 처럼 보입니다.시퀀스는 제데로 채번이 되었는데 날짜가 문제입니다.( 66903 실제 저장시간은 21시18분. )이런 경우는 어떻게 봐야할까요...저는 아무리 봐도 원인분석이 안되어서 도움 요청 드립니다.. ㅠ

족발개발자z · Answer

등록 하니까 정렬이 지멋대로 되네요...보기 불편한 점 죄송합니다.

최은영 · Answer

먼가 다른 로직이 있는건 아닌가요?말이 안되는데요...18분에 저장이 됬는데 주문번호엔 20분이라뇨..주문을 수정 할 수 있는 로직이 있다는 가정밖엔 생각이 안나네요..

옥다방고양이 · Answer

✅️로직상 문제될것이 전혀 없는것 같습니다.✅️INTO V_GUINUM FROM DUAL;부분의바로 뒤에DBMS_OUTPUT.PUT_LINE('V_GUINUM&#61;' V_GUINUM)찍어서 값을 다시 한번 더 검증해보세요.

allinux · Answer

본문 내용만으론 알 수 없으나 commit 시간을 주문시간이라고 저장한다면 먼저 주문에 들어갔으나 어떤 문제로 lock 에 걸리고 늦은게 먼저 commit 할 수도 있을 듯 합니다. 여러가지 가능성중 하나입니다.

꼬꼬마져니 · Answer

시퀀스의 ORDER 옵션 확인 하셔요.시퀀스의 기본 동작 메카니즘을 먼저 보시기 바랍니다.https://docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf/CREATE-SEQUENCE.html#GUID-E9C78A8C-615A-4757-B2A8-5E6EFB130571

족발개발자z · Answer

DB 세팅 부분에서 해답을 찾았습니다.운영 환경에서 2개의 DB가 세팅 되어있는데 실제 1,2번 DB의 서버 시간을 확인해보니 2번 DB의 시간이 2분정도 느리네요.답변 주신분들 감사합니다.

오라클 SYSTIMESTAMP 사용시 버그 일까요?

6개의 답변

Q&A 목록