방법

USE master;
GO
ALTER DATABASE MyTestDatabase SET SINGLE_USER WITH ROLLBACK IMMEDIATE
GO
ALTER DATABASE MyTestDatabase MODIFY NAME = MyTestDatabaseCopy
GO 
ALTER DATABASE MyTestDatabaseCopy SET MULTI_USER 
GO

참고 자료

[https://docs.microsoft.com/ko-kr/sql/relational-databases/databases/rename-a-database?view=sql-server-2017]

구성 시 주의점

  • Windows Cluster 용도 VIP 1ea, 리스너 용도 VIP 1 ea 필요함
  • 구성 장비의 IP는 Static IP로 설정
    • DHCP로 IP를 할당 받을 경우 Cluster 및 리스너 VIP를 설정 할 수 없음
  • 이중화 구성 장비 간 아래 PORT의 방화벽 오픈이 필요 ( 오픈해야 하는 PORT가 많으므로 보안 이슈 확인 후 장비 간 Any 오픈 )
    • MSSQL 실행 PORT : 1433(기본포트)
    • 클러스터 서비스 : 3343(TCP, UDP)
    • RPC : 135(TCP)
    • 클러스터 어드민 : 137(UDP)
    • 랜덤 포트 : 1024 ~ 65535, 49152 ~ 65535
  • 원할한 Failover를 위해 쿼럼 서버를 추가
    • 장비가 3 ea 이상인 경우도 쿼럼 서버를 추가하는것이 안전함.
  • Active와 Standby의 DB 데이터 저장 구조(mdf, ldf Path)가 같아야함
  • EnterPrise 버전만 여러개의 DB를 AlwaysOn 구성이 가능
    • Standard 버전은 하나의 DB만 AlwaysOn 구성이 가능
  • 안정적인 AlwaysOn 운영을 위해 클러스터 장비 간 Heartbeat Network 구성이 필요
  • Remote Registry Service 사용
  • 로컬 보안 설정의 ‘네트워크에서 이 컴퓨터로 엑세스’ 속성에 “Authenticated Users”가 포함되어야 함)
  • 클러스터 구성 시 스토리지를 공유해서 사용하지 않도록 설정
    • 스토리지 공유 : MSCS(Microsoft Cluster Service)방식 이중화
    • 스토리지 공유 하지 않음 : AlwaysOn 방식 이중화
  • AlwaysOn 구성 후, Alwayon Group의 OwnerNode와 클러스터 그룹의 OwnerNode 그룹이 일치 해야함
    • powerShell의 ‘get-Cluster-Group’ 명령어로 확인 가능
    • Node 이동은 Failover Clustering의 ‘추가 작업’ -> 코어 클러스터 리소스 이동 -> 노드 선택 메뉴로 변경 가능
  • 일반적으로 AlwaysOn 구성 시, 처리 속도는 20% ~ 30% 느려질 수 있음
    • 처리 지연이 발생하는 경우 mdf, ldf 모두 고성능 SSD로 변경하거나, 동기화 간 암호화 로직을 제거하는 방법이 있음.

참고 자료

[https://docs.entcloud.swisscom.com/guide/managed-services/managed-os/technical-description/windows-server-failover-cluster/#network]

[SQL Server 성능 최적화를 위한 Disk 설정]

  • 최소 2 개의 PREMIUM SSD 디스크 를 사용 (로그 파일용 1 개, 데이터 파일용 1 개).
    • HDD 및 표준 SSD의 경우 안정성 확보가 힘들기 때문에 메인 DB의 경우 프리미엄 SSD (필수)
    • 보다 안정적인 서비스를 위해 OS 영역도 프리미엄 SSD를 사용 (권장)
  • 프리미엄 SSD의 경우 Disk 캐시 설정을 한다 ( HDD, 표준 SSD의 경우 캐시 설정을 하지 않음)
    • 데이터 파일을 처리하는 디스크의 경우 읽기 전용 캐시를 사용 하도록 설정 (필수)
    • 로그 파일을 처리하는 디스크의 경우 캐시를 사용하지 않는다 (필수)
    • OS 영역의 디스크를 프리미엄 SSD로 구성한 경우 읽기/쓰기 캐시를 사용 (권장)
  • 운영체제 디스크에 데이터 및 로그 파일을 지정하지 않음
  • 임시 디스크(D:)에 데이터 및 로그 파일을 지정하지 않음
    • 임시 디스크의 경우 재부팅이 되는경우 데이터가 모두 삭제됨.
    • 임시 디스크의 경우 SSD를 사용하기 때문에 만약 프리미엄 SSD를 사용하지 않는 경우 tempDB를 위치 시키면 성능 향상에 도움이 됨.
    • tempDB를 임시 디스크에 사용하는 경우 재부팅시 파일 및 모든 디렉토리가 삭제 되기 때문에, 별도 디렉토리를 생성하지 않고 tempDB 위치를 지정해야함.
    • MSSQL을 실행시키는 계정이 임시 디스크 사용 권한이 없는 경우 DB 실행이 되지 않을 수 있음.
  • 데이터 처리량을 늘리기 위해서 데이터 디스크를 스트라이핑 하여 분산 처리
  • 최고 성능을 위해서는 울트라 SSD를 사용
  • NTFS 할당 단위 크기: 데이터 디스크를 포맷할 때 TempDB뿐만 아니라 데이터 및 로그 파일에 대해 64KB 할당 단위 크기를 사용하는 것이 좋습니다. (MSSQL 공간 관리 기본 단위(extents)로 설정)

[디스크 타입별 정리]

타입 표준 프리미엄 설명
OS HDD
캐싱 정책 Read/Write
프리미엄 SSD
캐싱 정책 Read/Write
- Default가 운영 체제 형식(캐싱 정책 : 읽기/쓰기) 이지만, 성능이 중요한 애플리캐이션의 경우 운영 체제 디스크 형식 대신 데이터 디스크 형식을 사용하는것이 좋음.
D: - Temp TempDB(MSSQL) - - D 시리즈, Dv2 시리즈 및 G 시리즈 VM의 경우 이러한 VM의 임시 드라이브는 SSD를 기반으로 사용
- TempDB가 과도하게 사용될 경우(예: 임시 개체 또는 복잡한 조인) D 드라이브에 TempDB를 저장하면 TempDB 처리량은 더 높아지고 TempDB 대기 시간은 줄어들 수 있습니다.
Data 표준 SSD
캐싱 정책 : None
프리미엄 SSD
캐싱 정책 : Read
TempDB(MSSQL)
- 프리미엄 SSD를 지원하는 VM(DS 시리즈, DSv2 시리즈 및 GS 시리즈)의 경우 읽기 캐싱이 사용되는 프리미엄 SSD를 지원하는 디스크에 TempDB를 저장하는 것이 좋습니다.
- 프리미엄 SSD를 사용하지 않는 경우 데이터 디스크에서 캐싱을 사용하지 않는게 좋음
Log HDD
캐싱 정책 : None
프리미엄 SSD
캐싱 정책 : None
- 로그와 같이 쓰기 워크로드가 대량으로 있는 경우 캐싱을 사용하지 않을 때 성능이 향상됨.
Backup HDD
캐싱 정책 : None
HDD
캐싱 정책 : None
- 로그와 같이 쓰기 워크로드가 대량으로 있는 경우 캐싱을 사용하지 않을 때 성능이 향상됨.

※ 참고 자료 : https://docs.microsoft.com/ko-kr/azure/virtual-machines/windows/sql/virtual-machines-windows-sql-performance


to Top