Oracle에서 Timestamp_to_scn 및 Scn_to_timestamp를 사용하는 방법은 무엇입니까?

Oracle에서 Timestamp_to_scn 및 Scn_to_timestamp를 사용하는 방법은 무엇입니까?

쿼리 결과 다음과 같이 확인되었습니다.

select cast(to_date(a.start_time,'mm/dd/yyyy hh:mi:ss pm') as timestamp) date_of_call,
ora_rowscn from calling_table a where rownum <= 10;

       DATE_OF_CALLING          ORA_ROWSCN

26-JUL-13 12.29.28.000000000 PM 8347567733892
26-JUL-13 12.29.35.000000000 PM 8347567733892
26-JUL-13 12.29.35.000000000 PM 8347567733892
26-JUL-13 12.29.38.000000000 PM 8347567733892
26-JUL-13 12.29.44.000000000 PM 8347567733892
26-JUL-13 12.29.47.000000000 PM 8347567733892
26-JUL-13 12.29.48.000000000 PM 8347567733892
26-JUL-13 12.29.48.000000000 PM 8347567733892
26-JUL-13 12.29.48.000000000 PM 8347567733892
26-JUL-13 12.29.56.000000000 PM 8347567733892

그러나 timestamp_to_scn 함수를 사용하여 이 타임스탬프를 scn으로 변환하려고 하면 다음 오류가 발생합니다.

ORA-08180: 지정된 시간을 기준으로 ORA-06512: "SYS.TIMestamp_TO_SCN", 라인 108180.00000에서 스냅샷을 찾을 수 없음 - "지정된 시간을 기준으로 한 스냅샷을 찾을 수 없음" *원인: 매핑 테이블의 SCN과 시간을 일치시킬 수 없습니다.*행동: 더 큰 시간을 사용해 봅니다.

또한 scn_to_timestamp on 또는 a_rowscn을 사용하여 해당 열을 타임스탬프로 변환할 때 다음 오류가 발생합니다.

ORA-08181: 지정된 번호가 유효한 시스템 변경 번호가 아닙니다. ORA-06512: "SYS.SCN_TO_TIMESTamp", line 1081.00000 - "지정된 번호는 유효한 시스템 변경 번호가 아닙니다." *원인: 제공된 scn이 유효한 scn의 범위를 벗어났습니다.*조치: 유효한 scn을 사용합니다.

내가 뭘 잘못하고 있는 거지?

당신은 너무 먼 과거를 보려고 합니다.시스템에서 유지 관리하는 redo/flashback 창에 있는 SCN으로만 변환할 수 있습니다.변경 내용이 만료되면 매핑이 손실됩니다.

이에 대한 설명은 설명서에 나와 있습니다.

SCN이 생성될 때 SCN과 타임스탬프 간의 연결은 제한된 시간 동안 데이터베이스에 의해 기억됩니다.이 기간은 데이터베이스가 자동 실행 취소 관리 모드에서 실행되는 경우 자동 조정된 실행 취소 보존 기간의 최대 기간이며 데이터베이스에 있는 모든 플래시백 아카이브의 보존 시간은 120시간 이상입니다.데이터베이스가 열려 있을 때만 연결이 더 이상 사용되지 않는 시간이 경과됩니다.인수에 대해 SCN이 지정된 경우 오류가 반환됩니다.SCN_TO_TIMESTAMP너무 오래되었습니다.

이러한 기능은 Oracle 내부 메커니즘의 일부이므로 당사에서는 제한적으로 사용할 수 있습니다. 물론 플래시백 쿼리에도 유용하지만 동일한 창에서 다시 사용할 수 있습니다.

SCN_TO_TIM 스탬프는 일부 내부 알고리즘을 사용하여 특정 이벤트가 발생한 경우 SCN과 TIME 간의 매핑을 수행하고 작업을 근사적으로 수행합니다.하지만 한계가 있습니다.UDON 데이터가 사용자의 기간을 포함하지 않는 경우 과거에는 너무 지나칠 수 없습니다.

이 경우 데이터 실행 취소 한계에 도달했을 때 자체 매핑을 만드는 까다로운 방법이 있습니다.SCN_TO_TIM 스탬프만큼 좋지는 않지만 데이터에 따라 근사치를 제공합니다.

삽입이 계속되는 테이블을 찾기만 하면 됩니다.감사 테이블 sys.aud$를 사용합니다.자신의 것을 사용할 수 있지만 테이블에는 행이 삽입된 시간을 나타내는 시간 파일이 있어야 합니다.그리고 SCN과 DATE가 있으면 SCN과 DATE를 다른 테이블로 매핑할 수 있습니다.

sys.aud$를 사용할 경우 다음 사항에 유의하십시오.

1. 액세스 권한을 부여하거나 두 개의 필드 또는 a_rowscn 및 ntimestamp#로 단순 보기를 생성하려면 DBA가 필요할 수 있습니다.
2. 데이터베이스에서 더 많은 작업이 진행될수록 매핑이 더 정확해집니다.일반적으로 sys.aud$ 테이블을 사용하여 약 60-120분의 정확도로 1년 전에 발생한 이전 데이터 편집을 매핑할 수 있습니다.
3. 감사가 꺼져 있으면 scn_time은 어떤 행도 반환하지 않으므로 매핑할 다른 테이블을 찾아야 합니다.

쿼리는 sys.aud$를 사용합니다.삽입 또는 업데이트 날짜를 찾아야 하는 테이블로 [YOU_TABLE] 대체

-- get scn to date interval [begin..end] mapping from audit table      
with scn_time as
 (
     select sc sc_start, 
            lead(sc) over(order by sc) sc_end,
            start_time,
            lead(end_time) over(order by sc) end_time_sc
     from 
      (
        select n.ora_rowscn sc, 
        min( cast(from_tz(ntimestamp#,'00:00') at local as date) ) start_time,
        max( cast(from_tz(ntimestamp#,'00:00') at local as date) ) end_time
            from sys.aud$ n
            -- if audit log is big you need to select only a part of the table
            -- to make query faster
            --where ntimestamp# > sysdate - 365
           group by  n.ora_rowscn 
      ) order by sc 
  )
-- map scn from you table to scn_mapping  
select *
  from (
          select t.ora_rowscn sc, t.*
          from [YOU_TABLE] t
       ) table_inspect
 inner join scn_time s
    on (table_inspect.sc between s.sc_start and s.sc_end)
 -- to filter out bit intervals    
 where (end_time_sc-start_time) < 1

1년 이상 전에 행이 삽입된 경우 해당 행이 삽입되었을 때 정보를 복원하는 방법을 사용했습니다.

UNDO_MANAGENT를 AUTO로 설정하고 UNDO_RETENATION을 시간을 거슬러 가장 긴 쿼리 기간을 포함하는 값으로 설정합니다.또한 UDON을 덮어쓰지 않도록 Retention GARANTE를 설정합니다.

Oracle 10g의 경우 5일 이상 플래시백할 수 없습니다.이것은 하드 코딩된 제한입니다.Oracle 11g의 경우 제한이 없습니다.

언급URL : https://stackoverflow.com/questions/22681705/how-to-use-timestamp-to-scn-and-scn-to-timestamp-in-oracle