SELECT
OBJECT_SCHEMA_NAME(a2.object_id) AS SchemaName,
a2.name AS TableName,
a1.rows as [RowCount],
CAST(ROUND(((a1.reserved + ISNULL(a4.reserved,0)) * 8) / 1024.00, 2) AS NUMERIC(36, 2)) AS ReservedSize_MB,
CAST(ROUND(a1.data * 8 / 1024.00, 2) AS NUMERIC(36, 2)) AS DataSize_MB,
CAST(ROUND((CASE WHEN (a1.used + ISNULL(a4.used,0)) > a1.data THEN (a1.used + ISNULL(a4.used,0)) - a1.data ELSE 0 END) * 8 / 1024.00, 2) AS NUMERIC(36, 2)) AS IndexSize_MB,
CAST(ROUND((CASE WHEN (a1.reserved + ISNULL(a4.reserved,0)) > a1.used THEN (a1.reserved + ISNULL(a4.reserved,0)) - a1.used ELSE 0 END) * 8 / 1024.00, 2) AS NUMERIC(36, 2)) AS UnusedSize_MB
FROM
(SELECT
ps.object_id,
SUM (CASE WHEN (ps.index_id < 2) THEN row_count ELSE 0 END) AS [rows],
SUM (ps.reserved_page_count) AS reserved,
SUM (CASE
WHEN (ps.index_id < 2) THEN (ps.in_row_data_page_count + ps.lob_used_page_count + ps.row_overflow_used_page_count)
ELSE (ps.lob_used_page_count + ps.row_overflow_used_page_count)
END
) AS data,
SUM (ps.used_page_count) AS used
FROM sys.dm_db_partition_stats ps
GROUP BY ps.object_id) AS a1
LEFT OUTER JOIN
(SELECT
it.parent_id,
SUM(ps.reserved_page_count) AS reserved,
SUM(ps.used_page_count) AS used
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.internal_tables it ON (it.object_id = ps.object_id)
WHERE it.internal_type IN (202,204)
GROUP BY it.parent_id) AS a4 ON (a4.parent_id = a1.object_id)
INNER JOIN sys.all_objects a2 ON ( a1.object_id = a2.object_id )
WHERE a2.type <> N'S' and a2.type <> N'IT'
ORDER BY ReservedSize_MB DESC
다음 예제를 복사하여 쿼리 창에 붙여넣고실행을 선택합니다. 이 예에서는모델데이터베이스의 복구 모델을 배우기 위해sys.databases카탈로그 뷰를 쿼리하는 방법을 보여줍니다.
복구 모델을 변경하려면
데이터베이스 엔진에 연결합니다.
표준 도구 모음에서새 쿼리를 선택합니다.
다음 예제를 복사하여 쿼리 창에 붙여넣고실행을 선택합니다. 이 예에서는modelALTER DATABASEFULL문의SET RECOVERY옵션을 사용하여데이터베이스의 복구 모델을로 변경하는 방법을 보여 줍니다.
-- 복구 모델을 보려면
SELECT name, recovery_model_desc
FROM sys.databases
WHERE name = 'model' ;
-- 복구 모델을 변경하려면
USE [master] ;
ALTER DATABASE [model] SET RECOVERY FULL ;
SSMS에서 하기.
DB 속성에서 옵션 들어가서 복구모델 선택하기.
단순(Simple) 데이터베이스 복구 모델을 선택하는 몇 가지 이유는 다음과 같습니다.
개발 및 테스트 데이터베이스에 가장 적합합니다.
데이터 손실이 허용되는 단순한 보고 또는 애플리케이션 데이터베이스
장애 시점 복구는 전체 및 개별 백업 전용입니다.
관리 오버헤드 없음
다음을 지원합니다.
전체 백업
차등 백업
복사 전용 백업
파일 백업
부분 백업
장점: 고성능 대량 복사 작업이 가능하고 로그 공간을 확보하여 공간 요청을 작게 유지합니다.
단점: 가장 최근의 데이터베이스 또는 불일치 백업을 다시 빌드해야 하므로 변경됩니다.
Full
전체 복구 모델을 사용하면 SQL Server는 사용자가 백업할 때까지 트랜잭션 로그를 예약합니다.이 복구 모델에서는 모든 거래(DDL(데이터 정의 언어) + DML(데이터 조작 언어))가 트랜잭션 로그 파일에 완전히 기록됩니다.로그 순서는 손상되지 않고 데이터베이스가 작업을 복원할 수 있도록 보존됩니다.단순 복구 모델과 달리 트랜잭션 로그 파일은 CHECKPOINT 작업 중에 자동으로 잘리지 않습니다.
데이터베이스 오류가 발생했을 때 전체 복구 모델을 사용하여 데이터베이스를 복원하는 가장 유연성을 얻을 수 있습니다. 지정 시간 복원, 페이지 복원 및 파일 복원을 포함한 모든 복원 작업이 지원됩니다.
전체 데이터베이스 복구 모델을 선택하는 이유:
미션 크리티컬 애플리케이션 지원
고가용성 키 설계
0 또는 명목 데이터 손실로 모든 데이터 복구를 용이하게 하기 위해
데이터베이스가 여러 파일 그룹을 갖도록 설계되었으며 읽기/쓰기 보조 파일 그룹 및 선택적으로 읽기 전용 파일 그룹의 부분적 복원을 수행하려는 경우
임의 시점 복원 허용
개별 시트 복원
높은 관리 오버헤드 유지
다음을 지원합니다.
전체 백업
차등 백업
트랜잭션 로그 백업
복사 전용 백업
파일 및/또는 파일 그룹 백업
부분 백업
장점: 데이터 파일의 유실 또는 손상으로 인한 작업 오작동이 없습니다.임의의 시점으로 회복될 수 있습니다.
단점: 로그가 손상되면 가장 최근의 로그 백업 이후의 변경 사항을 다시 작성해야 합니다.
데이터베이스가 개발 또는 테스트 서버인 경우 단순 복구 모델이 대부분 적합해야 합니다.그러나 데이터베이스가 프로덕션 데이터베이스인 경우 일반적으로 전체 복구 모델을 사용하는 것이 좋습니다.전체 복구 모델은 대량 로그 복구 모델로 보완할 수 있습니다.물론 데이터베이스가 작거나 데이터 웨어하우스의 일부이거나 데이터베이스가 읽기 전용인 경우에도 마찬가지입니다.
누군가는 데이터를 새로운 석유라 부르고, 누군가는 새로운 금이라고도 부른다. 철학자와 경제학자들은 비유의 적절성 대해 논쟁할 수 있겠지만, 데이터 기반 의사 결정을 도모하는 기업에 데이터 구성 및 분석이 필수적이라는 점은 의심의 여지가 없다.
일단은 견고한 데이터 관리 전략이 핵심이다. 데이터 거버넌스, 데이터 운영, 데이터 웨어하우징, 데이터 엔지니어링, 데이터 분석, 데이터 과학 등을 포괄하는 데이터 관리는 올바르게 수행될 경우 각종 비즈니스에서 경쟁 우위를 가져다줄 수 있다.
좋은 소식은 데이터 관리의 많은 측면이 잘 정립돼 있으며, 수십 년 동안 발전해 온 원칙이 존재한다는 점이다. 예를 들어, 적용하기 어렵거나 이해하기에 간단하지 않을 수 있지만, 많은 과학자와 수학자 덕분에 기업은 이제 데이터를 분석하고 결론을 내리기 위한 다양한 프레임워크를 갖게 됐다. 분석 한계를 나타내는 오차 막대를 그리는 통계 모델도 있다.
그러나 데이터 과학과 이를 뒷받침하는 다양한 학문에 대한 연구에서 얻은 모든 장점에도 불구하고 우리는 머리를 긁적거릴 때가 있다. 현장에서 벽에 부딪히는 경우가 많기 때문이다. 때로는 너무 많은 데이터를 수집하고 구성하는 역설적인 문제도 있다. 일부는 철학적이며 우리의 추상적 역량을 시험한다. 그리고 처음 데이터를 수집하는 데서는 개인 정보 보호 문제가 대두되고 있다.
다음은 수많은 기업에서 데이터 관리를 어려운 과제로 만드는 몇 가지 어두운 비밀들이다.
애물단지 비정형 데이터 기업 아카이브에 저장되어 있는 데이터의 대부분은 구조화되어 있지 않다. 은행의 콜센터 직원이 작성한 문자 메모를 검색하기 위한 인공 지능(AI) 사용을 원하는 경우가 있다. 이 문장에는 은행의 대출 및 서비스를 개선하는 데 도움이 될 수 있는 통찰이 담겨 있을 수 있다. 그러나 메모 데이터는 기록할 내용에 관해 서로 다른 생각을 가진 수백 명의 사람들이 작성한 것이다. 또한, 직원들은 서로 다른 작문 스타일과 능력을 가지고 있고, 일부는 전혀 쓰지 않았다. 또 어떤 사람들은 주어진 전화에 대해 너무 많은 정보를 기록한다. 수십 년 동안 수백 명의 직원이 작성한 텍스트 더미가 있다면, 구조화 수준이 훨씬 더 약해질 수 있다.
정형 데이터라도 비정형인 경우 좋은 데이터 과학자와 데이터베이스 관리자는 각 분야의 유형과 구조를 명료하게 지정해 데이터베이스를 마련한다. 때로는 필드의 값을 특정 범위의 정수 또는 미리 정의된 선택으로 제한한다. 하지만 사람들은 데이터베이스가 주름과 결함을 추가하는 방법을 생각해낸다.
필드가 비어 있는 경우도 있다. 질문이 적용되지 않는다고 생각할 때 ‘n.a.’를 넣기도 하지만, 그저 대시 기호를 넣는 이들도 있다. 사람들은 심지어 이름을 해마다, 날마다 다르게 표시하기도 한다.
우수한 개발자는 유효성 검사를 통해 이런 문제 중 일부를 파악한다. 훌륭한 데이터 과학자는 정리를 통해 이런 불확실성을 어느 정도 줄일 수도 있다. 그러나 탁월하게 구조화된 표에도 의심스러운 항목이 있고, 이런 의심스러운 항목에 알 수 없는 항목과 분석 오류가 발생할 수 있다. 좌절감을 느끼게 하는 현실이다.
너무 엄격하거나 느슨한 데이터 스키마 데이터팀이 스키마 제약 조건을 아무리 자세히 설명하려 해도 다양한 데이터 필드의 값을 정의하기 위한 스키마는 완벽하기 어렵다. 너무 엄격하거나 너무 느슨하다. 데이터팀에서 엄격한 제약 조건을 추가하면 사용자는 허용 가능한 값의 좁은 목록에서 답을 찾을 수 없다고 불평한다. 스키마가 너무 수용적이면 사용자는 일관성이 거의 없이 이상한 값을 추가할 수 있다. 스키마를 올바르게 조정하는 것은 거의 불가능할 지경이다.
매우 엄격한 데이터 법률 개인정보 보호 및 데이터 보호에 관한 법률은 이미 강력하며, 점점 더 강력해지고 있다. GDPR, HIPPA 및 각종 규제 사이에서 데이터를 수집하는 것은 매우 어려울 수 있으며, 해커의 침입에 대응하기란 훨씬 더 위험할 수 있다. 많은 경우에 프로그래머나 데이터 과학자보다 변호사에게 비용을 지출하는 것이 더 쉬울 수 있다. 이런 골칫거리로 인해 일부 기업은 데이터를 제거할 수 있는 즉시 데이터를 폐기한다.
엄청난 데이터 정리 비용 많은 데이터 과학자가 자신의 작업 중 90%가 데이터를 수집하고, 일관된 형식으로 만들고, 끝없는 구멍이나 실수를 처리하는 것이라고 본다. 데이터를 가지고 있는 사람은 항상 “CSV에 모든 것이 있다”라고 말할 것이다. 그러나 그들은 빈 필드나 잘못된 특성을 언급하지 않는다. 실제로 통계 분석을 수행하기 위해 R 또는 파이썬에서 루틴을 시작하는 것보다 데이터 과학 프로젝트에서 사용할 데이터를 정리하는 데 10배나 더 많은 시간을 소비하기 쉽다.
사용자의 의심 증가 최종 사용자와 고객이 기업의 데이터 관리 관행에 대해 점점 더 의심을 품고 있다. 일부 AI 알고리즘에 대한 불안감과 두려움이 증폭되고 있다. 일거수일투족을 감시하는 듯한 반응을 보이기도 한다. 이런 두려움은 규제를 조장하고 종종 기업과 선의의 데이터 과학자를 괴롭힌다. 사용자가 의도적으로 가짜 값이나 오답으로 데이터 수집을 방해하는 경향을 보이는 것이다. 때로는 작업의 절반이 악의적인 파트너 및 고객을 상대하는 업무가 될 수 있다.
외부 데이터와의 통합 위험성 공격적인 기업은 자사의 정보를 서드파티 데이터 및 인터넷에 떠도는 방대한 개인화된 정보와 통합하는 방법을 모색하고 있다. 실제로 일부 도구는 모든 고객에 대한 데이터를 흡수해 각 구매에 대해 개인화된 정보를 작성하겠다고 공개적으로 공언한다. 그렇다, 이들은 사용자의 패스트푸드 구매와 신용 점수를 추적하는 데 첩보기관이 테러리스트를 추적하는 데 사용하는 기술을 사용한다. 사람들이 불안해하는 것이 사실 당연하다.
데이터 사용을 단속하는 규제 당국 데이터 분석이 언제 어떤 선을 넘을지 알기 어렵지만, 일단 선을 넘으면 규제 당국이 나타난다. 캐나다의 최근 사례에서, 정부는 일부 도넛 가게가 어떻게 경쟁업체에서 쇼핑하는 고객들을 추적하고 있는지 조사했다.
정부는 보도 자료를 통해 “조사 결과, 팀 호튼스가 미국의 서드파티 위치 서비스 업체와 맺은 계약에 너무 모호하고 허용적인 표현이 포함되어 있었다. 이로 인해 회사가 ‘비식별화된’ 위치 데이터를 판매할 소지를 남겼을 것”이라고 밝혔다. 도대체 무엇을 위해? 더 많은 도넛을 팔기 위해서? 규제기관은 개인정보와 관련된 모든 것에 점점 더 주의를 기울이고 있다.
도출한 결과가 무가치함 우리는 뛰어난 알고리즘이 모든 것을 더 효율적이고 수익성 있게 만들 수 있다고 상상한다. 그리고 때로는 그런 알고리즘을 실제로 구현할 수 있다. 그러나 비용이 문제이다.
실제로 소비자는 물론 심지어 기업까지도 정교한 데이터 관리 체계에서 나오는 표적 마케팅의 가치에 점점 더 의문을 제기하고 있다. 이미 구매한 아이템에 대한 광고가 노출되는 것을 자주 경험했을 것이다. 엄격한 데이터 분석을 통해 실적이 낮은 공장을 식별했더니, 회사가 건물에 30년 임대 계약을 체결했을 수도 있다. 기업은 데이터 과학이 비현실적인 답을 산출할 가능성에 대비해야 한다.
결국 인간의 직관에 따라 결정 숫자는 높은 정확도를 제공하지만, 사람이 숫자를 어떻게 해석하는지가 더 중요한 경우도 많다. 모든 데이터 분석과 AI 마법이 끝난 후에 대부분 알고리즘은 일부 값이 임계 값을 초과하는지 또는 미만 인지에 대한 결정을 내려야 한다.
가령 경찰은 제한 속도의 20%를 초과하는 차량에 속도위반 고지서를 주려고 한다. 이런 임계값은 종종 임의의 값이다. 데이터에 적용할 수 있는 모든 과학 및 수학의 경우, ‘데이터 기반’ 프로세스에는 생각보다 더 많은 회색 지대가 있다. 기업이 데이터 관리 프랙티스에 투입한 방대한 자원에도 불구하고 결국 의사 결정에 영향을 미치는 최대 요인은 인간의 직관인 경우가 많다.
폭발적인 데이터 스토리지 비용 테라바이트당 가격은 계속 떨어지고 있지만 프로그래머는 더 빠르게 데이터 비트를 모으고 있다. 사물 인터넷 디바이스는 계속해서 데이터를 업로드하고, 사용자는 이런 바이트의 풍부한 컬렉션을 영원히 탐색할 것으로 기대한다. 동시에 컴플라이언스 담당자와 규제기관은 감사를 위해 계속해서 더 많은 데이터를 요구한다. 실제로 다시 액세스되는 데이터의 비율은 계속 낮아지고 있다. 그저 데이터가 하염없이 쌓여만 가는 것이다.
