시스템 테이블 및 뷰 참조
주제
시스템 테이블 및 뷰
Amazon Redshift는 시스템 작동 방식에 대한 정보가 저장되어 있는 시스템 테이블 및 뷰가 많습니다. 이러한 시스템 테이블 및 뷰 역시 다른 데이터베이스 테이블에 대한 쿼리와 동일한 방법으로 쿼리를 실행할 수 있습니다. 이번 단원에서는 몇 가지 시스템 테이블 쿼리 샘플을 살펴보면서 다음과 같은 주제를 가지고 설명하겠습니다.
-
다양한 유형의 시스템 테이블 및 뷰 생성
-
이러한 테이블에서 얻을 수 있는 정보 유형
-
Amazon Redshift 시스템 테이블을 카탈로그 테이블에 조인하는 방법
-
점점 증가하는 시스템 테이블 로그 파일의 관리 방법
일부 시스템 테이블은 진단 목적으로 AWS 직원만 사용할 수 있습니다. 다음 단원에서는 시스템 관리자 또는 데이터베이스 사용자가 유용한 정보를 얻기 위해 쿼리를 실행할 수 있는 시스템 테이블에 대해서 얘기하겠습니다.
참고
시스템 테이블은 자동 또는 수동 클러스터 백업(스냅샷)에 포함되지 않습니다. STL 시스템 뷰는 7일간의 로그 기록을 보존합니다. 따라서 로그 보존에는 별도의 고객 조치가 필요하지 않습니다. 따라서 로그 데이터를 7일 이상 보관하고 싶다면 정기적으로 다른 테이블에 복사하거나 Amazon S3으로 언로드해야 합니다.
시스템 테이블 및 뷰의 유형
다음과 같은 여러 유형의 시스템 테이블과 뷰가 있습니다.
SVV 뷰에는 임시 STV 테이블에 대한 참조와 함께 데이터베이스 객체에 대한 정보가 포함됩니다.
SYS 뷰는 프로비저닝된 클러스터 및 서버리스 작업 그룹의 쿼리 및 워크로드 리소스 사용량을 모니터링하는 데 사용됩니다.
STL 뷰는 디스크에 영구 저장되어 시스템 이력을 알려주는 로그에서 생성됩니다.
STV 테이블은 현재 시스템 데이터의 스냅샷을 포함하는 가상 시스템 테이블입니다. 이 두 테이블은 일시적인 인메모리 데이터를 기반으로 하기 때문에 디스크 기반 로그나 정규 테이블에 영구 저장되지는 않습니다.
SVCS 뷰는 동시성 확장 클러스터와 기본 클러스터 모두의 쿼리에 대한 세부 정보를 제공합니다.
SVL 뷰는 기본 클러스터의 쿼리에 대한 세부 정보를 제공합니다.
시스템 테이블과 뷰는 정규 테이블과 동일한 일관성 모델을 사용하지 않습니다. 특히 STV 테이블과 SVV 뷰에 대한 쿼리를 실행할 때는 이러한 문제를 알고 있어야 합니다. 예를 들어 일반 테이블 t1에 열 c1이 있다고 가정할 때 다음과 같은 쿼리는 아무런 행도 반환하지 않을 수 있습니다.
select * from t1 where c1 > (select max(c1) from t1)
하지만 시스템 테이블에 대한 다음 쿼리는 분명히 행을 반환하게 됩니다.
select * from stv_exec_state where currenttime > (select max(currenttime) from stv_exec_state)
위 쿼리가 행을 반환할 수 있는 이유는 currenttime이 일시적이고, 쿼리에서 두 참조가 평가 시 동일한 값을 반환하지 않기 때문입니다.
반면에 다음 쿼리는 아무런 행도 반환하지 않습니다.
select * from stv_exec_state where currenttime = (select max(currenttime) from stv_exec_state)
시스템 테이블 및 뷰에 있는 데이터의 가시성
시스템 테이블 및 보기에 저장되는 데이터의 가시성은 사용자 가시성과 수퍼유저 가시성이라는 두 가지 등급이 있습니다.
수퍼유저 가시성 카테고리에 속하는 테이블의 데이터는 수퍼유저 권한이 있는 사용자만 볼 수 있습니다. 일반 사용자는 사용자 가시성 테이블의 데이터를 볼 수 있습니다. 일반 사용자에게 수퍼유저 가시성 테이블에 대한 액세스를 제공하려면 해당 테이블에 대한 SELECT 권한을 일반 사용자에게 부여합니다. 자세한 내용은 GRANT 단원을 참조하십시오.
기본적으로 대부분의 사용자 가시성 테이블에서 일반 사용자는 다른 사용자가 생성한 행을 볼 수 없습니다. 일반 사용자에게 SYSLOG ACCESS UNRESTRICTED가 부여된 경우 해당 사용자는 다른 사용자가 생성한 행을 포함하여 사용자 가시성 테이블에 있는 모든 행을 볼 수 있습니다. 자세한 내용은 ALTER USER 또는 사용자 생성을 참조하세요. SVV_TRANSACTIONS의 모든 행은 모든 사용자에게 표시됩니다. 데이터 가시성에 대한 자세한 내용은 AWS re:Post 기술 자료 문서 Amazon Redshift 데이터베이스의 일반 사용자에게 내 클러스터의 다른 사용자가 제공한 시스템 테이블 데이터를 볼 수 있는 권한을 허용하려면 어떻게 해야 합니까?
메타데이터 보기의 경우 Amazon Redshift는 SYSLOG ACCESS UNRESTRICTED가 부여된 사용자에게 가시성을 허용하지 않습니다.
참고
사용자에게 시스템 테이블에 대한 무제한 액세스를 제공하면 다른 사용자가 생성한 데이터에 대한 가시성이 사용자에게 제공됩니다. 예를 들어, STL_QUERY 및 STL_QUERY_TEXT에는 INSERT, UPDATE 및 DELETE 문의 전체 텍스트가 포함되며, 여기에는 사용자가 생성한 민감한 데이터가 포함될 수 있습니다.
수퍼유저는 모든 테이블의 모든 행을 볼 수 있습니다. 일반 사용자에게 수퍼유저 가시성 테이블에 대한 액세스를 제공하려면 해당 테이블에 대한 GRANT SELECT 권한을 일반 사용자에게 부여합니다.
시스템 생성 쿼리 필터링
일반적으로 쿼리 관련 시스템 테이블 및 뷰(SVL_QUERY_SUMMARY, SVL_QLOG 등)에는 Amazon Redshift에서 데이터베이스 상태를 모니터링하는 데 사용하는 자동 생성 문이 다수 포함되어 있습니다. 이러한 시스템 생성 쿼리도 수퍼유저에게 노출되지만 사용할 일은 거의 없습니다. 따라서 userid 열을 사용하는 시스템 테이블이나 시스템 뷰에서 선택할 때 이러한 쿼리를 필터링하려면 WHERE 절에 userid > 1 조건을 추가하면 됩니다. 예:
select * from svl_query_summary where userid > 1
프로비저닝 전용 쿼리를 SYS 모니터링 뷰 쿼리로 마이그레이션
프로비저닝된 클러스터에서 Amazon Redshift Serverless로 마이그레이션
프로비저닝된 클러스터를 Amazon Redshift Serverless로 마이그레이션하는 경우 프로비저닝된 클러스터의 데이터만 저장하는 다음과 같은 시스템 뷰를 사용하는 쿼리가 있을 수 있습니다.
모든 STL 뷰
모든 STV 뷰
모든 SVCS 뷰
모든 SVL 뷰
일부 SVV 뷰
Amazon Redshift Serverless에서 지원되지 않는 SVV 뷰의 전체 목록은 Amazon Redshift 관리 안내서의 Amazon Redshift Serverless로 쿼리 및 워크로드 모니터링 하단에 있는 목록을 참조하세요.
쿼리를 계속 사용하려면 SYS 모니터링 뷰에서 정의되었으며 프로비저닝 전용 뷰의 열에 해당하는 열을 사용하도록 쿼리를 다시 구성하세요. 프로비저닝 전용 뷰와 SYS 모니터링 뷰 간의 매핑 관계는 SYS 모니터링 뷰로 마이그레이션하기 위한 시스템 뷰 매핑 섹션을 참조하세요.
프로비저닝된 클러스터에 머물면서 쿼리 업데이트
Amazon Redshift Serverless로 마이그레이션하지 않는 경우에도 기존 쿼리를 업데이트하고 싶을 수 있습니다. SYS 모니터링 뷰는 사용 편의성과 복잡성 감소를 위해 설계되어 효과적인 모니터링 및 문제 해결을 위한 완전한 지표를 제공합니다. 여러 개의 프로비저닝 전용 뷰의 정보를 통합하는 SYS_QUERY_HISTORY 및 SYS_QUERY_DETAIL 등의 SYS 뷰를 사용하면 쿼리를 간소화할 수 있습니다.
SYS 모니터링 뷰를 사용하여 쿼리 식별자 추적 개선
SYS_QUERY_HISTORY 및 SYS_QUERY_DETAIL과 같은 SYS 모니터링 뷰에는 사용자 쿼리에 대한 식별자가 들어 있는 query_id 열이 포함됩니다. 마찬가지로 STL_QUERY 및 SVL_QLOG와 같은 프로비저닝 전용 뷰에는 쿼리 열이 포함되며 쿼리 열에도 쿼리 식별자가 들어 있습니다. 하지만 SYS 시스템 뷰에 기록된 쿼리 식별자는 프로비저닝 전용 뷰에 기록된 쿼리 식별자와 다릅니다.
SYS 뷰의 query_id 열 값과 프로비저닝 전용 뷰의 쿼리 열 값 간의 차이는 다음과 같습니다.
SYS 뷰에서 query_id 열은 사용자가 제출한 쿼리를 원래 형식으로 기록합니다. Amazon Redshift 최적화 프로그램은 성능 향상을 위해 이러한 쿼리를 하위 쿼리로 분류할 수 있지만, 실행하는 단일 쿼리에는 SYS_QUERY_HISTORY에 여전히 행이 하나뿐입니다. 개별 하위 쿼리는 SYS_QUERY_DETAIL에서 확인할 수 있습니다.
프로비저닝 전용 뷰에서는 쿼리 열에 하위 쿼리 수준의 쿼리가 기록됩니다. Amazon Redshift 최적화 프로그램이 원래 쿼리를 여러 하위 쿼리로 다시 작성하는 경우, 실행하는 단일 쿼리에 대해 쿼리 식별자 값이 서로 다른 여러 행이 STL_QUERY에 생성됩니다.
모니터링 및 진단 쿼리를 프로비저닝 전용 뷰에서 SYS 뷰로 마이그레이션할 때는 이러한 차이를 고려하여 적절하게 쿼리를 편집하세요. Amazon Redshift의 쿼리 처리 방식에 대한 자세한 내용은 쿼리 계획 및 실행 워크플로우 섹션을 참조하세요.
예
Amazon Redshift가 프로비저닝 전용 뷰와 SYS 모니터링 뷰에서 어떻게 다르게 쿼리를 기록하는지 보여주는 예는 다음 샘플 쿼리를 참조하세요. 이 쿼리는 Amazon Redshift에서 실행할 때와 같이 작성된 것입니다.
SELECT s_name , COUNT(*) AS numwait FROM supplier, lineitem l1, orders, nation WHERE s_suppkey = l1.l_suppkey AND o_orderkey = l1.l_orderkey AND o_orderstatus = 'F' AND l1.l_receiptdate > l1.l_commitdate AND EXISTS (SELECT * FROM lineitem l2 WHERE l2.l_orderkey = l1.l_orderkey AND l2.l_suppkey <> l1.l_suppkey ) AND NOT EXISTS (SELECT * FROM lineitem l3 WHERE l3.l_orderkey = l1.l_orderkey AND l3.l_suppkey <> l1.l_suppkey AND l3.l_receiptdate > l3.l_commitdate ) AND s_nationkey = n_nationkey AND n_name = 'UNITED STATES' GROUP BY s_name ORDER BY numwait DESC , s_name LIMIT 100;
눈에 보이지는 않지만 Amazon Redshift 쿼리 최적화 프로그램은 사용자가 제출한 위 쿼리를 5개의 하위 쿼리로 다시 작성합니다.
첫 번째 하위 쿼리는 임시 테이블을 생성하여 하위 쿼리를 구체화합니다.
CREATE TEMP TABLE volt_tt_606590308b512(l_orderkey , l_suppkey , s_name ) AS SELECT l1.l_orderkey , l1.l_suppkey , public.supplier.s_name FROM public.lineitem AS l1, public.nation, public.orders, public.supplier WHERE l1.l_commitdate < l1.l_receiptdate AND l1.l_orderkey = public.orders.o_orderkey AND l1.l_suppkey = public.supplier.s_suppkey AND public.nation.n_name = 'UNITED STATES'::CHAR(8) AND public.nation.n_nationkey = public.supplier.s_nationkey AND public.orders.o_orderstatus = 'F'::CHAR(1);
두 번째 하위 쿼리는 임시 테이블에서 통계를 수집합니다.
padb_fetch_sample: select count(*) from volt_tt_606590308b512;
세 번째 하위 쿼리는 위에서 만든 임시 테이블을 참조하여 다른 하위 쿼리를 구체화하기 위해 또 다른 임시 테이블을 만듭니다.
CREATE TEMP TABLE volt_tt_606590308c2ef(l_orderkey , l_suppkey) AS (SELECT volt_tt_606590308b512.l_orderkey , volt_tt_606590308b512.l_suppkey FROM public.lineitem AS l2, volt_tt_606590308b512 WHERE l2.l_suppkey <> volt_tt_606590308b512.l_suppkey AND l2.l_orderkey = volt_tt_606590308b512.l_orderkey) EXCEPT distinct (SELECT volt_tt_606590308b512.l_orderkey, volt_tt_606590308b512.l_suppkey FROM public.lineitem AS l3, volt_tt_606590308b512 WHERE l3.l_commitdate < l3.l_receiptdate AND l3.l_suppkey <> volt_tt_606590308b512.l_suppkey AND l3.l_orderkey = volt_tt_606590308b512.l_orderkey);
네 번째 하위 쿼리도 임시 테이블의 통계를 수집합니다.
padb_fetch_sample: select count(*) from volt_tt_606590308c2ef
마지막 하위 쿼리는 위에서 만든 임시 테이블을 사용하여 출력을 생성합니다.
SELECT volt_tt_606590308b512.s_name AS s_name , COUNT(*) AS numwait FROM volt_tt_606590308b512, volt_tt_606590308c2ef WHERE volt_tt_606590308b512.l_orderkey = volt_tt_606590308c2ef.l_orderkey AND volt_tt_606590308b512.l_suppkey = volt_tt_606590308c2ef.l_suppkey GROUP BY 1 ORDER BY 2 DESC , 1 ASC LIMIT 100;
프로비저닝 전용 시스템 뷰 STL_QUERY에서 Amazon Redshift는 다음과 같이 하위 쿼리 수준에서 5개 행을 기록합니다.
SELECT userid, xid, pid, query, querytxt::varchar(100); FROM stl_query WHERE xid = 48237350 ORDER BY xid, starttime;userid | xid | pid | query | querytxt --------+----------+------------+----------+------------------------------------------------------------------------------------------------------ 101 | 48237350 | 1073840810 | 12058151 | CREATE TEMP TABLE volt_tt_606590308b512(l_orderkey, l_suppkey, s_name) AS SELECT l1.l_orderkey, l1.l 101 | 48237350 | 1073840810 | 12058152 | padb_fetch_sample: select count(*) from volt_tt_606590308b512 101 | 48237350 | 1073840810 | 12058156 | CREATE TEMP TABLE volt_tt_606590308c2ef(l_orderkey, l_suppkey) AS (SELECT volt_tt_606590308b512.l_or 101 | 48237350 | 1073840810 | 12058168 | padb_fetch_sample: select count(*) from volt_tt_606590308c2ef 101 | 48237350 | 1073840810 | 12058170 | SELECT s_name , COUNT(*) AS numwait FROM supplier, lineitem l1, orders, nation WHERE s_suppkey = l1. (5 rows)
SYS 모니터링 뷰 SYS_QUERY_HISTORY에서 Amazon Redshift는 다음과 같이 쿼리를 기록합니다.
SELECT user_id, transaction_id, session_id, query_id, query_text::varchar(100) FROM sys_query_history WHERE transaction_id = 48237350 ORDER BY start_time;user_id | transaction_id | session_id | query_id | query_text ---------+----------------+------------+----------+------------------------------------------------------------------------------------------------------ 101 | 48237350 | 1073840810 | 12058149 | SELECT s_name , COUNT(*) AS numwait FROM supplier, lineitem l1, orders, nation WHERE s_suppkey = l1.
SYS_QUERY_DETAIL에서는 SYS_QUERY_HISTORY_HISTORY의 query_id 값을 사용하여 하위 쿼리 수준의 세부 정보를 찾을 수 있습니다. child_query_sequence 열에는 하위 쿼리가 실행되는 순서가 표시됩니다. SYS_QUERY_DETAIL의 열에 대한 자세한 내용은 SYS_QUERY_DETAIL 섹션을 참조하세요.
select user_id, query_id, child_query_sequence, stream_id, segment_id, step_id, start_time, end_time, duration, blocks_read, blocks_write, local_read_io, remote_read_io, data_skewness, time_skewness, is_active, spilled_block_local_disk, spilled_block_remote_disk from sys_query_detail where query_id = 12058149 and step_id = -1 order by query_id, child_query_sequence, stream_id, segment_id, step_id;user_id | query_id | child_query_sequence | stream_id | segment_id | step_id | start_time | end_time | duration | blocks_read | blocks_write | local_read_io | remote_read_io | data_skewness | time_skewness | is_active | spilled_block_local_disk | spilled_block_remote_disk ---------+----------+----------------------+-----------+------------+---------+----------------------------+----------------------------+----------+-------------+--------------+---------------+----------------+---------------+---------------+-----------+--------------------------+--------------------------- 101 | 12058149 | 1 | 0 | 0 | -1 | 2023-09-27 15:40:38.512415 | 2023-09-27 15:40:38.533333 | 20918 | 0 | 0 | 0 | 0 | 0 | 44 | f | 0 | 0 101 | 12058149 | 1 | 1 | 1 | -1 | 2023-09-27 15:40:39.931437 | 2023-09-27 15:40:39.972826 | 41389 | 12 | 0 | 12 | 0 | 0 | 77 | f | 0 | 0 101 | 12058149 | 1 | 2 | 2 | -1 | 2023-09-27 15:40:40.584412 | 2023-09-27 15:40:40.613982 | 29570 | 32 | 0 | 32 | 0 | 0 | 25 | f | 0 | 0 101 | 12058149 | 1 | 2 | 3 | -1 | 2023-09-27 15:40:40.582038 | 2023-09-27 15:40:40.615758 | 33720 | 0 | 0 | 0 | 0 | 0 | 1 | f | 0 | 0 101 | 12058149 | 1 | 3 | 4 | -1 | 2023-09-27 15:40:46.668766 | 2023-09-27 15:40:46.705456 | 36690 | 24 | 0 | 15 | 0 | 0 | 17 | f | 0 | 0 101 | 12058149 | 1 | 4 | 5 | -1 | 2023-09-27 15:40:46.707209 | 2023-09-27 15:40:46.709176 | 1967 | 0 | 0 | 0 | 0 | 0 | 18 | f | 0 | 0 101 | 12058149 | 1 | 4 | 6 | -1 | 2023-09-27 15:40:46.70656 | 2023-09-27 15:40:46.71289 | 6330 | 0 | 0 | 0 | 0 | 0 | 0 | f | 0 | 0 101 | 12058149 | 1 | 5 | 7 | -1 | 2023-09-27 15:40:46.71405 | 2023-09-27 15:40:46.714343 | 293 | 0 | 0 | 0 | 0 | 0 | 0 | f | 0 | 0 101 | 12058149 | 2 | 0 | 0 | -1 | 2023-09-27 15:40:52.083907 | 2023-09-27 15:40:52.087854 | 3947 | 0 | 0 | 0 | 0 | 0 | 35 | f | 0 | 0 101 | 12058149 | 2 | 1 | 1 | -1 | 2023-09-27 15:40:52.089632 | 2023-09-27 15:40:52.091129 | 1497 | 0 | 0 | 0 | 0 | 0 | 11 | f | 0 | 0 101 | 12058149 | 2 | 1 | 2 | -1 | 2023-09-27 15:40:52.089008 | 2023-09-27 15:40:52.091306 | 2298 | 0 | 0 | 0 | 0 | 0 | 0 | f | 0 | 0 101 | 12058149 | 3 | 0 | 0 | -1 | 2023-09-27 15:40:56.882013 | 2023-09-27 15:40:56.897282 | 15269 | 0 | 0 | 0 | 0 | 0 | 29 | f | 0 | 0 101 | 12058149 | 3 | 1 | 1 | -1 | 2023-09-27 15:40:59.718554 | 2023-09-27 15:40:59.722789 | 4235 | 0 | 0 | 0 | 0 | 0 | 13 | f | 0 | 0 101 | 12058149 | 3 | 2 | 2 | -1 | 2023-09-27 15:40:59.800382 | 2023-09-27 15:40:59.807388 | 7006 | 0 | 0 | 0 | 0 | 0 | 58 | f | 0 | 0 101 | 12058149 | 3 | 3 | 3 | -1 | 2023-09-27 15:41:06.488685 | 2023-09-27 15:41:06.493825 | 5140 | 0 | 0 | 0 | 0 | 0 | 56 | f | 0 | 0 101 | 12058149 | 3 | 3 | 4 | -1 | 2023-09-27 15:41:06.486206 | 2023-09-27 15:41:06.497756 | 11550 | 0 | 0 | 0 | 0 | 0 | 2 | f | 0 | 0 101 | 12058149 | 3 | 4 | 5 | -1 | 2023-09-27 15:41:06.499201 | 2023-09-27 15:41:06.500851 | 1650 | 0 | 0 | 0 | 0 | 0 | 15 | f | 0 | 0 101 | 12058149 | 3 | 4 | 6 | -1 | 2023-09-27 15:41:06.498609 | 2023-09-27 15:41:06.500949 | 2340 | 0 | 0 | 0 | 0 | 0 | 0 | f | 0 | 0 101 | 12058149 | 3 | 5 | 7 | -1 | 2023-09-27 15:41:06.502945 | 2023-09-27 15:41:06.503282 | 337 | 0 | 0 | 0 | 0 | 0 | 0 | f | 0 | 0 101 | 12058149 | 4 | 0 | 0 | -1 | 2023-09-27 15:41:06.62899 | 2023-09-27 15:41:06.631452 | 2462 | 0 | 0 | 0 | 0 | 0 | 22 | f | 0 | 0 101 | 12058149 | 4 | 1 | 1 | -1 | 2023-09-27 15:41:06.632313 | 2023-09-27 15:41:06.63391 | 1597 | 0 | 0 | 0 | 0 | 0 | 20 | f | 0 | 0 101 | 12058149 | 4 | 1 | 2 | -1 | 2023-09-27 15:41:06.631726 | 2023-09-27 15:41:06.633813 | 2087 | 0 | 0 | 0 | 0 | 0 | 0 | f | 0 | 0 101 | 12058149 | 5 | 0 | 0 | -1 | 2023-09-27 15:41:12.571974 | 2023-09-27 15:41:12.584234 | 12260 | 0 | 0 | 0 | 0 | 0 | 39 | f | 0 | 0 101 | 12058149 | 5 | 0 | 1 | -1 | 2023-09-27 15:41:12.569815 | 2023-09-27 15:41:12.585391 | 15576 | 0 | 0 | 0 | 0 | 0 | 4 | f | 0 | 0 101 | 12058149 | 5 | 1 | 2 | -1 | 2023-09-27 15:41:13.758513 | 2023-09-27 15:41:13.76401 | 5497 | 0 | 0 | 0 | 0 | 0 | 39 | f | 0 | 0 101 | 12058149 | 5 | 1 | 3 | -1 | 2023-09-27 15:41:13.749 | 2023-09-27 15:41:13.772987 | 23987 | 0 | 0 | 0 | 0 | 0 | 32 | f | 0 | 0 101 | 12058149 | 5 | 2 | 4 | -1 | 2023-09-27 15:41:13.799526 | 2023-09-27 15:41:13.813506 | 13980 | 0 | 0 | 0 | 0 | 0 | 62 | f | 0 | 0 101 | 12058149 | 5 | 2 | 5 | -1 | 2023-09-27 15:41:13.798823 | 2023-09-27 15:41:13.813651 | 14828 | 0 | 0 | 0 | 0 | 0 | 0 | f | 0 | 0 (28 rows)
시스템 테이블 쿼리, 프로세스 및 세션 ID
시스템 테이블에 표시되는 쿼리, 프로세스 및 세션 ID를 분석할 때 다음 사항에 유의하세요.
query_id및query와 같은 열의 쿼리 ID 값은 시간이 지남에 따라 재사용될 수 있습니다.process_id,pid,session_id와 같은 열의 프로세스 ID 또는 세션 ID 값은 시간이 지남에 따라 재사용될 수 있습니다.transaction_id및xid와 같은 열의 트랜잭션 ID 값은 고유합니다.
