기억창고

태국에 게임 서버 서비스를 하려고 이것 저것 테스트 하던 도중

이상하게 쿼리를 한번에 3만개 정도 실행 시키면, 데드락 걸리면서 쿼리가 제대로 실행이 안되는 경우가 발생했습니다.

처음엔 이게 시간과 관련된 쿼리라 태국의 로컬시간대랑 뭔가 연관이 있지 않을까 이것 저것 보던중

태국에서 셋팅한 윈도우 설정에 문제가 있다는걸 확인했습니다.

CPU가 Xeon X5675 @ 3.07Ghz 에다가 16GB 렘이 있는 시스템인데

윈도우 2003 (32bit)를 설치해서 메모리를 제대로 소화를 못하는거 같더군요.

그런 고로, 메모리를 설정하는 것을 구글에서 찾아내서 적용시켜 보니 쌩쌩 날아다니는 DB....

ㅁㄴㅀㄴㅏㅣㅓㅈㅎㅁ5!@$

어쨋든.... 메모리 설정에 대해선

http://toe10.tistory.com/63 을 참고해서 셋팅했습니다.

혹시 모를 폭파 위험에 여기서 제가 한 셋팅 순서도 올려 놓겠습니다.

1. MSSQL에서 AWE(Address Windowing Extensions)을 설정해야 합니다만,

32bit 운영체제 이므로 그전에 Lock page in memory 권한을 얻어와야 합니다.

시작 -> 프로그램 -> 관리도구 -> 서비스에서

SQL Server Agent(MSSQLSERVER)의 사용자 명을 확인합니다.

2. 시작 -> 실행 -> gpedit.msc 를 실행한뒤 아래 그림처럼

Lock pages in memory 권한을 1과 같은 사용자에게 줍니다.

3. 서버 설정 탭에 들어와서 AWE 사용을 체크하고

최대 서버 메모리를 설정합니다 (단위는 MB)

4. 네트워크 속성에서 네트워크 응용 프로그램을 취해 데이터 처리량 최대화를 선택합니다.

...

문제는 "Microsoft SQL Server 2005 포켓 컨설턴트 관리자용"이란 책에선 이 옵션을 피하라고 기술 되어있습니다만..

음....

특정 테이블의 레코드들만 따로 백업할때 쓰는 방법 입니다. 

(보안상 중요한 텍스트는 다 삭제)

command 에 들어가서

서버 점검하던중 뭔가 설정이 초기화 됬는지,

갑자기 서버 관리자 페이지에서 쿼리가 먹히지 않더군요.   (사용자 'x맨'이(가) 로그인 하지 못했습니다)

먼저 서비스 DB에 연결 되어있는건 확인됬고,

다음 게임 컨텐츠 DB에 연결 하려고, 안의 프로시저를 실행해본 결과, 특정 DB에만 접속을 못하고 아래의 에러가 나왔습니다.

결국, 이 얘긴 해당 DB에서 상대쪽 DB에 접근이 안된다는 의미이고,

msdn 의 http://support.microsoft.com/kb/307864/ko 의 도움말을 살펴본 결과

상대쪽 DB 보안 -> 로그인 -> 해당 계정의 기본 DB지정에 문제가 있음을 알게 되었습니다.

결국... 기본 DB를 연결해 주려는 DB로 설정하니 말끔이 해결...

... 알고나면 허망한 sql 세계 ㅠㅠ

출처 : http://tistory.kkwang.com/161

mssql은 복구를 위해 실제데이터(확장자 mdf)와 트랜잭션로그데이터(확장자 ldf)를 기록합니다.

mdf는 말그대로 디비에 저장되는 실데이터를 말하며, ldf는 트랜잭션로그, 즉 이러한 데이터를 이용한 읽기, 수정, 삭제등의 모든 로그를 기록합니다.

그래서 특정데이터에 대해 입출력이나 업데이트가 반복되는 경우 비정상적으로 ldf파일이 커지는 경우가 발생하게 됩니다. 이러한 일은 정상적인 억세스로 일어날 수도 있으나 잘못된 프로그래밍 또는 오류로 인한 무한루프에 의해 급증하는 경우도 발생하게 됩니다.

하드디스크가 매우 여유롭다면 몰라도 이런일로 하디디스크 풀이 나는 장애가 발생된다면 정말 난감해집니다.

사실 ldf파일이 없이도 mdf만으로 디비를 복구하는 방법도 있습니다만 제대로? MS의 정책에 따라 완벽한 복구를 위해서 ldf를 버리지 말고 용량을 잘 조절해서 사용하는 방법을 말씀 드리겠습니다.

일단 EM환경보다는 제가 사용하기 편리한 쿼리분석기에서의 작업을 기준으로 설명 드리겠습니다.

일단 쿼리분석기를 실행합니다.

### 트랜잭션로그를 백업할 디비를 지정하여 줍니다.

use testdb  — 저는 testDB를 지정한다고 가정하였습니다.

### 로그파일의 정보를 확인합니다.

dbcc loginfo

### 현재 지정된 디비가 사용하는 mdf 및 ldf파일의 경로, 이름 및 크기를 확인합니다.

exec sp_helpfile

### 위에서 정해준 디비의 로그를 백업해 줍니다.

backup Log testdb to disk=’d:\dbbackup\temp\testdb.bak’

go

선택 1, ### 트랜잭션 로그파일을 최소의 단위로 축소합니다.

backup log testdb with truncate_only

선택 2, ### 트랜잭션 로그파일을 삭제합니다.

backup log testdb with no_log

### 트랜잭션 로그파일을 10메가로 생성합니다.

dbcc shrinkfile (testdb_log, 10)

### mdf와 ldf파일이 제대로 잘 리사이징 되었는지 확인합니다.

exec sp_helpfile

모든 작업이 잘 마무리 되었다면, 이제는 갑작스런 트랜잭션로그의 증가로 문제가 되는 것을 방지하기 위해
트랜잭션로그파일의 최대크기를 지정해놓는 방법도 좋습니다.

alter database testdb

modify file ( name = testdb_log, maxsize = 200 mb )

go

위 의 과정을 진행하시면 트랜잭션로그는 위에서 지정한데로 200메가를 한계치로 생성 삭제 됩니다.
트랜잭션로그의 용량은 데이터의 중요도 및 규모에 따라 정책적으로 유지하셔야 하는 부분입니다.
200메가는 예제로 적어놓은 사이즈입니다.

또한 위의 과정 중 축소와 삭제는 둘 중 원하시는 방법을 선택적으로 사용하시면 됩니다.

////////////////////////////////////////////////////////////////////////////////////////

추가적으로 하다가 트랜잭션 로그 파일을 10메가로 생성할때,

메시지가 발생되어 에러가 났었지만,

select * from sys.database_files 

쿼리를 실행시킨후 나온 DB이름을 대입하니 문제없이 실행 되었습니다.

DB를 다른 컴으로 옮길일 이 있어서, 백업을 받은 다음, 그 파일을 다른 컴퓨터에서 복원을 시키려 하는데...

같은 이름의 데이터베이스 이름을 만들고, 복원시 덮어 써버리는 옵션을 이용해서 해보려니 가끔

restore database is terminating abnormally ... SQL error 3154

하면서 실행이 안됬다...

뭔가 지웠다 다시 하라니 글들을 실험해 봤지만.. 영...

그러다 해외 사이트에서 발견한 아주 간단한 방법..

ㅡ_ㅡ.... 오전동안 뻘짓한 시간이.. ㅠㅠ