가끔 보자, 하늘.

뭔가 실수로 transaction log가 백업되지 않아 커지는 문제가 발생했다면 ldf 파일을 강제로 줄이는 방법이 있습니다. 2008 버전 정도에서는 backup log [db명] with truncate_only 라는 쿼리를 실행해 ldf 파일을 비울 수 있습니다. 만약 truncate_only' is not a recognized backup option 라는 오류가 발생하는 버전이라면 backup log [db명] to disk='null' 이라는 쿼리를 실행해 ldf 파일을 비울 수 있습니다. 간혹 백업 처리 과정마저도 문제가 발생하는 경우는 Database 백업 모드를 simple로 조정 후 shrinkfile('db log logical name' , 1) 이라는 쿼리를 실행하면 log 파..

에러 메세지(error 15136) : "데이터베이스 보안 주체는 데이터베이스의 스키마를 소유하여 삭제할 수 없습니다.", 다른 팀에서 MSSQL서버를 scale up을 위해 이관하던 중 어떤 이유에선지 특정 계정이 db의 owner로 지정된 경우가 최근 발생한 것을 확인했었습니다. 권한 조정이 필요한데 특정 계정이 삭제 안된다는 문의가 와서 확인을 했더니 sp 실행권한만 있어야 할 계정이 db_owner로 떡하니 설정되어 있더군요. 이런 경우 GUI에서 계정 해제가 불가능하므로 쿼리로 owner 권한을 dbo로 이관해야 합니다. 다음 쿼리로 조정이 가능합니다. alter authorization on schema::db_owner to dbo; 위와 같이 권한을 위임을 하면 해당 계정을 삭제하거나 권한..

최근 아주 오래된 MSSQL DB (2008 R2)를 MySQL로 마이그레이션 작업을 하면서 AWS SCT(Schema Conversion Tool)를 사용해며 관련 내용을 정리해 보았습니다. 이 링크에서 SCT 설치파일과 사용할 JDBC 드라이버를 다운받아 설치합니다. 그리고 Settings -> Global Settings -> Drivers에서 MSSQL과 MySQL 드라이버를 설정합니다. 그리고 상단 메뉴에서 File -> New Project 를 선택해 새로운 프로젝트를 생성합니다. MSSQL 2008 R2는 SCT에서 지원하지 않습니다. 별도 MSSQL 라이센스가 없어도 AWS Console -> RDS에서 Free tier로 SQL 서버를 생성해 사용 후 삭제하면 거의 비용이 들지 않습니다...

MSSQL에서 DB를 복구 시 복구된 DB에 연결된 사용자가 있어 재설정 시 복잡한 경우가 발생합니다. 아래와 같은 순서로 복구를 진행하면 편리합니다. 복구 전 사용한 같은 이름의 사용자를 생성합니다. 복구 전이므로 기본 데이터베이스는 기본으로 설정합니다. DB를 복구합니다. 이때 같은 이름의 사용자가 있으면 복구된 DB에서는 초기화되어 자동 삭제됩니다. 이제 보안 -> 로그인 으로 가서 사용하려는 사용자의 기본 데이터베이스도 설정하고, 사용자 매핑에서 사용할 DB를 지정하고 스키마 설정을 합니다. 위와 같이 진행하면 깔끔하게 마무리 됩니다. 만약 복구를 선진행했다면 설정된 사용자을 지우고 다시 생성, 연결해야 합니다. 이때 사용자를 삭제하려면 데이터베이스의 스키마를 소유하고 있어 삭제할 수 없다는 에러..

타 팀에서 서비스 중인 DB 중 트랜잭션 로그 백업 처리 스케쥴을 등록하지 않아 디스크 용량이 0이 되버려서 이러지도 저러지도 못하는 경우가 있어 처리해준게 벌써 두 번째. RDBMS에서 기본 복구 모델 설정은 보통 full로 되어 있기 때문에 Management studio에서 축소 처리를 해도 백업 전에는 줄어들지 않습니다. DB 관리를 위해 트랜잭션 파일 옵션에 대해서는 두 가지를 신경써야 합니다. 1. 사고 발생 시 복구가 필요한 DB 인가.. 중요한 정보가 기록되고 사고 발생 시 분 단위로 정보를 복구해야 하는지를 생각해서 꼭 필요한 경우 full로 그렇지 않고 하루 혹은 주 단위로 전체 백업을 한 파일로 복구 하거나 혹은 분실되도 상관없는 DB는 simple로 설정하는게 좋습니다. 2. 스케쥴..

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에서 비교해서 결과를 돌려주기 때문에 그대로 사용 가능합니다. 그런데 공식 문서에는..

워낙 가끔 만지다보니 가끔 혼동이 와서 정리합니다. Windows Server 2019 Standard ( 64bit ) , MSSQL Standard 2017( 64bit ) (1) 에 사용할 이름을 설정, (2)에 연결할 DB의 IP, PORT를 입력합니다. MSSQL 끼리 연결할 때 다른 설정은 굳이 입력하지 않아도 됩니다. 연결할 DB에서는 "보안" 항목에 입력할 계정에 필요한 권한이 설정되어 있을 것이므로 (입력된 것이 없다면 연결할 DB에 계정 생성, 필요한 사용 권한 설정을 해 두시면 됩니다.) 다른 설정은 필요없습니다. 카탈로그에 사용할 DB 이름을 넣을 수 있지만 사용 권한 설정에 필요한 정보가 다 있으므로 입력이 불필요합니다. 그리고 "보안" 페이지에서 원격 로그인, 암호를 입력한 후 ..

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 불러오는 중입니다...