서론

최근 HP ZBook Ultra G1a 노트북의 저장 공간을 확장하기 위해 기존 SSD를 2TB 모델로 교체했습니다. 하지만 SSD 클로닝 작업 후 예상치 못한 문제에 직면했죠. 노트북이 부팅되지 않고 "Reset System"이라는 메시지가 화면 왼쪽 상단에 계속 깜빡이면서 BIOS 단계에서 무한 재부팅되는 현상이 발생했습니다. 이 문제를 해결하는 과정에서 얻은 경험을 공유하고자 합니다.

문제 분석

문제 증상 설명

• 노트북 부팅 시도 시 화면 왼쪽 상단에 "Reset System" 메시지가 순간적으로 나타남
• BIOS 화면으로 진입한 후 다시 재부팅되는 과정이 무한 반복
• BIOS 설정에서는 2TB SSD가 정상적으로 인식됨
• 놀랍게도 기존 SSD로 다시 교체하여 부팅을 시도했을 때도 동일한 문제가 지속됨

의심되는 원인

문제의 원인을 추적해보니, SSD 클로닝 작업 전에 Ubuntu 듀얼부팅을 구현하기 위해 boot 영역을 수정했던 것이 주요 원인으로 추정되었습니다. 특히 기존 SSD에서도 동일한 문제가 발생한 것을 보면, 부트 영역의 변경이 BIOS 수준에서 영향을 미쳤거나 부트 설정 자체가 손상된 것으로 보입니다.

해결 방법

Windows 설치 USB 준비

1. 다른 컴퓨터에서 Windows 설치 미디어 생성 도구를 사용하여 USB 부팅 디스크 제작
2. HP ZBook Ultra G1a의 BIOS에서 부팅 순서를 USB 우선으로 변경

복구 절차

1. Windows 설치 USB로 부팅
2. 설치 화면이 나타나면 '컴퓨터 복구' 옵션 선택
3. 복구 과정에서 "복구 실패" 메시지가 표시됨
4. 놀랍게도 이후 노트북이 정상적으로 부팅됨

흥미로운 점은 시스템이 복구에 실패했다는 메시지를 표시했음에도 불구하고, 이 과정 이후로 부팅 문제가 완전히 해결되었다는 것입니다. 아마도 Windows 복구 도구가 부트 영역을 자동으로 수정하거나 BIOS와의 연결을 재설정하는 과정에서 문제가 자연스럽게 해결된 것 같습니다.

교훈과 예방책

이번 경험을 통해 몇 가지 중요한 교훈을 얻었습니다:

1. Windows 설치 USB 사전 준비: SSD 업그레이드나 시스템 변경 작업을 시작하기 전에 반드시 Windows 설치 USB를 미리 만들어두어야 합니다. 부팅 문제가 발생한 후에는 다른 컴퓨터가 없으면 USB를 만들기 어려울 수 있습니다.
2. 듀얼부팅 설정 전 백업의 중요성: 부트 영역을 수정하기 전에 반드시 시스템 이미지 백업을 생성해야 합니다.
3. SSD 클로닝 시 주의사항: 클로닝 전에 부트 영역이 수정된 경우, 단순 클로닝만으로는 부팅 문제가 발생할 수 있습니다.
4. BIOS 설정 확인: SSD 교체 후 BIOS가 새로운 하드웨어를 정상적으로 인식하는지 확인하고, 필요한 경우 부팅 설정을 재조정해야 합니다.

결론

HP ZBook Ultra G1a의 SSD 업그레이드 과정에서 발생한 "Reset System" 무한 부팅 문제는 의외로 간단한 Windows 복구 시도만으로 해결되었습니다. 비록 복구 도구가 실패 메시지를 표시했지만, 이 과정이 문제를 해결하는 데 충분했습니다. 더욱이 이 문제는 새 SSD뿐만 아니라 기존 SSD에서도 동일하게 발생했던 것으로 보아, 부트 설정 자체의 문제였음을 알 수 있습니다.

여러분도 유사한 문제를 경험하셨다면, 먼저 Windows 복구 도구를 시도해보시길 권장합니다. 또한 SSD 업그레이드나 듀얼부팅 설정 시 겪은 경험이 있으시다면 댓글로 공유해주시면 감사하겠습니다.

자신을 버린 적 있는 사람을 무람없이 다시 사랑할 수 없는 것처럼, 그녀가 삶을 다시 사랑하는 일은 그때마다 길고 복잡한 과정을 필요로 했다.

왜냐하면, 당신은 언젠가 반드시 나를 버릴 테니까.
내가 가장 약하고 도움이 필요할 때,
돌이킬 수 없이 서늘하게 등을 돌릴 테니까.
그걸 나는 투명하게 알고 있으니까.
그걸 알기 전으로 돌아갈 수 없게 되었으니까.

삶이 항상 좋은 것은 아니나, 우리는 항상 삶으로 돌아간다. 

하지만 이 책의 한 구절처럼 그것이 항상 쉬운 것은 아니다.

