Microsoft MVP성태의 닷넷 이야기
개발 환경 구성: 146. SQL Server 2012 에 포함된 LocalDB 기능 소개 [링크 복사], [링크+제목 복사]
조회: 18129
글쓴 사람
홈페이지
첨부 파일

SQL Server 2012 에 포함된 LocalDB 기능 소개


마이크로소프트웨어 잡지 1월호에 실렸던 내용입니다.

SQL 서버 2012에 포함된 LocalDB 기능
; http://www.imaso.co.kr/?doc=bbs/gnuboard_pdf.php&bo_table=article&page=1&wr_id=39261&publishdate=20120101

편집을 거쳐서 실렸기 때문에, 제가 쓰는 평소의 글과는 다소 다른 (마이크로소프트웨어 측 편집자의) 문체 입니다. 기고한 워드 문서를 아래에 그대로 실었기 때문에 읽기가 자연스럽지 않을 수 있는데요. 이를 위해 워드 원문 파일을 첨부했으니 참고하십시오. ^^




최근 들어 응용 프로그램들이 경량화 되면서 가볍게 사용할 수 있는 DB 들이 주목 받게 되었다. 이에 대한 트렌드의 반영일까? 마침 지난 11월 중순에 공개된 (코드명 Denali로 알려진) SQL Server 2012 RC 버전에도 기존 버전에서 볼 수 없었던 LocalDB 라는 기능이 포함되어 있다. 과연, 새롭게 추가된 LocalDB가 어떤 용도로 사용될 수 있는지 이번 글을 통해서 가늠해 보자.


정성태 kevin@jennifersoft.com
현재 (주) 제니퍼소프트에서 ‘제니퍼’ 성능 관리 솔루션에 대한 ‘닷넷’ 버전 개발을 담당하고 있으며, 개인적으로 https://www.sysnet.pe.kr 사이트를 통해 ‘닷넷 프레임워크’ 관련한 지식들을 공유하고 있다.




마이크로소프트의 .NET Framework 개발자들에게는 데이터베이스 선택에 있어 SQL 서버가 자연스러울 수 밖에 없다. 닷넷 BCL(Base Class Library)에는 SQL 서버에 접속하는 기능을 가진 System.Data.SqlClient 제공자를 기본적으로 포함하고 있는 데다, 대부분의 닷넷 개발자들이 사용하는 Visual Studio 에서도 SQL 서버와의 연동 기능을 풍부하게 제공하고 있고, 무엇보다도 SQL 서버의 관리가 여타 데이터베이스보다도 쉽기 때문에 힘들게 다른 데이터베이스를 고려할 필요가 없는 것이다. 이런 상황에서, 데이터베이스가 필요한 응용 프로그램을 개발하려는 경우 우선 순위로 SQL 서버 제품 군에서 적절한 버전을 고르게 되는데, 현재 선택 가능한 유형으로는 크게 다음과 같이 3가지가 있다.

  • SQL 서버 Standard Edition 이상
  • SQL 서버 Express
  • SQL 서버 Compact Edition

일단, 무료 데이터베이스를 생각한다면 Express 버전과 Compact Edition을 선택할 수 있는데, Express 버전의 경우에는 설치와 함께 일련의 부가적인 설정 작업이 필요하므로 간단한 데이터베이스를 원하는 경우라면 “Compact Edition”을 고려하게 된다. 하지만, 아쉽게도 “Compact Edition”은 다른 SQL 서버 제품 군과 100% 호환이 되지 않는다는 단점이 있다. 일례로, 테이블 내의 컬럼에 사용되는 타입도 제한적이며 다중 SQL 구문 실행도 지원하지 않는 데다 파일 형식도 다르고, 결정적으로 소스 코드레벨에서도 차이점을 보이기 때문에 다른 버전의 SQL 서버를 사용하는 응용 프로그램을 “Compact Edition”용으로 마이그레이션 하려면 적지 않은 작업이 요구된다. [표 1]에서는 3가지 SQL 서버 버전의 차이점을 응용 프로그램의 용도에 따라 선택할 때 대표적으로 따져봐야 할 기준들을 분류해 놓고 있다.

