일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 | 29 |
30 | 31 |
- Kibana
- ChatGPT
- elasticsearch
- MSSQL
- ssh
- API
- 영어
- Python
- JS
- 유니티
- AWS
- Linux
- 엘라스틱서치
- build
- docker
- logstash
- Git
- mariadb
- MySQL
- s3
- error
- 구글
- nodejs
- 설정
- unity
- Windows
- sample
- Ai
- JavaScript
- Today
- Total
목록복구 (2)
가끔 보자, 하늘.
MSSQL에서 DB를 복구 시 복구된 DB에 연결된 사용자가 있어 재설정 시 복잡한 경우가 발생합니다. 아래와 같은 순서로 복구를 진행하면 편리합니다. 복구 전 사용한 같은 이름의 사용자를 생성합니다. 복구 전이므로 기본 데이터베이스는 기본으로 설정합니다. DB를 복구합니다. 이때 같은 이름의 사용자가 있으면 복구된 DB에서는 초기화되어 자동 삭제됩니다. 이제 보안 -> 로그인 으로 가서 사용하려는 사용자의 기본 데이터베이스도 설정하고, 사용자 매핑에서 사용할 DB를 지정하고 스키마 설정을 합니다. 위와 같이 진행하면 깔끔하게 마무리 됩니다. 만약 복구를 선진행했다면 설정된 사용자을 지우고 다시 생성, 연결해야 합니다. 이때 사용자를 삭제하려면 데이터베이스의 스키마를 소유하고 있어 삭제할 수 없다는 에러..
타 팀에서 서비스 중인 DB 중 트랜잭션 로그 백업 처리 스케쥴을 등록하지 않아 디스크 용량이 0이 되버려서 이러지도 저러지도 못하는 경우가 있어 처리해준게 벌써 두 번째. RDBMS에서 기본 복구 모델 설정은 보통 full로 되어 있기 때문에 Management studio에서 축소 처리를 해도 백업 전에는 줄어들지 않습니다. DB 관리를 위해 트랜잭션 파일 옵션에 대해서는 두 가지를 신경써야 합니다. 1. 사고 발생 시 복구가 필요한 DB 인가.. 중요한 정보가 기록되고 사고 발생 시 분 단위로 정보를 복구해야 하는지를 생각해서 꼭 필요한 경우 full로 그렇지 않고 하루 혹은 주 단위로 전체 백업을 한 파일로 복구 하거나 혹은 분실되도 상관없는 DB는 simple로 설정하는게 좋습니다. 2. 스케쥴..