그럼에도 우리는 돌아간다 

DJI Pocket 3로 촬영하였습니다.

운전해서 지리산 국립공원에 가면 노고단까지 약 2시간 정도면 도착 합니다.(길은 잘 되어 있으나 약간 경사 있음)

연휴나 주말에는 주차를 위해 오래 대기해야 할 수 있으니 아침 일찍 이동하는 것이 좋습니다.

한국에 온 지도 벌써 6년이 지났다.
처음 한국에 왔을 때의 복잡한 심정과 지금을 생각하면 참 뭔가 바쁘게 달려왔는데 아직도 갈 길이 멀었구나 하는 생각이 든다. 그게 게으른 나를 계속 노력하게 하는 유일한 원동력 같기도 하다.

6년 전과 비교하면.. 조금 더 삶이 편안해진 것을 느끼고 조금은 더 성장했다고 느끼며, 호주에서 살던 때에도 그랬지만 여전히 주위에 좋은 사람들이 많이 있고 또 새로운 소중한 인연들이 생겼다.

호주에서 즐겨 마시던 맥라렌베일의 한 와인 사진이 나를 과거로 잠시 초대했다. 이 와인을 마실 때 즐거웠던 기억들은 아직도 가슴 한켠을 아련하게 만들지만, 와인을 제대로 처음 시작하게 된 계기가 이 와인이 아니었던가 할 정도로 즐겁게 마셨던 기억이 있다.

호주에서의 인연들도 이제 모두 희미해지고 과거의 추억으로만 남았지만 그래도 내게 행복이라는 것을 처음 알려준 장소였으며 커다란 시련을 주어 더 마음이 단단해지게 하는 기회를 준 장소이기도 했다.

2024년 한국에서의 이번 겨울의 끝을 마주하며 그 과거의 인연들과 기억들을 한번 다시 한번 떠올려 본다.

개요: PostgreSQL의 시퀀스 사용방법 및 권장안을 정리한 글입니다.

         Oracle과의 차이점 및 cache 동작 방식을 이해하여 보다 적절한 cache 값 설정,

         개발하는 데에 필요한 현재 last_value 확인 방법 등을 서술합니다.

관련된 함수 정리

• 예시

-- 현재 값 확인, 다만 해당 시퀀스가 해당 세션에서 사용되었어야지만 확인 가능 

-- 사용 권한 없는 경우 하단의 방식으로 확인 가능. 
currval('delivery_tip_id_seq'); 

-- 해당 sequence의 insert 권한 필요 
nextval('delivery_tip_id_seq'); 
setval('delivery_tip_id_seq',1000); 
setval('delivery_tip_id_seq',1000,true);

• **특정 시퀀스 select 권한만 가진 유저가 last_value를 확인하고 싶은 경우**

la_tms=> select last_value from corrected_coordinate_id_seq; 

last_value 
------------     
189710 (1 row)

시퀀스 관련 함수 권한 정리

currval(): SELECT 혹은 USAGE 권한 부여 필요

nextval(): UPDATE 혹은 USAGE 권한 부여 필요

setval(): UPDATE 권한 부여 필요

SELECT setval('myseq', 42);          
-- 다음 nextval이 43 리턴 

SELECT setval('myseq', 42, true);    
-- 위와 동일 

SELECT setval('myseq', 42, false);   
-- 다음 nextval이 42 리턴

• 권한 확인 예시

la_tms=> \dp+ delivery_tip_id_seq*
Access privileges
 Schema |        Name         |   Type   |     Access privileges     | Column privileges | Policies 
--------+---------------------+----------+---------------------------+-------------------+----------
  public | delivery_tip_id_seq | sequence | latms_user=rwU/latms_user+|                   | 
         |                     |          | kurly_user=r/latms_user   |                   | 
(1 row)

Cache 동작방식 관련

• 오라클과 비교하였을 때 cache값이 성능에 큰 영향을 주지는 않는 것으로 확인되었음.
• 가급적 cache값을 기본값인 1로 설정하는 것으로 권장.
• 다만, cache값을 크게 주었을 때 성능 개선이 없지는 않음.
• 세션 레벨로 sequence cache가 동작하기 때문에, cache를 10으로 설정한 경우 세션1에서는 1로 시작하고 세션2에서는 11부터 시작하게 되는 방식으로 오라클과 동작방식이 다름.
• 동시성 제공을 위해 nextval 작업은 rollback이 없으며 그로 인해 한번 fetch된 값은 다시 return되지 않음. PostgreSQL 시퀀스는 gapless 시퀀스로 사용될 수 없음.

14~16 버전에서 추가된 view들에 대한 추가 필요

목록