[표 1: SQL 서버 Edition 별 비교]
SQL 서버 Standard Edition 이상SQL 서버 ExpressSQL 서버 Compact Edition
DB 파일 크기 제한16 TB10 GB4 GB
파일 포맷MDFMDFSDF
네임스페이스System.Data.SqlClientSystem.Data.SqlClientSystem.Data.SqlServerCe
사전 설치필요필요없음
가격정책유료무료무료

혹시, 무료이면서 설정도 복잡하지 않고 마이그레이션 관점에서 아무런 문제가 없는 SQL 서버 Express 급의 기능을 갖는 버전이 있다면 좋지 않을까? 바로 이런 요구 사항이 반영되어 SQL 서버 2012에 새롭게 제공되는 기능이 “LocalDB”라고 보면 된다.


SQL 서버 2012 - LocalDB

SQL 서버 2012에 포함된 LocalDB의 특징들을 간단하게 살펴보면 다음과 같다.

- SQL 서버 Express 와 100% 호환
- 동일한 System.Data.SqlClient 제공자를 이용하여 데이터베이스에 연결
- AttachDbFileName 속성을 이용하여 파일 경로를 이용한 데이터베이스 접근 허용
- SQL 서버 Express 보다 더 간단한 설치 방식 지원
- In-process DLL 방식이 아닌, 별도의 sqlservr.exe 에서 실행

SQL 서버 Express 버전과 100% 호환되기 때문에 기존 데이터베이스 파일 포맷인 MDF/LDF 파일을 그대로 사용할 수 있다는 장점을 기반으로, ‘연결 문자열’을 제외한 기존 코드를 모두 그대로 마이그레이션 할 수 있어 응용 프로그램의 목적에 맞게 그때 그때 SQL 서버를 임의로 교환할 수 있는 환경이 비로소 갖춰지게 되었다.

뒤에서 좀더 살펴보면서 알게 되겠지만, LocalDB는 새로운 종류의 SQL 서버 Edition으로 분류되어도 좋을 정도로 그 위치를 잘 잡고 있다. 즉, 기존 SQL 서버 Express와 “Compact Edition”의 제품들을 대체하는 용도는 아니다. Express 버전의 경우, 사용자가 제품 키만 입력하면 언제든지 유료 SQL 서버 제품 군으로 쉽게 업그레이드하는 것이 가능하고 “Compact Edition”은 여전히 “모바일 환경”에서 설치될 수 있는 유일한 제품이기 때문이다.


LocalDB 설치

현재 RC 버전이 공식적으로 릴리즈 되어 다음의 경로에서 다운로드가 가능하다.

Microsoft® SQL Server® 2012 Express RC0
; http://www.microsoft.com/download/en/details.aspx?id=28151

위의 링크에서 “SqlLocalDB.msi” 파일명으로 x86/x64 버전이 각각 33MB, 28MB 정도의 크기로 제공이 되는데 설치 작업을 완료하면 약 150MB 의 디스크 공간이 점유된다. 설치 과정 중에는 어떠한 사용자 입력도 없으며, 설치 후에도 LocalDB를 사용하기 위한 별도의 설정 작업이 필요하지 않다. 또한, SQL Express와 달리 어떠한 NT 서비스 등록도 안되어 있으며 sqlservr.exe 프로세스도 기본적으로는 실행되어 있지 않다.

