반응형
250x250
Notice
Recent Posts
Recent Comments
Link
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
Tags
- unity
- MySQL
- elasticsearch
- JavaScript
- 엘라스틱서치
- Python
- error
- 유니티
- API
- sample
- JS
- ChatGPT
- 영어
- build
- Git
- logstash
- mariadb
- Linux
- Ai
- ssh
- docker
- nodejs
- AWS
- s3
- Kibana
- 구글
- Windows
- 설정
- MSSQL
Archives
- Today
- Total
목록SHRINKFILE (1)
가끔 보자, 하늘.
MSSQL RECOVERY 옵션
타 팀에서 서비스 중인 DB 중 트랜잭션 로그 백업 처리 스케쥴을 등록하지 않아 디스크 용량이 0이 되버려서 이러지도 저러지도 못하는 경우가 있어 처리해준게 벌써 두 번째. RDBMS에서 기본 복구 모델 설정은 보통 full로 되어 있기 때문에 Management studio에서 축소 처리를 해도 백업 전에는 줄어들지 않습니다. DB 관리를 위해 트랜잭션 파일 옵션에 대해서는 두 가지를 신경써야 합니다. 1. 사고 발생 시 복구가 필요한 DB 인가.. 중요한 정보가 기록되고 사고 발생 시 분 단위로 정보를 복구해야 하는지를 생각해서 꼭 필요한 경우 full로 그렇지 않고 하루 혹은 주 단위로 전체 백업을 한 파일로 복구 하거나 혹은 분실되도 상관없는 DB는 simple로 설정하는게 좋습니다. 2. 스케쥴..
개발 이야기/DB, 데이터분석, AI
2020. 9. 9. 11:21