전체 글

Redis 실행 시 문제점 Redis 를 실행하는 경우 foreground 에서 동작합니다.즉 실행한 세션을 종료하거나 'Ctrl + C' 키를 입력하는 경우 Redis 데몬이 죽게됩니다. 이 문제를 방지하기 위해 background 로 동작하도록 옵션을 설정할 수 있습니다.이 때는 logfile 을 꼭 지정해야 합니다. 지정하지 않으면 로그가 날아갑니다. Redis 백그라운드 실행 방법 1. redis.conf 파일의 deamonize 옵션을 yes 로 변경합니다.2. redis.conf 파일의 logfile 에 절대경로와 파일명을 입력합니다. 12345$ grep "daemonize" redis.confdaemonize yes $ grep "logfile" redis.conflogfile "/home..

Redis 다운로드 및 설치 방법1. wget 명령어를 통해 redis 압축파일을 다운로드 합니다.제가 다운로드한 버전은 5.0.6 버전입니다.http://download.redis.io/releases/ 경로에서 다른버전도 확인할 수 있습니다. 1wget http://download.redis.io/releases/redis-5.0.6.tar.gzcs 2. 압축파일을 해제한 후 생성된 폴더로 들어갑니다. 1tar xvzf redis-5.0.6.tar.gz && cd redis-5.0.6cs 3. redis 를 설치하기 위한 툴을 다운로드 합니다.패키지 의존성이 얽혀있기 때문에 인터넷 환경에서 받아주세요. 12345sudo apt-get updatesudo apt-get install build-esse..

단순 모드 ( Simple Mode)SQL Server 엔진에서 트랜잭션 로그를 주기적으로 비워줍니다.단순 모드라고 해서 트랜잭션 로그가 기록되지 않는 것은 아닙니다. 트랜잭션 로그가 계속 증가하는 원인 분석 단순모드 DB 의 트랜잭션 로그 사용량이 갑자기 증가하기 시작하였습니다. 처음에는 SQL Server 에서 비워주기 전 로그가 많이 쌓여 사용량이 증가한 것으로 생각하였지만,4시간이 지나도록 정리되지 못하고 사용량이 67% 까지 증가하고 있었습니다. 왜 정리를 못하는지 확인해보니, 2184 세션의 트랜잭션이 84910 초동안 활성화 되어 있었습니다.그래서 해당 트랜잭션 로그 시점 이후의 로그들은 정리되지 못하고 계속 쌓이고 있었습니다. 해당 세션을 KILL 한 후 로그 사용량을 확인해보니 0.7% ..

오랫동안 활성화 되어있는 트랜잭션이 있는 경우 문제점트랜잭션이 오랫동안 수행되고 있는 경우, 이후에 같은 페이지를 접근하는 다른 세션들은 대기해야 합니다.이런 경우 트랜잭션을 수행하는 세션을 정리해야 이후의 세션들이 작업을 진행할 수 있습니다. 또한 트랜잭션이 활성화 되어 있다면, 트랜잭션 로그도 정리할 수 없어 사용량이 계속 늘어나게 됩니다. 다양한 원인(락, 네트워크 등)으로 트랜잭션을 정상종료하지 못하고 남아있는 좀비세션들이 있을 수 있습니다. 오랫동안 수행되는 트랜잭션을 찾는 쿼리오랫동안 수행되는 트랜잭션의 세션ID, 현재 상태, 접속계정, 접속 hostname, 수행된 시간, 쿼리를 확인할 수 있습니다. 12345678910111213141516SELECT p.spid , p.cmd , p.st..