그렇다면, 닷넷 클라이언트 측 프로그램은 어떻게 LocalDB에 접근할 수 있을까? 이에 대한 답은 System.Data.SqlClient 제공자에서 가지고 있다. SqlConnection.ConnectionString 속성에 지정된 연결 문자열 속에 LocalDB용임을 알리는 설정이 포함되어 있으면 자동적으로 sqlservr.exe 프로세스를 실행하고 데이터베이스에 연결을 해준다. 여기서 다시 궁금한 점이 하나 생기는데, 그럼 어떻게 기존의 .NET Framework에 포함된 System.Data.SqlClient 제공자가 무슨 근거로 LocalDB임을 적절하게 판단할 수 있는가 하는 점이다. 당연히, 기존의 System.Data 어셈블리에 포함된 코드들은 LocalDB의 존재에 대한 고려가 전혀 안되어 있어서 알 수 없다. 그러므로, 이런 문제점을 해결하기 위해 마이크로소프트는 .NET Framework 4.0에 한해서 새롭게 4.0.2 업데이트 설치 파일을 제공하고 있다. (참고로, 4.0.2 업데이트에는 ClickOnce 및 WPF에서 보고된 일부 문제를 해결하는 패치를 포함하고 있다.)

Update 4.0.2 for Microsoft .NET Framework 4 ? Runtime Update (KB2544514)
; http://www.microsoft.com/download/en/details.aspx?id=27756

위의 링크에 포함된 설치 파일을 실행하면 LocalDB 연결 문자열을 인식하는 System.Data 어셈블리가 설치되며 닷넷 개발자는 기존의 방식대로 SqlConnection/SqlCommand 등의 타입을 이용해서 LocalDB를 사용하는 것이 가능하다.


System.Data.SqlClient를 이용한 프로그래밍

설치작업까지 정상적으로 완료했다면, 어떠한 외부적인 어셈블리 참조과정 없이 기존에 알고 있던 System.Data.SqlClient 제공자를 그대로 사용하여 LocalDB에 접속하는 것이 가능하다. 단지 달라지는 것이 있다면 ‘연결 문자열’인데, 다음과 같이 “Data Source” 속성에 “(localdb)\v11.0”이라는 값을 지정해주면 된다.

Data Source=(localdb)\v11.0; Integrated Security=true; 

아래는, 위의 연결 문자열을 사용해서 새로운 데이터베이스를 만드는 예제 코드를 보여준다.

void CreateTestDatabase(string databaseName)
{
    using (SqlConnection connection = new SqlConnection())
    {
        connection.ConnectionString =
            @"Data Source=(localdb)\v11.0; Integrated Security=true;";
        connection.Open();
 
        string checkExitsDB = "select count(*) from sys.databases where name = @dbname";
        SqlCommand command = new SqlCommand();
        command.Connection = connection;
        command.CommandText = checkExitsDB;
        SqlParameter dbNameParameter = command.CreateParameter();
        dbNameParameter.ParameterName = "@dbname";
        dbNameParameter.DbType = System.Data.DbType.String;
        dbNameParameter.Value = databaseName;
        command.Parameters.Add(dbNameParameter);
 
        int count = Convert.ToInt32(command.ExecuteScalar());
        if (count == 0)
        {
            command.CommandText = "Create database " + databaseName;
            command.ExecuteNonQuery();
        }
 
        connection.Close();
    }
}

그렇다면 이렇게 생성된 데이터베이스는 어디에 위치하고 있을까? 위의 코드가 정상적으로 실행이 되었다면 기본적으로 %USERPROFILE% (예: c:\users\[계정명]) 폴더에 Test.mdf, Test_log.ldf 파일이 생성된다. 물론, 다음과 같이 생성될 데이터베이스 파일의 경로를 직접 지정하는 것도 가능하다는 사실을 알아두자.

command.CommandText = @"Create database test on (name='test', filename='c:\temp\test.mdf')";

이와 같이 “Create Database…”로 생성된 데이터베이스를 지정하는 연결문자열은 기존처럼 “Database” 속성으로 추가해 주면 된다.

Data Source=(localdb)\v11.0; Integrated Security=true; Database=test; 

.NET Framework 4.0.2 업데이트에서 설치된 System.Data.SqlClient 제공자는 “(localdb)\v11.0” 텍스트가 포함된 연결 문자열을 가진 SqlConnection 개체가 Open 메서드를 실행하면 자동적으로 sqlservr.exe 프로세스를 현재 프로세스의 자식으로 생성하고 연결을 시도한다. 아울러 sqlservr.exe 프로세스의 종료는 데이터베이스로의 마지막 접속이 끝난 이후 수 분 내에 자동으로 내려가도록 되어 있다.


