타 팀에서 서비스 중인 DB 중 트랜잭션 로그 백업 처리 스케쥴을 등록하지 않아 디스크 용량이 0이 되버려서 이러지도 저러지도 못하는 경우가 있어 처리해준게 벌써 두 번째. 

 

RDBMS에서 기본 복구 모델 설정은 보통 full로 되어 있기 때문에 Management studio에서 축소 처리를 해도 백업 전에는 줄어들지 않습니다. 

 

DB 관리를 위해 트랜잭션 파일 옵션에 대해서는 두 가지를 신경써야 합니다. 

 

1. 사고 발생 시 복구가 필요한 DB 인가.. 

 

중요한 정보가 기록되고 사고 발생 시 분 단위로 정보를 복구해야 하는지를 생각해서 꼭 필요한 경우 full로 그렇지 않고 하루 혹은 주 단위로 전체 백업을 한 파일로 복구 하거나 혹은 분실되도 상관없는 DB는 simple로 설정하는게 좋습니다. 

 

2. 스케쥴러에 정기적으로 백업하는 옵션 설정. 전체 백업 주기에 맞춰 자동으로 삭제.

 

트랜잭션 로그는 정기적으로 백업을 해서 파일 크기를 일정하게 유지하는게 좋습니다. 그리고 전체 백업 파일이 생성되는 시점 이전의 트랜젝션 로그들은 존재 의미가 없습니다. 

 

예를들어 매주 월요일 0시에 전체 백업을 한다면 그 이전에 생성된 트랜젝션 로그 파일들은 자동 삭제되도록 설정하는게 좋습니다.

 

만약 최신 데이터 뿐만 아니라 1년전 정보를 특정 시간 간격 단위로 복구해야 한다면 그 기간안에 백업된 파일들은 유지해야겠죠.

 

 

그리고 간혹 트랜잭션 로그가 별 의미없는 DATABASE를 만들어 사용하는 경우가 있습니다. 

 

테스트 DB용, 로그 DB 등 ... 

 

테스트 DB의 경우 일정 기간 사용 후 삭제한다면 모를까.. 지속적으로 사용할 경우 트랜잭션 로그 설정을 잊지 말아야 합니다. 

 

로그  DB를 RDBMS에 기록한다는게 아이러니 하지만... 써야만 하는 상황이라면... 복구 옵션을 simple로 두고 문제 발생 시 언제든 삭제되도록 하는게 좋습니다. 

 

 

[복구 모델 변경 쿼리]

USE myDBName;
ALTER DATABASE myDBName SET RECOVERY FULL;   -- 쿼리 하나하나를 확인하며 복구가 필요한 경우
ALTER DATABASE myDBName SET RECOVERY SIMPLE;

[로그 파일 삭제]

DBCC SHRINKFILE (myDBName_log, TRUNCATEONLY)

파일 축소 시 DB 명은 select * from sys.database_files 로 타겟 DB명을 확인하세요. 일반적으로 트랜잭션 로그 파일은 DB명 뒤에 _log가 붙어 있습니다.

 

 

'개발 이야기 > DATABASE' 카테고리의 다른 글

MSSQL RECOVERY 옵션  (0) 2020.09.09
MSSQL 버전 별 암호화 지원 정리  (0) 2020.01.30
MSSQL Linked Server 설정 방법  (0) 2020.01.27
MariaDB, Galera Cluster, MaxScale 전체 정리  (0) 2019.07.04
SELinux for Galera cluster  (0) 2019.07.03
mariadb 시작 오류  (0) 2019.03.18

pwdencrypt에 대해서 찾아보면 MSSQL 2008까지는 hashbytes에 MD2, MD4, MD5, SHA, SHA1을 지원했으면 pwdencrypt는 SHA1을 사용합니다. (2000 이전에는 없었으며, 2000에서는 대/소문자를 구분하지 않는 SHA1, 2005 ~ 2008까지는 대/소문자를 구분하는 SHA1을 사용)

 

이후 버전에서는 SHA2_256, SHA2_512를 지원하는데 pwdencrypt는 SHA2_512(대소문자 구분)를 사용합니다.

 

MSSQL 2008 이하 버전에서 2012 이상으로 마이그레이션 했을 경우 pwdencrypt로 암호화 할 때 앞 2byte를 버전 번호로 사용하여 pwdcompare에서 비교해서 결과를 돌려주기 때문에 그대로 사용 가능합니다.

 

그런데 공식 문서에는 pwdencrypt 대신 HASHBYTES를 사용하라고 되어 있네요. 

PWDENCRYPT is an older function and might not be supported in a future release of SQL Server. Use HASHBYTES instead. HASHBYTES provides more hashing algorithms.

하지만 2019 버전에서도 지원하니까 앞으로 몇 년은 일단 고민하지 말아야겠네요.

 

 