데이터베이스 마지막으로 접속한 시간 확인하는 방법데이터베이스를 마지막으로 접근한 시간은 약간 우회적으로 표현해야 합니다.데이터베이스의 객체를 언제 마지막으로 사용했는지로 확인할 수 있습니다. 즉, 객체의 마지막 접근(사용) 시간을 확인하는 방식으로 할 수 있습니다. 객체의 마지막 접근 시간을 확인하는 쿼리특정 데이터베이스에서 마지막 접근한 시간을 확인합니다.4개의 결과값 중 제일 최근의 값이 사용자가 마지막으로 DB에 접근한 시간입니다. 1234567SELECT MAX(last_user_seek) as Last_User_Seek, MAX(last_user_scan) as Last_User_Scan, MAX(last_user_lookup) as Last_User_Lookup, MAX(last_user_up..

윈도우 업데이트란?윈도우 상품에 버그가 있어 해결했거나 혹은 기능 추가할 부분이 있는 경우,사용자들의 컴퓨터에 소스를 업데이트 하여 최신화를 하는 기능입니다. 버그로 인해 취약점이 있기 때문에 업데이트를 받아 주는게 좋지만,업데이트가 원치 않는 시간에 되는 경우가 있어 가끔은 업데이트를 받지않거나 미뤄두고 싶은 경우가 있습니다. 그래서, 업데이트를 끄는 방법을 공유드립니다. 업데이트 끄는 방법1. 시작 버튼을 누른 후 '서비스' 를 입력합니다. 2. 'Windows Update' 목록을 찾은 후 우클릭 '속성' 을 선택합니다. 3. '시작 유형'을 '사용 안 함' 으로 변경합니다. 윈도우 업데이트가 앞으로는 설치되지 않습니다.그러나 보안에 취약해 질 수 있기 때문에 까먹지 말고 한번씩 확인해서 받아주시길..

dm_db_index_usage_stats DMV 뷰이 DMV 뷰를 통해서 테이블에 마지막으로 접근한 시간을 확인할 수 있습니다. 뷰의 명칭만 보면 인덱스만 확인할 수 있는 것으로 착각할 수 있으나,인덱스가 없는 테이블에도 적용이 가능합니다. 인덱스가 없는 테이블에 접근하는 경우 DMV 뷰의 last_user_scan 컬럼에 마지막 접근 시간이 UPDATE 됩니다. TABLE 에 마지막으로 접근한 시간을 확인하는 쿼리 123456789101112131415161718192021222324select DB_NAME(usage.database_id) AS db_name, schema_name, table_name, max(last_access) as last_access from( select sta.dat..

dm_exec_procedures_stats DMV 뷰이 DMV 뷰를 통해서 마지막으로 실행한 SP 를 확인할 수 있습니다. 그러나 dm_exec_procedures_stats 동적뷰는 캐시된 저장 프로시저에 대한 통계를 반환하기 때문에캐시에서 제거되면 해당 레코드가 동적뷰에서 제거되어 확인이 불가능 합니다. 캐시에서 제거되는 경우다음과 같은 경우 캐시된 저장 프로시저가 캐시에서 제거될 수 있습니다.캐시를 채우면서 전체 절차를 단위 테스트 하는 경우sp_configure 변경 (특정 옵션은 프로시저 캐시를 삭제하는 부작용이 있습니다.)큰 메모리를 필요로 하는 쿼리DBCC FREEPROCCACHE 구문 수행명시적 재컴파일 또는 프로시저 삭제 및 재작성 SP 를 마지막으로 수행한 시간 확인하는 쿼리 1234..

파티션 테이블, 구성표, 함수란파티션 테이블은파티션 별로 파일그룹을 지정한 '파티션 구성표' 와파티션 별로 저장할 데이터 경계값을 지정하는 '파티션 함수' 로 구성됩니다. 경계값은 경계값을 포함할 건지, 포함하지 않을 건지에 대한 옵션을 설정할 수 있습니다. 파티션 테이블, 파일그룹, 경계값을 확인하는 쿼리아래 쿼리는 TEST_T1 의 파티션 테이블의 구성만 확인할 수 있지만,전체 파티션 테이블을 확인하고 싶은 경우 12 라인의 조건을 주석처리 해주시면 됩니다. 1234567891011121314151617181920212223242526SELECT a.name "테이블 이름", f.name "파티션 함수", c.name "파티션 구성표", e.name "파일 그룹", f.type_desc "파티션 타입..

플랜캐시 & 실행계획SQL Server는 한번 실행된 쿼리는 처음 만들어진 실행계획을 플랜캐시에 등록하여 이후에 재사용합니다.특정 조건을 만족하여 쿼리의 실행계획이 재 컴파일 되기 전까지는 말이죠. 실행계획이 재 컴파일 되어 새로운 실행계획이 만들어지는경우 기존의 실행계획은 삭제되어 확인할 수 없습니다. 그럼 현재 플랜캐시에 있는 실행계획을 확인해 보도록 하겠습니다.플랜캐시에서는 아래와 같은 정보를 확인할 수 있습니다.- 쿼리 구문- 수행 횟수- CPU 시간- 수행 시간- 논리적 읽기- 논리적 쓰기- 쿼리 플랜 현재 플랜캐시에 있는 실행계획을 확인하는 쿼리21, 22 라인의 조건을 기호에 맞게 수정하여 특정 데이터베이스에서 특정 시간에 생성된 실행 계획을 확인할 수 있습니다.주석처리를 하여 전체 실행계획..