사용자 단위로 분리된 데이터베이스 환경

“Create Database …”명령어를 사용하는 경우 해당 데이터베이스 파일은 %USERPROFILE% 폴더에 생성되지만, 그에 대한 기록이 master.mdf 파일에 함께 저장되어 sys.databases 뷰를 이용하여 조회할 수 있다. LocalDB 에서 생성한 데이터베이스 파일이 ‘사용자 단위’로 관리되기 때문에 master.mdf 파일 역시 ‘사용자 단위’로 분리되어야 한다. 만약, 컴퓨터 단위로 master.mdf 파일이 하나만 존재한다면, “A 계정”에서 생성한 데이터베이스 파일이 “B 계정”으로 로그인 한 환경에서 sys.databases 뷰를 통해서 보일 것이고 “A 계정”의 %USERPROFILE% 폴더에 접근하려고 하는 시도가 있을 수 있다.

이러한 부작용을 방지하기 위해 LocalDB 에서는 설치 폴더에 있는 master.mdf 와 같은 시스템데이터베이스 파일들을 %USERPROFILE% 폴더 하위의 지정된 경로에 복제하는 방법을 사용한다. 다음은 원본과 복제된 파일이 위치하는 경로이다.

원본 폴더: %PROGRAMFILES%\Microsoft SQL Server\110\LocalDB\Binn\Templates
복제 폴더: %LOCALAPPDATA%\Microsoft\Microsoft SQL Server Local DB\Instances\v11.0

복제된 폴더에 보면 master.mdf 이외에도 model.mdf, msdbdata.mdf, tempdb.mdf 파일을 볼 수 있는데 모두 SQL 서버 Express 이상의 제품에서 사용되는 것들이다. 이들을 모두 LocalDB를 활성화 시키는 사용자에게 제공함으로써 결국 각각의 사용자마다 투명하게 “단일한 SQL 서버 Express 환경”이 구현되는 효과를 누리게 되는 셈이 된다.

실제로, sqlservr.exe 프로세스가 SqlClient 제공자에 의해서 자동으로 실행되어질 때 그 명령행 인자를 살펴보면 다음과 같이 복제된 폴더의 master.mdf 파일 경로가 넘어가는 것을 볼 수 있다.

"C:\Program Files\Microsoft SQL Server\110\LocalDB\Binn\\sqlservr.exe"   
-c 
-SMSSQL11E.LOCALDB 
-sLOCALDB#9E9A6FCF 
-d"C:\Users\...[사용자 계정]…\Application Data\Local\Microsoft\Microsoft SQL Server Local DB\Instances\v11.0\master.mdf" 
-l"C:\Users\...[사용자 계정]…\Application Data\Local\Microsoft\Microsoft SQL Server Local DB\Instances\v11.0\mastlog.ldf" 
-e"C:\Users\...[사용자 계정]…\Application Data\Local\Microsoft\Microsoft SQL Server Local DB\Instances\v11.0\error.log"

참고로 IIS 및 NT 서비스로 동작하는 프로세스의 경우, 서비스 전용 계정(Local System, Network Service, Local Service)로 활성화 된 sqlservr.exe 프로세스는 별도로 운영체제에 의해 정의된 시스템 계정을 위한 프로파일 폴더에 시스템 데이터베이스 파일들을 저장시킨다.

SYSTEM 계정: %SYSTEMROOT%\system32\config\systemprofile\AppData\Local\Microsoft\Microsoft SQL Server Local DB\Instances\v11.0
Network Service 계정: %WinDir%\ServiceProfiles\NetworkService\AppData\Local\Microsoft\Microsoft SQL Server Local DB\Instances\v11.0
Local Service 계정: %WinDir%\ServiceProfiles\LocalService\AppData\Local\Microsoft\Microsoft SQL Server Local DB\Instances\v11.0


AttachDbFileName 속성을 이용한 데이터베이스 파일 경로 지정

다음과 같은 연결 문자열이 주어졌을 때,