'개발 이야기 > DATABASE' 카테고리의 다른 글

MSSQL RECOVERY 옵션  (0) 2020.09.09
MSSQL 버전 별 암호화 지원 정리  (0) 2020.01.30
MSSQL Linked Server 설정 방법  (0) 2020.01.27
MariaDB, Galera Cluster, MaxScale 전체 정리  (0) 2019.07.04
SELinux for Galera cluster  (0) 2019.07.03
mariadb 시작 오류  (0) 2019.03.18

워낙 가끔 만지다보니 가끔 혼동이 와서 정리합니다.

 

Windows Server 2019 Standard ( 64bit ) , MSSQL Standard 2017( 64bit )

 

 

(1) 에 사용할 이름을 설정, (2)에 연결할 DB의 IP, PORT를 입력합니다. MSSQL 끼리 연결할 때 다른 설정은 굳이 입력하지 않아도 됩니다. 연결할 DB에서는 "보안" 항목에 입력할 계정에 필요한 권한이 설정되어 있을 것이므로 (입력된 것이 없다면 연결할 DB에 계정 생성, 필요한 사용 권한 설정을 해 두시면 됩니다.) 다른 설정은 필요없습니다. 카탈로그에 사용할 DB 이름을 넣을 수 있지만 사용 권한 설정에 필요한 정보가 다 있으므로 입력이 불필요합니다.

 

 

 

그리고 "보안" 페이지에서 원격 로그인, 암호를 입력한 후 "확인"을 누르면 설정이 종료됩니다. 

 

끝!!!

'개발 이야기 > DATABASE' 카테고리의 다른 글

MSSQL RECOVERY 옵션  (0) 2020.09.09
MSSQL 버전 별 암호화 지원 정리  (0) 2020.01.30
MSSQL Linked Server 설정 방법  (0) 2020.01.27
MariaDB, Galera Cluster, MaxScale 전체 정리  (0) 2019.07.04
SELinux for Galera cluster  (0) 2019.07.03
mariadb 시작 오류  (0) 2019.03.18

Collo를 좀 더 알기쉽게 전달하기 위해 개요 및 샘플들을 제작하여 SlideShare에 공유 중입니다. 

 

이 글에서도 링크를 추가하여 계속 업데이트 하도록 하겠습니다.

 

https://www.slideshare.net/winninghabit/collo-01-kr

 

Collo -01 , kr

Collo를 소개합니다! https://github.com/blackwitch/Collo

www.slideshare.net

https://www.slideshare.net/winninghabit/collo-02-kr

불러오는 중입니다...

 

'개발 이야기 > Collo' 카테고리의 다른 글

Collo - slideshare 링크 공유  (0) 2019.11.05
Collo - 실시간 마이그레이션 툴  (0) 2019.09.30

한동안 회사에서 진행한 Data Warehouse(이하 DW) 및 통계시스템 구축이 최근 완료되었습니다. 

 

그리고 데이타를 저장한 Database(이하 DB) 종류, 저장된 로그의 파일 포멧 그리고 서버 위치도 다른 데이터들을 한 곳으로 손쉽게 모으기 위해 만들었던 천 줄 내외의 Javascript 코드를 정리해서 Collo라는 이름으로 github에 며칠 전 공개하게 되었습니다.

 

Collo의 주 목표는 실시간으로 누적되는 데이터를 해당 시스템의 부하없이 DW로 가져오는 것이었으며, 마이그레이션에 대한 모든 기능을 포함한 솔루션이 아닌 손쉽게 수정, 조작 가능한 작은 유틸리티 제작을 목표로 한 프로젝트였습니다. 그리고 데이타를 가져오는 성능 보다는 안정성에 더 중점을 두어 제작하였습니다. 그리고 유지보수를 위해서도 언제든, 누구든 분석하기 쉽게 가능한 작은 코드 수를 유지하려고 노력했습니다. 혼자 개발을 했기 때문에 개발 시간 단축, 각 저장소에 대한 안정된 연결을 유지하기 위해 공개된 npm들을 최대한 활용하였습니다.

 

제작 중간부터는 사용 가능한 저장소를 하나 둘 늘리면서 내가 다뤄보지 않은 저장소에 대해서도 지원하면 좋겠다는 생각을 했고, 이 작은 프로젝트가 같은 고민과 과제를 안고 있는 누군가에게 도움이 되었으면 했습니다. 이때부터 오픈소스로 공개를 목표로 하게 되었습니다. 게다가 관리툴의 UI도 엉망이어서 누군가의 도움을 받길 원했습니다. (첫번째 목표였을지도... -_-a)

 

이 카테고리에는 Collo에 대한 활용 방법, 예시들을 올릴 예정입니다. 

 

https://github.com/blackwitch/Collo

 

 

 

 

'개발 이야기 > Collo' 카테고리의 다른 글

