 TechNet 인터뷰: Kalen Delaney에게 듣는 SQL Server 진행- Joyce Thompson
1987년 컴퓨터 공학 석사로 버클리를 졸업한 직후, Kalen Delaney는 당시 여섯 명으로 구성되어 있던 Sybase의 전화 고객 지원 팀의 일원으로 SQL Server에 입문했습니다. 고객 지원의 최전선에 섰던 이때부터 그녀는 SQL Server와 그 사용 고객들에 대한 깊은 지식을 쌓을 수 있게 되었고 이때 만났던 기술 전문가들은 그녀가 오늘날 존경 받는 "단일 제품 전문가"가 되는 데 큰 도움을 주었습니다. Kalen은 현재 Microsoft의 SQL Server 워크숍을 창설하고 이끌면서 기업 고객과 독립 기술 교육 센터 중심의 활동을 벌여 나가고 있습니다. Ron Soukup의 베스트셀러 Inside SQL Server 6.5의 뒤를 이어 Kalen은 Ron의 저작을 완전히 업데이트해서, 클라이언트 서버 모델과 저장 프로시저 등과 같은 혁신을 가져온 SQL Server 최신 버전의 구현과 아키텍처, 설계 등에 관한 거의 천 여 페이지에 이르는 안내서 Inside SQL Server 7.0을 저술했습니다. Kalen Delaney는 SQL Server에 관해 상세하게 알고 있을 뿐 아니라, 이 제품에 진정한 애정을 갖고 있습니다. 시애틀 서부 지방에 살고 있지만 전세계의 SQL Server 전문가들이 그녀의 동료입니다. 지식을 공유하고자 하는 그녀의 열린 자세로 인해 그녀는 중요한 인물로 대접 받고 있으며, 세 네 개의 TechNet 무료 구독권을 포함해 그에 따르는 모든 권리와 특권을 보유하고 있습니다. 항상 생기 있고 웃음이 많은 Kalen은 어느 화창한 가을 오후, 그녀의 네 아이 중 막내가 스쿨버스를 타고 돌아올 시간이 될 때까지 TechNet과 인터뷰를 가졌습니다. JOYCE THOMPSON: Kalen, 녹음을 시작하겠습니다. SQL Server의 최신 버전에서 새로운 점은 무엇인가요? 뛰어난 특징은 무엇입니까? KALEN DELANEY: 저를 놀라게 했던 가장 중요한 변화는 Sybase로부터의 이탈이었습니다. 지금까지는 Sybase와 상당히 밀접한 관계가 있었지만 Sybase 아키텍처의 일부 한계로 인해 확장성 측면에서 장애에 부딪혔던 것입니다. 7.0은 전혀 다릅니다. SQL 언어는 동일하지만 데이터 처리, 쿼리 처리를 위한 시스템 작동 방식은 새로운 것입니다. 내부의 모든 것이 변경되었습니다. 이 사실을 처음 알았을 때는 다소 겁이 나더군요. 이거, 처음부터 다시 시작해야 되겠구나, 남들보다 SQL Server를 먼저 시작한 이점이 사라지는구나 하는 생각이 들었습니다. 다행히 새 버전에 대한 연구를 일찍 시작할 수 있었고 여러 방면에서 수많은 지원과 도움을 받을 수 있어서 이 제품에 관해 가장 앞서 있다는 자신감을 회복할 수 있었습니다. 그랬더니 마음이 좀 편해지더군요. 제가 별로 중요하지 않다고 생각했던 사항에 대해서도 반응은 엄청났습니다. 예를 들어 저는 행 수준 잠금에 대해서는 항상 회의적이었는데 마케팅에서는 상당한 쟁점이었습니다.
JOYCE THOMPSON: 데이터베이스 분야에 익숙하지 않은 사람들을 위해서 그 잠금 문제에 관해 약간 설명해 주시지 않겠습니까? KALEN DELANEY: 6.5와 7.0의 가장 큰 차이점 중 하나는 작업하는 데이터의 크기에 관한 것입니다. 즉, 데이터 관련 작업을 진행하는 중에 얼마만큼의 데이터를 유보해야 하는가 하는 문제입니다. 이론적으로, 현재 작업 중인 단 1바이트에 대해서만 잠금을 설정해서 그 1바이트에는 아무도 접근하지 못하게 할 수 있습니다. 아니면 다른 극단적인 경우로 전체 데이터베이스를 잠궈서 아무도 접근 못하게 할 수 있습니다. 그러나 여기에는 그에 따른 대가가 있습니다. 전체 데이터베이스를 잠근다면 본인에게는 아무런 문제도 발생하지 않겠지만 동료와 함께 작업할 수 없습니다. 다른 반대의 경우로 작업하는 각 바이트를 잠궈 버린다면 모든 시스템 자원을 잡아 먹게 될 것입니다. Sybase SQL Server는 페이지 수준에서 잠겨지는데 이는 입력과 출력에 사용되는 고정된 크기의 데이터 블록입니다. 행의 크기와 실제 저장하는 데이터의 크기에 따라 이것이 보유하는 행의 개수도 다양합니다. 다른 대부분의 시스템들은 개별 행을 잠그는 방식이었으므로 쟁점은 항상 행 잠금이냐 페이지 잠금이냐 하는 것이었습니다. Sybase는 페이지를 잠그는 것이 오버헤드가 훨씬 적다고 보았습니다. 페이지를 잠그면 다른 일부 사용자들을 차단하더라도 오버헤드가 충분히 낮기 때문에 사용자가 들어 가서 작업을 하고 나온 후에 다른 사용자도 들어갈 수 있습니다. 비판자들은 "효율적인 시스템을 갖추려면 행 수준 잠금이어야 한다 "고 말할 것입니다. 그러나 효율적인 시스템은 충분히 있습니다. 월 스트리트의 수많은 회사들이 Sybase SQL Server를 사용해서 잘 운영해오고 있습니다. 이것이 페이지 수준 잠금임을 이해하고 적절한 시간을 할애해서 이것과의 작업을 설계한다면 극히 효율적인 시스템을 갖출 수 있을 것입니다. 이상적인 경우, 프로젝트 기간의 80%를 설계에 할애할 수 있다면 그 실제 구축은 상당히 간단한 작업이 될 것입니다. 그러나 많은 기업에게 이 같은 일은 불가능합니다. 따라서 페이지 수준 잠금의 원활한 수행에 필요한 설계 작업이 항상 가능한 것은 아닙니다. SQL Server 7.0에서는 행 수준 잠금을 추가했습니다. 행 수준에는 오버헤드가 많기 때문에 저는 회의적이었지만 엔진 작동 방식의 상당한 내적 변화는 SQL Server가 이를 극복하는 데 도움이 되었습니다. 행 수준 잠금 때문에 응용 프로그램의 여러 가지 속도 저하가 있을 것으로 예상했지만 시스템에 수많은 개선이 이루어졌기 때문에 그런 일은 전혀 발생하지 않았습니다.
JOYCE THOMPSON: 구체적으로 어떤 개선입니까? KALEN DELANEY: 우선 엔진이 쿼리를 처리하는 방식, 예를 들어, "지난 두 주 동안 이 제품을 구입한 Wisconsin 거주 고객" 등과 같은 쿼리에 대한 대응 방식에 개선이 있었습니다. SQL 서버가 이를 내부 작업 시퀀스로 변환하는 방식, 구하는 데이터가 어디에 있는지 찾아내는 방식 등과 관련된 모든 방식과 엔진의 고차원적인 수준에서 사용자의 요구를 충족하는 방식 등이 완전히 다시 작성되었습니다. 걱정했던 성능 저하는 전혀 나타나지 않았습니다. 반드시 인식해 두어야 할 중요한 사항은 인덱싱 구조가 완전히 변경되었다는 점입니다. 인덱스의 조직 방식, 그리고 어떤 종류의 인덱스를 얼마나 가져야 하는지 등에 관한 일반 규칙이 완전히 변경된 것입니다. 따라서 6.0에서 7.0으로 업그레이드한 후에도 응용 프로그램의 성능 향상이 없는 경우의 대부분은 인덱스를 재분석하지 않았기 때문입니다. SQL 6.5에 있던 인덱스를 그대로 두는 경우가 있는데 그리 바람직하지 않습니다. JOYCE THOMPSON: 그렇다면 제품을 올바로 사용했을 경우에는 실제로 속도 향상을 기대해도 좋다는 뜻입니까? KALEN DELANEY: 별다른 조치 없이 바로 성능이 향상될 것이지만, 만일 그렇지 않은 경우에는 제일 먼저 살펴 보아야 할 것이 인덱싱입니다. Microsoft는 인덱스 조정 마법사라는 새로운 도구를 준비해 놓고 있습니다. 인덱스 조정이라는 것이 복잡한 주제여서 SQL 6.5에서는 인덱싱과 최적의 인덱스 구성법을 가지고 한 클래스 전체를 강의해 왔기 때문에 저는 이것에 대해서도 회의적이었습니다. 그러나 이 마법사는 대단한 도구였습니다. 인덱스 조정 마법사는 SQL Server 프로필러라는 다른 도구의 일부인데 이 도구는 시스템의 작동 방식과 개선 방법에 대해 훌륭한 정보를 제공합니다. JOYCE THOMPSON: TechNet 사용자들이 본격적인 자세한 설명을 얼마나 선호하는지는 잘 알고 계시리라 믿습니다. 인덱싱 구조의 변화와 그 가장 효과적인 사용 방법에 관해 어떤 사항을 설명해 주실 수 있습니까? 새로운 인덱싱 구조가 어떤 방식으로 개선을 가져오는지 구체적으로 말씀해 주십시오. KALEN DELANEY: 좋습니다. 표에 클러스터된 인덱스가 하나 있습니다. 이 인덱스는 데이터의 물리적 순서를 강요하는 인덱스이며 성을 기준으로 구축되었습니다. 데이터는 실제로 성의 순서로 물리적으로 저장되는데, SQL 7.0에서는 이 클러스터된 인덱스를 구축하기 위해 선택한 열 또는 데이터가 가능한 한 작아야 합니다. 예를 들어 클러스터된 인덱스를 주소 중심으로 구축해서는 안되며 어떤 열을 선택하든 반드시 비휘발성이어야 합니다. 주식 가격이나 이와 유사한 것을 중심으로 구축해서는 안됩니다. 사회보장번호처럼 몇 바이트 이내이고(보통은 4바이트가 적당) 변하지 않는 것이어야 합니다. JOYCE THOMPSON: 보조 인덱스는 어떻게 됩니까? KALEN DELANEY: 저희는 보조 인덱스의 숫자를 제한할 것을 강력하게 권장해 왔습니다. SQL Server는 기술적으로 256개의 보조 인덱스를 사용할 수 있었습니다. 그러나 SQL 6.5에서 이 데이터를 수정해야 하는 경우라면, 행을 변경할 때마다 인덱스를 변경해야만 하기 때문에 매우 비효율적입니다. 따라서 자주 업데이트를 수행해야 하는 경우에는 클러스터되지 않은 인덱스를 최고 5개에서 6개 정도로 제한할 것을 권장했던 것입니다. 7.0에서는 이 같은 제한은 전혀 없습니다. 오히려 유용하다고 생각되는 모든 것에 인덱스를 설정하는 것이 좋습니다. 조정 마법사는 팩트 다음에 실행할 수 있으며, 사용 중인 것과 그렇지 않은 인덱스는 어떤 것인지 알려 줍니다. 실제 시스템 활동의 작업 부하를 캡처해서 조정 마법사를 통해 실행시키면 "사용하지 않는 인덱스"를 알려 줍니다. 그러면 그 인덱스를 제거하면 됩니다. JOYCE THOMPSON: 인덱스 조정 마법사가 그보다 더 큰 도구의 일부분이라고 말씀하셨습니다. SQL Server 프로필러는 당신이 좋아하는 기능 중에 하나입니까? KALEN DELANEY: 정확히 지적하셨습니다! 프로필러는 SQL Server의 외부 도구 가운데 하나이지만, SQL Server의 내부 상황을 볼 수 있는 확대경의 기능을 한다는 점에서 이 도구를 좋아합니다. JOYCE THOMPSON: SQL Server 설치를 지원하는 경우라면 매우 중요하겠군요? KALEN DELANEY: 절대적으로 중요한 도구입니다. JOYCE THOMPSON: 이 도구를 그렇게 좋아하는 이유는 무엇입니까?
KALEN DELANEY: 프로필러보다 먼저 사용되었던 도구는 SQL Trace입니다. 응용 프로그램이 계속 오류를 내는데 그 내부 원인을 알 수 없는 경우에 유용한 도구였습니다. 이 기존의 도구는 마치 문지기처럼, SQL Server로 들어 오는 모든 것을 감시하는 기능을 했습니다. 응용 프로그램이 사용자 수준에서는 단추를 눌러서 작동한다면, 내부에서는 응용 프로그램이 누르는 동작을 SQL 구문으로 변환해서 SQL Server에 보내는 것입니다. 즉, "사용자가 실행하고 있는 것은 조건이 존재하는 표에서 선택된 것임"을 SQL Trace 도구가 알려주는 것입니다. 이 같은 기능은 매우 유용한 것이지만 단점은 입구에서 그친다는 점입니다. 일단 SQL Server 안으로 들어 오면 내부에는 이 같은 방법이 없습니다. 아마 모든 응용 프로그램이 "이 저장 프로시저를 실행하십시오"라는 말밖에는 할 수 없을 것입니다. 이 저장 프로시저는 이미 SQL Server에 저장된 거대한 코드 덩어리일 수도 있습니다. 문지기가 할 수 있는 것이라고는 "이 같은 커다란 저장 프로시저를 실행했습니다"라는 말 밖에 없을 것입니다. 이 저장 프로시저가 천 개의 구문을 갖고 있고 50개의 다른 저장된 프로시저를 호출한다고 합시다. 이를 먼저 알 수 있는 방법은 없습니다. 프로필러는 저장 프로시저가 호출될 때마다, 그것이 응용 프로그램으로부터 호출된 것이든 다른 프로시저 내에서 호출된 것이든 이를 알려주고, 구문을 실행하는 데 필요한 시간이 얼마나 되는지, CPU 시간은 얼마나 되는지, 각 프로시저가 수행해야하는 물리적인 읽기/쓰기 횟수는 얼마나 되는지 모든 프로시저 내의 모든 구문에 관해 알려 줍니다. 실행에 두 시간이 걸리는 저장 프로시저가 있다면 이 저장 프로시저 내의 어디에 정체 요소가 있는지, 문제를 야기하는 원인은 무엇인지를 알려줍니다. 다양한 필터를 설정할 수 있어서 특정 워크스테이션이나 사용자, 또는 특정 응용 프로그램으로부터 SQL을 필터링할 수 있으며 개체의 액세스를 감시할 수 있습니다. 중요한 표로써 그 안의 값은 변화합니다. 일부 사용자는 이에 대한 특권을 필요로 하지만 일부 데이터는 변하지 않아야 하는데도 변경될 수 있습니다. 이를 어떻게 구별하겠습니까? 프로필러는 특정 표에 대한 액세스를 항상 기록합니다. 따라서 누가 그 같은 변경을 수행했는지 가려낼 수 있습니다. 시간과 컴퓨터, 그리고 CPU 사용 시간 등 모든 것을 캡처할 수 있으며, 동시에 그 구문과 연결된 사용자 이름 역시 캡처할 수 있습니다. 따라서 프로필러는 문제 해결 도구일 뿐만 아니라 편집 도구이기도 합니다. 처음 프로필러를 접하고 며칠 간 사용해 본 결과, SQL Server 프로필러만 가지고도 전문가가 될 수 있겠다는 생각을 했습니다. 그 정도로 풍부한 기능을 갖고 있었습니다. JOYCE THOMPSON: 프로필러의 활용법에 관해 교육한 바가 있습니까? 사람들이 이를 직관적으로 파악해 내던가요? KALEN DELANEY: 나름입니다. 더 많이 사용해 본 사람일수록 찾고자 하는 것이 무엇인지 빨리 파악해 낼 수 있습니다. 문제가 어디에 잠재해 있는지 알고 있다면 프로필러가 이 문제를 격리해 내는 방식만 파악하면 됩니다. 이건 그 자체로 거의 예술입니다. 몇 달 정도 시간을 들여서 프로필러의 최적 활용법에 관한 지침과 연구를 수행한다면 상당히 훌륭한 결과를 볼 수 있을 것입니다. 그러나 이 같은 일이 누구에게나 쉽지는 않을 것이라고 봅니다. 어떤 사람들은 저 같은 사람을 고용해야 할 것입니다. JOYCE THOMPSON: 수많은 기술 인력들에게는 데이터베이스 생성과 관리, 정신적 또는 조직적 작업과 관련된 어떤 특성 같은 것이 있습니까? KALEN DELANEY: 데이터베이스 시스템, 특히 SQL Server는 기술 인력의 그 두 진영 사이를 가로지르고 있기 때문에 약간 빗나간 답변을 드려야겠습니다. 사실, Microsoft의 자격증 프로그램에는 System Engineer 자격증과 Solution Developer가 있습니다. 솔루션 개발자는 프로그래머에 가깝습니다. SQL Server를 익힌 사람은 양쪽 어느 곳이든 선택할 수 있습니다. 프로그래머로서 또는 응용 프로그램을 프로그래밍한다는 방향에서 SQL Server에 접근할 수 있습니다. SQL은 프로그래밍 언어이며 저장 프로시저를 작성하는 것은 프로그램 가능한 모듈을 작성하는 것과 같습니다. 따라서 프로그래밍에 관심을 가진 수많은 사람들이 이 같은 측면에 끌리는 것입니다. 한편 데이터베이스 관리 시스템은 그 역시 하나의 시스템이며 운영 체제와 데이터베이스 시스템 사이에는 유사점이 많습니다. 수많은 시스템 엔지니어들, 그리고 운영 체제에 적성이 맞는 사람들이 SQL 서버에 관심을 갖게 되는 것은 이것이 전체 운영 체제의 세계를 축소해 놓은 것과 유사하기 때문입니다. 운영 체제에서와 마찬가지로 백업, 자원 액세스 등에 신경 쓰게 되고, 해당 파일에 대한 액세스 권한, SQL Server에 파일을 생성할 수 있는 권한, 표 생성 권한, 표의 데이터 읽기 권한, 복원, 허용, 공간 관리 등에 대해 알아야 하는데 이 모든 것들은 데이터베이스 인력들도 알고 있어야 하는 것들입니다. 따라서 시스템과, 시스템 관리자로서 얻게 되는 제어권 등에 관심 있는 사람들이 약간 작은 규모에서 SQL Server에 관심을 기울이게 되는 것입니다. JOYCE THOMPSON: Kalen, 이번에는 트랜잭션 로그 축소에 관해 질문하겠습니다. 이 기능을 효과적으로 사용하는 방법에 관해 일부 혼란이 있는 것으로 알고 있는데요? KALEN DELANEY: 오, 다시 기술적인 분야로군요. JOYCE THOMPSON: 예, 전문 분야 아니십니까!
KALEN DELANEY: 전에 언급했듯이 많은 사람들이 그 문제에 혼란을 느끼고 있기 때문에 상당한 관심을 갖고 있습니다. 마케팅 쪽에서는 SQL 7.0이 트랜잭션 로그를 축소할 것이라고 말합니다. 트랜잭션 로그는 데이터베이스에 가한 모든 변경 사항을 SQL Server가 저장하는 파일을 말합니다. 삽입 작업을 할 때마다, 업데이트를 할 때마다 SQL Server가 이를 기록하는데 이 기록은 몇 가지 용도에 이용될 수 있습니다. 이는 SQL Server 작업 경험이 없는 분들의 이해를 돕기 위한 배경 설명입니다. SQL Server 작업 경험이 있는 분들은 이 로그의 용도가 무엇인지 이미 알고 있습니다. 이 로그에는 모든 트랜잭션이 기록되어 몇 가지 용도에 이용될 수 있습니다. 트랜잭션 중일 때 이를 항상 기록합니다. 만일 천 개의 행을 업데이트하고 있는 중인데 이를 모두 업데이트하거나 아니면 전혀 건드리지 않아야 하는 상황이라면 업데이트하는 모든 것을 기록해서 만일 작업 중 시스템 장애가 발생하면 수행한 모든 작업을 취소하고 원래 상태로 돌아가야 합니다. 따라서 트랜잭션이 진행 중인 한에는 이 트랜잭션이 수행한 작업을 기록해야 합니다. 그러나 트랜잭션이 완료된 후에도 이 트랜잭션 로그는 백업에 사용될 수 있습니다. 로그만 백업해 둘 수 있으므로 드라이브나 시스템에 문제가 생겨서 복구 또는 복원해야 하는 경우에는 데이터 전체를 복구하는 것이 아니라 로그만 백업하면 되기 때문에 훨씬 효율적입니다. 전체 데이터베이스를 복원한 후 로그에 기록된 모든 변경 사항을 다시 수행해서 트랜잭션 로그를 마지막으로 수행한 지점으로 데이터베이스를 되돌릴 수 있는 것입니다. 로그의 크기는 계속 증가할 수 있습니다. 트랜잭션이 계속 추가될수록 그 크기는 기본적으로는 계속 증가할 것입니다. 이 로그를 따로 백업해둔다면 필요한 모든 정보를 다른 곳에 백업해 둔 것이므로, SQL Server는 이미 로그가 기록된 장소에 새로 로그를 쓸 수 있습니다. 따라서 정기적으로 백업을 실시한다면 로그의 크기는 그리 크게 증가하지 않을 것입니다. 많은 사람들이 혼동을 느끼는 것은 두 가지 다른 요소가 존재하기 때문입니다. 한쪽에는 논리적 구조인 로그가 존재하고 다른 쪽에는 이 논리적 구조를 담고 있는 실제 파일이 존재합니다. 방금 제가 언급한 것과 같은 경우에 트랜잭션을 기록하는 것이라면 이 로그를 백업한 후에는 실제로 덮어 쓰기를 수행할 수 있습니다. 이것은 실제 파일의 첫 부분으로 돌아가서 다시 쓰기를 시작한다는 점에서 쳇바퀴와 같습니다. 물리적 파일에서 쓰기를 수행하는 위치는 반드시 순차적이지 않을 수도 있습니다. 따라서 사용 중인 공간과 축소 가능한 공간의 크기를 살펴 볼 때는 어떤 "용도"인가를 반드시 염두에 두어야 합니다. 로그가 사용될 수 있는 이 같은 방식들을 구분할 수 있는 도구는 그리 많지 않습니다. 실제로 이 로그가 사용되는 것일 수도 있고 사용되지 않지만 아직 백업되지 않았기 때문에 덮어 쓸 수 없을 수도 있습니다. 사용될 수 있지만 이미 백업 되었기 때문에 재사용될 수 있거나, 로그의 크기가 매우 크다면 실제 파일 속에는 아직 건드리지도 않은 공간이 있을 수도 있습니다. JOYCE THOMPSON: 정말 여러 가능성이 있겠습니다. KALEN DELANEY: 물리적 파일을 축소시키려면 여러 사항을 종합해야 합니다. 로그 내부에 더 이상 필요하지 않는 공간을 갖고 있어야 합니다. 따라서 이 공간을 백업해 두었어야만 이를 사용할 수 있습니다. 그러나 다른 한편으로 우리는 실제 구조를 다루고 있습니다. 실제 하드 드라이브에 있는 파일은 물리적인 시작과 끝을 갖고 있는 실제 물리적 구조입니다. 만일 100MB 정도의 로그 기록을 작성했는데 이중 실제로 필요한 것은 마지막 2MB뿐이고 백업을 해 놓았다면 앞의 98MB는 더 이상 필요하지 않습니다. 그런데 마지막의 2MB 때문에 축소 작업을 하지 못하는 경우가 있을 수 있습니다. 마지막 부분부터 축소 작업을 수행해야 하는데 이 부분에서 현재 트랜잭션이 이루어지고 있기 때문에 축소 작업을 수행할 수 없습니다. 이미 백업해 놓아서 더 이상 필요 없는 부분이 98MB나 되는데도 이를 백업할 수 없는 것입니다. 현재 활성 상태인 부분이 끝 쪽에 있다면 절대 축소할 수 없습니다. 따라서 약간의 작업이 필요합니다. SQL Server에게 트랜잭션을 약간 더 기록하도록 하는 것입니다. 그렇게 되면 SQL Server는 새로운 쓰기 작업을 이미 백업해 둔 앞 부분으로 되돌아가서 수행할 수 있으므로 마지막 부분은 비활성 상태가 될 수 있습니다. 이때는 물리적인 축소 작업을 수행할 수 있습니다. 문제는 세세한 작업이 많이 필요하기 때문이 아니라 로그에서 물리적으로 활성 상태인 부분을 가려낼 수 있는 도구를 Microsoft가 제공하지 않았기 때문입니다. JOYCE THOMPSON: 공간 문제 외에 시간적인 요소도 있습니까? KALEN DELANEY: 있습니다. 이것은 문서이지만 크고 굵은 문자로 되어있지는 않습니다. 실제 축소 과정은 백업을 수행할 때 이루어집니다. 따라서 축소 명령을 내리면 SQL Server는 "백업이나 잘라내기를 수행하지 않으면 물리적 축소 작업을 수행할 수 없다"는 반응을 나타냅니다. 이미 저장한 경우에는 잘라내기도 백업과 같은 효과를 갖습니다. 바로 이런 경우에만, 즉 로그를 백업하거나 잘라 내기한 경우에만 물리적 축소 작업이 수행됩니다. JOYCE THOMPSON: 엄밀하게 말해서 데이터 변환 도구(Data Transformation Tool)는 SQL Server 내부에 있지는 않지만 TechNet 독자들은 상당한 관심을 갖고 있습니다. 여기에 관해 설명해 주실 내용은?
KALEN DELANEY: DTS는 SQL Server와 함께 사용할 수 있는 새로운 도구이지만 SQL Server의 일부는 아닙니다. 이 도구는 SQL Server와 함께 자동으로 설치되어 있는데, 사용자는 이 도구를 설치할 것인지 말 것인지 선택할 수 없습니다. 부분적으로 이 도구는 어디에서든 데이터를 가져와서 이를 다른 어떤 종류의 시스템으로도 변환시킬 수 있는 일종의 데이터 펌프입니다. 텍스트 파일을 SQL Server 표로 변환하거나 그 반대로 할 수 있지만 SQL Server를 직접 사용할 필요는 없습니다. ORACLE 데이터를 DB2 데이터로 변환할 수 있으며 Access를 Paradox로 변환할 수 있습니다. SQL Server를 전혀 개입시키지 않고도 DTS, 즉 데이터 변환 서비스를 이용해서 시스템을 자유로이 오갈 수 있습니다. 따라서 이 강력한 데이터 전송 도구 때문에 SQL Server를 구입할 가능성도 있습니다. 그러나 이 도구는 단지 데이터를 A에서 B로 옮기는 작업 외에도 매우 다양한 작업을 수행할 수 있습니다. 말 그대로 데이터를 변환할 수 있으며, 필요한 경우에는 이를 다른 것으로 변환하거나 무시하거나, 복사조차 하지 않게 프로그래밍할 수 있습니다. 따라서 기본적으로 데이터를 청소하거나, 다른 형식으로 변환하거나, 아무 변환 없이 전송할 수도 있습니다. 전체 패키지를 여러 단계로 작성할 수 있습니다. 패키지를 만들고 패키지의 각 아이콘에서 수행할 작업을 만들 수 있습니다. 표를 만들기, 데이터 가져오기, 이를 어느 곳으로 전송하기, 스크립트 실행하기, 그리고 작업이 성공할 경우 할 일, 실패할 경우 할 일 등 조건 구문도 지정할 수 있습니다. 사람들은 DTS에 관한, Inside SQL Server 와 같은 책을 원하고 있습니다. DTS의 작동 방식과 최적 활용법 등을 알고 싶어 하는 것입니다. 제가 말씀 드린 사항 중 일부는 새롭지만 그리 강력하거나 유용하지 않을 수 있습니다. 그러나 DTS는 다릅니다. DTS는 새롭고 강력하고 흥미진진한 도구입니다. 더 개선될 수 있는 여지도 있지만 현재 그 최초의 모습만으로도 충분히 강력하고 흥미진진한 도구입니다. JOYCE THOMPSON: 함께 얘기를 나눌 수 있어서 기쁘게 생각합니다. 마지막으로 데이터 웨어하우징에 관해서 하실 말씀은 없습니까? KALEN DELANEY: 물론 있지만 그것만으로도 별개의 대담 주제가 될 것입니다. Joyce Thompson은 작가이자 인터뷰 진행자이며 TechNet에 자주 기고하고 있습니다. Kalen Delaney는 Inside Microsft SQL Server 7.0.을 비롯한 몇 권의 책을 저술한 작가입니다. Kalen의 연락처는 http://www.insideSQLserver.com입니다. | ||||||||||||||||||||||||||||||
잠금 기능