Data Source=(localdb)\v11.0; Integrated Security=true;Database=Test

SqlConnection 개체는 Test라는 데이터베이스에 접속하려고 시도할 것이고, 이 데이터베이스에 대한 정보를 master.mdf 로부터 조회해서 찾아낼 것이다. 즉, “Database=…” 속성을 지정해서 사용하려는 데이터베이스는 반드시 사전에 master.mdf 에 등록된 경우에 가능한 것이어서 사전 등록 과정이 필요하다는 불편함이 있다.

등록으로 인한 불편함은 여기서 끝나지 않는다. 가령, %USERPROFILE%에 생성된 데이터베이스 파일(mdf, ldf)을 사용자가 임의로 삭제한다면 어떻게 될까? 응용 프로그램 측에서 데이터베이스가 이미 등록되어 있는지 확인하려고 "select count(*) from sys.databases where name = …[DB명]…" 쿼리를 실행하면 반환 값으로 여전히 1 이라는 결과를 얻게 된다. 왜냐하면, 파일만 삭제되었을 뿐 master.mdf 파일에는 여전히 등록되어 있기 때문이다. 이렇게 직접적인 파일 삭제와 관련해서는 사실 기존 SQL 서버 Express 이상의 버전에서는 크게 문제가 되지 않았던 부분이다. 왜냐하면 항상 NT 서비스로 실행되어 있는 sqlservr.exe가 등록된 데이터베이스 파일을 기본적으로 잠그고 있기 때문인데, 그러한 장치가 마련되어 있지 않은 LocalDB에서는 태생적으로 실제 파일과 master.mdf 내용과의 불일치 문제가 발생할 확률이 높아졌다는 부담이 발생한다.

이와 같은 불편함 없이, 가볍게 데이터베이스 파일 경로만 지정해서 사용할 수 있는 방법은 없을까? 바로 이런 목적으로 제공되는 속성이 AttachDbFileName 이다. 이전 SQL 서버 2008 Express 버전에서도 제공된 기능이긴 하지만 2012 버전에 와서는 LocalDB에서도 사용할 수 있도록 확장되었다 . 대표적으로, 이 속성을 사용하는 경우가 프로젝트에 MDF 파일을 포함해서 배포하는 것을 들 수 있다. 예를 들면, [그림 1] 의 프로젝트는 MDF 파일을 포함하고 있는데, 빌드를 완료하고 나면 EXE 결과물이 생성된 폴더에 Northwnd.mdf 파일이 함께 배포가 된다.

[그림 1 - MDF 데이터베이스 파일을 포함하고 있는 프로젝트]
local_db_1.png

응용 프로그램에서 이런 식으로 master.mdf 파일에 등록하지 않은 임의의 데이터베이스 파일을 연결해서 사용하려면 다음과 같이 연결 문자열을 지정할 수 있다.

Data Source=(localdb)\v11.0; Integrated Security=true;AttachDbFileName=…[MDF파일 경로]…

아래는 이와 관련된 간단한 예제 코드를 보여준다.

string mdfPath = Path.Combine(Environment.CurrentDirectory, "NORTHWND.MDF");

using (SqlConnection connection = new SqlConnection())
{
    connection.ConnectionString =
        @"Data Source=(localdb)\v11.0; Integrated Security=true;AttachDbFileName=" + mdfPath;
    connection.Open();
    …[생략]…
    connection.Close();
}

웹 사이트 프로젝트의 경우에는 [그림 2] 처럼 보통 MDF 파일을 “App_Data” 폴더에 포함시키고,

[그림 2 - App_Data 폴더에 추가된 데이터베이스 파일]
local_db_2.png

연결 문자열은 다음과 같이 “|DataDirectory|”를 사용하여 지정할 수 있다.

protected void Page_Load(object sender, EventArgs e)
{
    string mdfPath = @"|DataDirectory|NORTHWND.MDF";
    using (SqlConnection connection = new SqlConnection())
    {
        connection.ConnectionString =
            @"Data Source=(localdb)\v11.0; Integrated Security=true;AttachDbFileName=" + mdfPath;
        connection.Open();
 
        connection.Close();
    }
}