Collo - slideshare 링크 공유  (0) 2019.11.05
Collo - 실시간 마이그레이션 툴  (0) 2019.09.30

(* 이 글은 NodeJS 10.15.1 을 기준으로 작성되었습니다. )

한국은 GMT +9 를 기준으로 시간을 사용하며, 데이터를 다룰때도 일반적으로는 GMT +9 기준을 사용합니다. 단일 솔루션만 다룰 때는 거의 신경쓰지 않겠지만, 이기종 혹은 여러 솔루션을 한번에 컨트롤 할 때는 상당히 거슬리는 문제가 됩니다. 특히 월드 와이드 서비스를 하고 있다면요. 대부분의 DB에서 UTC 기준으로 값을 저장하기 때문에 큰 문제는 없지만, 간혹 일부 npm에서 datetime 자료형을 다룰 때 미묘한 차이가 있습니다.

node-mysql(구분을 위해 임시로 node-를 붙였습니다)의 경우, 저장된 datetime 값을 그대로 가져오기 때문에 전혀 문제가 없는데 반해, node-mssql은 useUTC옵션을 제대로 설정하지 않으면 잘못된 날짜 정보를 가져오게 되어 문제가 발생합니다. 

예를 들면 아래와 같습니다. 
(아래 테스트는 DB : MSSQL/2008R2, MySQL/MariaDB10.4, npm package version : node-mssql/4.2.0, node-mysql/2.16.0 하에서 진행되었습니다.)

MSSQL과 MySQL의 어떤 테이블의 datetime 컬럼에 "2019-01-01 00:00:00" 라는 값을 넣어보겠습니다. 이 값은 UTC 기준으로 값이 저장됩니다. string 형태로 출력해보면 "Mon, 31 Dec 2018 15:00:00 GMT", 실제 저장된 값은 "15462684000000"입니다.

이 값을 MSSQL의 management studio, MySQL는 prompt 혹은 HeidiSQL 모두에서 현지 시간으로 보입니다. 즉 "2019-01-01 00:00:00"으로 보이게 됩니다.

이제 node-mssql/node-mysql로 값을 읽어보면 아래와 같은 결과가 나옵니다.

2019-01-01 09:00:00  (MSSQL NPM으로 읽어온 경우) 
2019-01-01 00:00:00  (MySQL NPM으로 읽어온 경우) 

node-mssql으로 얻은 결과값이 이상한 것을 보실 수 있습니다. node-mssql에는 useUTC 옵션이 있습니다. default 갑이 true로 되어 있어, DB의 datetime이 어디를 기준으로 되어 있던 무조건 UTC 기준값으로 인지합니다. 그래서 최종 출력시에는 Asia/Seoul 의 시간대인 +9시간이 되어 출력된 것이죠. 

 

connection에 사용되는 config값에 useUTC 옵션값을 추가하고 값을 false로 설정하면 현지 시간값으로 읽어옵니다. 사용에 주의 하세요. 

 


이상입니다. 좋은 하루 되세요. :)





(windows 환경)


nodejs에서 80포트 열어 쓰던 어플이 있는데, 어느날 갑자기


error: listen EACCES 0:0:0:0:80 에러를 뱉으면서 안된다. --a


netstat -ano 하면 ip,port 그리고 해당 포트를 사용하는 PID를 볼 수 있다. 


찾아보니 4 ... System이 쓰고 있다고. -- ㅁ.... 모지..


이래저래 찾아보니.. 최근에 로컬에 mssql을 설치했는데.. 


SQL Server Reporting Services가 내부적으로 80포트를 쓰고 있었네 --;


서비스 중지 시키니 잘 돌아감. 


휴 ~ 



"MS-SQL 서버는 Select(RecordSet) 와 OUTPUT Parameter 동시에 사용할 때 해당 Select(RecordSet) 를 모두 읽어 들여야만 OUTPUT Parameter 에 값이 채워진다."


(출처) 
http://extern.tistory.com/20 

다른거 검색하다가 문득 정리 잘 된 글이 있어서 링크를 걸어본다. 
"임시 디렉터리를 찾을 수 없거나 디스크 공간이 부족합니다"

아직 sql 2000을 사용하고 있는데 오랜만에 들어가서 매니저를 열려고 하니 위와 같은 에러가 발생하네요. 

시스템 관리자가 temp 디렉토리를 지운 듯... -_-;


환경 변수 찾아가서 windows temp 디렉토리 설정 관련된 옵션을 하나씩 열고 그대로 저장 한번 해주고.. 최종 확인 누르고 나오면 temp 관련된 폴더가 다시 생성됩니다. 

다시 열면 그대로 진행됩니다. 

혹은 진짜 디스크 공간이 없거나.. 0-0


* 찾아보니 MMC 관련된 에러군요. ^^;;

+ Recent posts