• 데이터베이스 레벨에서 테이블 레벨, 인덱스 레벨 등으로 정보를 좁혀가며 확인하는 것이 좋습니다.
• 복제 관련 테이블(pg_stat_replication)을 모니터링하며 빠르게 복제 관련 이슈를 대응할 수 있습니다.
• 인덱스 생성이나 vacuum 등의 진행상황을 확인할 수 있는 view들이 추가되었으며 진행상황을 확인할 수 있습니다.
• 버전 별로 각 뷰들이 제공하는 정보들이 차이가 있을 수 있습니다.
• pg_stat_reset () 함수 호출로 현재 접속한 데이터베이스에 대한 통계를 초기화 할 수 있습니다.
  • 수퍼유저 권한 필요
  • **해당 함수 호출 이후에는 해당 데이터베이스 레벨 analyze를 권장합니다.**

뷰 이름설명지원 버전

[PostgreSQL: Documentation: 11: 28.2. The Statistics Collector](https://www.postgresql.org/docs/11/monitoring-stats.html)

[PostgreSQL: Documentation: 12: 27.2. The Statistics Collector](https://www.postgresql.org/docs/12/monitoring-stats.html)

[PostgreSQL: Documentation: 13: 27.2. The Statistics Collector](https://www.postgresql.org/docs/13/monitoring-stats.html)

예시

• 데이터베이스 레벨 뷰
  • 해당 통계를 기반으로 temp사용량이 많은 데이터베이스를 확인, work_mem 파라미터 등의 조정을 고려할 수 있습니다. 다만 temp사용량은 temp table이나 unlogged 테이블 생성시에 사용되므로 확인 필요( log_temp_file 활성화를 통해 temp 사용하는 쿼리 확인 가능)

{
"select * from pg_stat_database where datname like 'm%'": [
	{
		"datid" : 16403,							### 데이터베이스 oid
		"datname" : "test_db",						### 데이터베이스명
		"numbackends" : 12,							### 백엔드 연결 수
		"xact_commit" : 4065007,					### commit된 트랜잭션 수
		"xact_rollback" : 6,						### 롤백된 트랜잭션 수 
		"blks_read" : 82335002,						### 디스크 블록 리드 수
		"blks_hit" : 2107484331,					### 버퍼 캐시 리드 수
		"tup_returned" : 5665571669,				### row 리턴 수
		"tup_fetched" : 685654924,					### row fetch 수
		"tup_inserted" : 29599104,					### row inserted 수
		"tup_updated" : 14807862,					### row update 수
		"tup_deleted" : 3853807,					### row delete 수
		"conflicts" : 0,							### 복제본과 충돌나서 쿼리 취소된 횟수
		"temp_files" : 16359,					    ### tempfile 생성된 회수
		"temp_bytes" : 85413165754,				    ### temp파일 발생량(byte)
		"deadlocks" : 0,						    ### 해당 DB에서 발생한 데드락 횟수
		"blk_read_time" : 1.289543325209E9,		    ### 블록 읽기에 소요된 시간
		"blk_write_time" : 0.0,                     ### 블록 쓰기에 소요된 시간
		"stats_reset" : "2023-05-24T08:22:48.903Z"  ### 마지막으로 통계가 초기화된 시점
	}
]}

• 테이블 통계 뷰
  • 해당 통계를 기반으로 analyze(테이블 데이터 통계정보수집), vacuum, autovacuum, autoanalyze 등에 대한 정보를 확인할 수 있습니다.
  • 현재 해당 테이블에 얼마만큼의 dead tuple이 존재하는지 live tuple이 존재하는지의 비율과 변경량 등을 확인 가능합니다.

{
"select * from pg_stat_user_tables": [
	{
		"relid" : 2017157389,
		"schemaname" : "public",
		"relname" : "test_temp",
		"seq_scan" : 2,
		"seq_tup_read" : 0,
		"idx_scan" : null,
		"idx_tup_fetch" : null,
		"n_tup_ins" : 0,
		"n_tup_upd" : 0,
		"n_tup_del" : 0,
		"n_tup_hot_upd" : 0,
		"n_live_tup" : 0,
		"n_dead_tup" : 0,
		"n_mod_since_analyze" : 0,
		"last_vacuum" : "2023-06-28T20:10:01.283Z",
		"last_autovacuum" : null,
		"last_analyze" : "2023-06-28T20:10:01.285Z",
		"last_autoanalyze" : null,
		"vacuum_count" : 3,
		"autovacuum_count" : 0,
		"analyze_count" : 4,
		"autoanalyze_count" : 0
	}
]}

• 인덱스 통계 뷰
  • 해당 통계를 기반으로 인덱스의 사용 빈도, 사용될 때 읽어 들이는 평균 row수 등을 확인 가능합니다
  • 이를 기반으로 사용되지 않는 인덱스, 인덱스에서 읽어 들이는 평균 row수 등을 확인 가능합니다.

{
"select * from pg_stat_user_indexes order by idx_scan desc": [
	{
		"relid" : 46389,
		"indexrelid" : 46419,
		"schemaname" : "public",
		"relname" : "test_temp",
		"indexrelname" : "idx_test_temp_01",
		"idx_scan" : 97664185023,
		"idx_tup_read" : 16665052192,
		"idx_tup_fetch" : 6487645140
	}
]}