이하, 모든 사용법은 기존 SQL 서버를 대상으로 하는 방식과 다르지 않으므로 생략한다.


SSMS(SQL Server Management Studio) 를 이용한 관리

“Microsoft® SQL Server® 2012 Express RC0” 다운로드 페이지 - http://www.microsoft.com/download/en/details.aspx?id=28151 에 접속하면 약 600MB 용량의 SQLManagementStudio_x64_ENU.exe 파일을 다운로드 받을 수 있는데 이를 컴퓨터에 설치하면 “시작” / “Microsoft SQL Server 2012 RC0” / “SQL Server Management Studio” 메뉴를 이용하여 SSMS 도구를 실행할 수 있고, 이를 이용해서 LocalDB에 등록된 데이터베이스를 관리할 수 있다.

유의할 점이라면, [그림 3]에서 보는 것처럼 “Server name” 란에 “(localdb)\v11.0” 값을 주어야 한다.

[그림 3 - SSMS 에서 LocalDB 연결]
local_db_3.png

정상적으로 연결 되어 [그림 4]와 같은 화면이 나오면, 현재 로그인 한 사용자 계정과 연관된 LocalDB 설정을 할 수 있다. 만약 다른 사용자 계정과 연결된 데이터베이스를 관리하고 싶다면 SSMS 프로그램 아이콘을 “SHIFT” 키를 누른 상태에서 마우스 오른쪽 버튼을 눌러 “다른 사용자로 실행(Run as different user)”을 선택하는 등의 방식을 통해 구동해 주어야 한다. 그 외 모든 관리 방법은 기존의 SQL 서버 제품 군과 동일하기 때문에 역시 생략한다.

[그림 4 - SSMS 에서 LocalDB 관리]
local_db_4.png


User Instance 와 LocalDB의 비교

Visual Studio 에서 ASP.NET 웹 사이트 개발을 해본 경험이 있다면 아마도 SQL 서버 2008 Express 버전에서 지원되던 “User Instance” 기능에 대해 알고 있을 것이다. (혹시 모른다면, “SQL Express 버전과 User Instance 옵션 - https://www.sysnet.pe.kr/2/0/668” 글을 참고하자.)

내부적으로 LocalDB의 동작 방식은 “User Instance”의 그것과 많이 흡사하다. (master.mdf 파일을 포함한) 시스템 데이터베이스 파일의 사용자 단위 복제, 연결 문자열에 사용되던 AttachDBFileName 속성, “|DataDirectory|” 경로 지정 방식 및 사용자 단위로 생성되는 sqlservr.exe 프로세스 운영이 모두 동일하다. 그럼에도 불구하고 ‘하위 호환성’을 위해서인지 SQL 서버 2012 버전에서도 여전히 “User Instance” 속성은 유효하게 제공되고 있다.

단지, SQL 서버 2012 Express 버전으로 데이터베이스를 업그레이드 한 경우 인스턴스 명이 바뀌었다면 연결 문자열에 “Data Source=…” 부분만 그에 맞게 변경해 주면 된다.

Data Source=…[SQL 서버 2012 인스턴스]…;AttachDBFileName=|DataDirectory|NORTHWND.MDF;Integrated Security=true;User Instance=true

물론, 기존의 “User Instance”로 사용되던 데이터베이스를 LocalDB로 마이그레이션 하는 것도 가능하다. 바뀌어야 할 부분은 “User Instance”속성을 제거하고 “Data Source=(localdb)\v11.0” 값만 변경해 주면 정상적으로 동작한다.

Data Source=(localdb)\v11.0;AttachDBFileName=|DataDirectory|NORTHWND.MDF;Integrated Security=true

“User Instance” 옵션으로 연결하던 데이터베이스를 LocalDB로 바꿀 이유는 충분하다. 왜냐하면 SQL 서버 Express 버전의 설치/유지 보다는 LocalDB의 관리가 더욱 간단하기 때문이다. 결국, “User Instance” 기능은 SQL 서버 Express 버전에 종속되는 반면, LocalDB는 “User Instance”기능을 별도로 분리시켜 새로운 SQL 서버 버전으로 추가되었다고 볼 수 있다.


마치면서…

장점만을 부각시켜서 현재의 응용 프로그램 구조에 채택하도록 만들었다가 자칫 결정적인 순간에 알게 된 단점으로 인해 더 큰 실망으로 이어지는 부작용을 없애기 위해 이쯤에서 단점들을 정확하게 짚고 넘어가는 것도 필요할 것 같다. 이미 위의 글을 진행하면서 단점들이 일부 소개된 것이나 다름없지만 그래도 명시적으로 나열해보면 다음과 같다.

.NET Framework 4.0 에서만 지원 아직 정식버전이 나오기 이전이라서 단정지을 수는 없지만, .NET Framework 4.0.2 QFE만 제공되는 이유로 인해 .NET 3.5 이하 버전에서는 LocalDB가 설치되어도 연결할 수 없다.

.NET Framework 4.0.2 업데이트 필요 추가적인 관리 요소가 필요 없다는 것이 LocalDB의 장점임에도 불구하고 오히려 .NET Framework 자체를 업데이트해야 하는 관리 요소가 추가되었다. 아마도 현재 시점의 클라이언트 컴퓨터라면 .NET Framework 4.0 기준으로도 소수일 테고, 4.0.2로 업데이트 된 경우는 거의 없다 생각하고 배포 정책을 결정하는 것이 맞을 것이다.

모바일 미지원 굳이 LocalDB의 단점이라기 보다는, 이런 용도로 제작된 것이 아니라는 인식을 확인하는 차원에서 포함했을 뿐 별 의미는 없다. 이런 제약때문에라도 여전히 모바일 환경에서는 SQL 서버 Compact Edition 버전이 선택대상으로 고려될 수 있다.

Windows Vista SP2, Windows Server 2008 SP2 이상의 운영체제 지원 정식 버전이 나오는 시점에도 크게 달라질 것 같지 않지만, Windows XP/2003 급의 운영체제에서는 공식적으로 지원되지 않는다. (설치 자체가 안 된다.)

참고로, Itanium 버전(IA-64)은 더 이상 SQL 서버 버전에서 지원하지 않기로 마이크로소프트 측에서 공식적으로 밝힌 상태이므로 당연히 LocalDB 기능도 IA-64 용으로는 릴리즈 되지 않았다.

여기까지 SQL 서버 2012와 함께 제공되는 LocalDB 기능에 대해서 살펴보았다. 장/단점을 적절하게 파악하고, 향후 제작하게 될 응용 프로그램에 SQL 서버의 4가지 버전(Standard, Express, LocalDB, Compact)을 적절하게 선택해서 적용하는데 도움이 되기를 바라며 이만 글을 맺는다.

참고자료
  • http://blogs.msdn.com/b/sqlexpress/archive/2011/07/12/introducing-localdb-a-better-sql-express.aspx
  • http://blogs.msdn.com/b/sqlexpress/archive/2011/10/27/net-framework-4-now-supports-localdb.aspx
  • http://blogs.msdn.com/b/sqlexpress/archive/2011/10/28/localdb-where-is-my-database.aspx




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]





[최초 등록일: ]
[최종 수정일: 3/3/2012 ]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer@outlook.com

비밀번호

댓글 쓴 사람
 



2012-03-13 11시48분
위의 글을 쓰는 시점에서는 RC 였는데, 이제는 정식버전이 릴리즈되었습니다. (현재, MSDN구독자 다운로드 센터를 통해서 공개되었습니다.) 참고로, localdb 만 별도 설치본으로 빠져나와서, x64 용으로 33,768KB, x86 용으로 28,360KB 의 MSI 파일이 제공되고 있습니다.
정성태
2012-05-17 03시12분
[방문자] 좋은 내용 읽고 갑니다.
[손님]
2015-06-12 01시25분
연결문자열의 "Data Source"에 버전 문자열이 지정되어 SQL 서버의 버전에 따라 문제가 되었는데요.

Data Source=(localdb)\v11.0;

이것이 SQL Server 2014에 포함된 LocalDB부터는 다음과 같이 "mssqllocaldb"로 통합되어 더 이상 버전 문제로 고민할 필요가 없어졌습니다.

Data Source=(localdb)\mssqllocaldb;

Breaking Changes to LocalDB.
; http://www.sqlcoffee.com/SQLServer2014_0010.htm

정성태

1  2  3  [4]  5  6  7  8  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
11965정성태6/30/2019385.NET Framework: 846. C# - 2차원 배열을 1차원 배열로 나열하는 확장 메서드파일 다운로드1
11964정성태6/30/2019434Linux: 20. C# - Linux에서의 Named Pipe를 이용한 통신
11963정성태6/29/2019390Linux: 19. C# - .NET Core Unix Domain Socket 사용 예제
11962정성태6/27/2019341Math: 61. C# - 로지스틱 회귀를 이용한 선형분리 불가능 문제의 분류파일 다운로드1
11961정성태6/27/2019295Graphics: 37. C# - PLplot - 출력 모음(Family File Output)
11960정성태6/27/2019452Graphics: 36. C# - PLplot의 16색 이상을 표현하는 방법과 subpage를 이용한 그리드 맵 표현
11959정성태6/27/2019323Graphics: 35. matplotlib와 PLplot의 한글 처리
11958정성태6/25/2019776Linux: 18. C# - .NET Core Console로 리눅스 daemon 프로그램 만드는 방법 [1]
11957정성태6/24/2019810Windows: 160. WMI 쿼리를 명령행에서 간단하게 수행하는 wmic.exe [1]
11956정성태6/24/2019497Linux: 17. CentOS 7에서 .NET Core Web App 실행 환경 구성 [1]
11955정성태6/20/2019582Math: 60. C# - 로지스틱 회귀를 이용한 분류파일 다운로드1
11954정성태6/20/2019519오류 유형: 550. scp - sudo: no tty present and no askpass program specified
11953정성태6/20/2019342오류 유형: 549. The library 'libhostpolicy.so' required to execute the application was not found in '...'
11952정성태6/20/2019506Linux: 16. 우분투, Centos의 Netbios 호스트 이름 풀이 방법
11951정성태6/20/2019460오류 유형: 548. scp 연결 시 "Permission denied" 오류 및 "WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!" 경고
11950정성태6/18/2019603.NET Framework: 845. C# - 윈도우 작업 관리자와 리소스 모니터의 메모리 값을 구하는 방법
11949정성태6/18/2019371오류 유형: 547. CoreCLR Profiler 예제 프로젝트 빌드 시 컴파일 오류 유형
11948정성태6/17/2019454Linux: 15. 리눅스 환경의 Visual Studio Code에서 TFS 서버 연동
11947정성태9/25/2019531Linux: 14. 리눅스 환경에서 TFS 서버 연동
11946정성태6/17/2019569개발 환경 구성: 445. C# - MathNet으로 정규 분포를 따르는 데이터를 생성, PLplot으로 Histogram 표현파일 다운로드1
11945정성태6/25/2019545Linux: 13. node.js에서 syslog로 출력하는 방법
11944정성태6/16/2019994Linux: 12. Ubuntu 16.04/18.04에서 node.js 최신 버전 설치 방법
11943정성태6/15/2019807.NET Framework: 844. C# - 박싱과 언박싱 [1]
11942정성태6/20/20191217개발 환경 구성: 444. 로컬의 Visual Studio Code로 원격 리눅스 머신에 접속해 개발하는 방법
11941정성태6/13/2019472오류 유형: 546. "message NETSDK1057: You are using a preview version of .NET Core" 빌드 경고 없애는 방법
11940정성태6/13/2019444개발 환경 구성: 443. Visual Studio의 Connection Manager 기능(Remote SSH 관리)을 위한 명령행 도구파일 다운로드1
1  2  3  [4]  5  6  7  8  9  10  11  12  13  14  15  ...