2011년 7월 24일 일요일

[MS SQL Server] 데이터베이스 복구모델


데이터베이스 복구모델은 3가지가 있다.
1. 간단(단순) 복구 모델
2. 전체 복구 모델
3. 대량 복구 모델

이 중 간단 복구 모델과 전체 복구 모델을 자주 사용하게 된다. 간단히 정리하자면,

간단 복구 모델
데이터가 변경되는 내용을 로그파일에 기록하지 않음.
(마지막으로 백업된 시점까지만 복구 가능)

전체 복구 모델
데이터가 변경되는 모든 작업과 내용을 로그파일에 기록.
(장애가 난 최근 시점까지 복구 가능)


전체 복구 모델을 사용할 경우 트랜잭션 로그파일의 크기가 커져서 DB 백업 파일의 크기가 늘어나게 된다.
DB복구에 가장 최근 시점까지 복구가 필요한 경우가 아니라면 간단 복구 모델로 DB 백업 파일의 크기를 줄여주었다.



■ 데이터 베이스 복구 모델 선택
cf) 데이터베이스 복구 모델 선택 - MSDN
단순 복구 모델을 선택하는 경우


다음에 해당하는 경우 단순 복구 모델을 사용합니다.
- 오류 지점 복구가 필요하지 않습니다. 데이터베이스가 손실되거나 손상될 경우 오류 지점과 이전 백업 사이의 모든 업데이트가
  손실되어도 상관 없습니다.


- 로그에 있는 일부 데이터가 손실되어도 상관 없습니다. 


- 트랜잭션 로그를 백업 및 복원하지 않고 전적으로 전체 및 차등 백업을 사용하려고 합니다.


전체 복구 모델을 사용하는 경우
다음 중 하나에 해당되는 경우 전체 복구 모델과 선택적으로 대량 로그 복구 모델을 함께 사용합니다.

- 모든 데이터를 복구할 수 있어야 합니다.


- 데이터베이스에 여러 파일 그룹이 있으며 읽기/쓰기 보조 파일 그룹과 선택적으로 읽기 전용 파일 그룹의 증분 복원을
  수행하려고 합니다. 


- 실패 지점까지 복구할 수 있어야 합니다. 


- 개별 페이지를 복원하려고 합니다.


- 트랜잭션 로그 백업의 관리 비용이 발생해도 괜찮습니다.



■ 복구 모델 확인





■ 단순/전체 복구 모델로 변경


SQL Server Management Studio 에서도 변경 가능
DB의 속성 페이지 - 옵션 - 복구 모델




2011년 7월 12일 화요일

[MS SQL Server] 비교 연산자와 ANSI_NULLS 데이터베이스 옵션


■ 문자열 데이터 타입에 대한 비교 연산
DECLARE @ApplyVersion NVARCHAR(50);
DECLARE @Version NVARCHAR(50);

SET @ApplyVersion='2011071203';
SET @Version='3';

IF @ApplyVersion > @Version
BEGIN
    ...
END

문자열 타입을 대상으로 비교 연산자 > 를 사용할 때 어떻게 비교할까?
프로그래밍 언어와 다르게 DB 조건문에서는 뭔가 다른 동작을 할까?
예상대로 프로그래밍 언어의 문자열 비교와 마찬가지로 문자열의 첫음부터 알파벳 순서대로 비교를 한다.
위 예에서는 @Version 이 큰 값으로 판단한다.

하지만 문자열을 조건문에 사용할 때 중요한건 ANSI_NULLS 데이터베이스 옵션


■ ANSI_NULLS

MSDN : SET ANSI_NULLS (Transact-SQL)

SET ANSI_NULLS ON 으로 설정 할 경우, NULL값을 포함할 수 있는 비교 동작은 UNKNOWN (결과값이 없다.)
SET ANSI_NULLS OFF 으로 설정 할 경우, NULL값을 포함할 수 있는 비교 동작은 예상대로 동작한다.
하지만 특별한 경우가 아니고서는 식에  NULL 값을 포함할 수 있는 비교에는 ANSI_NULLS 설정에 영향을 받지 않는
IS NULL, IS NOT NULL 을 사용하는게 유용할 것 같다.

2011년 7월 1일 금요일

Windows Forms User Settings in C#


User Settings 을 저장하고 불러오는 방법.

출처 : Windows Forms User Settings in C# - Code Project








Introduction

This morning, for the first time, I was jealous of VB.NET programmers. The My.Settings namespace makes loading and saving user settings pretty easy, and it�s pretty well documented. Unfortunately, C# programmers don�t have anything quite as slick as the My.Settingsnamespace, and the procedure for persisting user settings is not well-documented.

It turns out that it is pretty easy to persist user settings in C#, and this article will show you how to do it. We�re going to stick to the basics�nothing fancy. We will use as our example a Windows Forms �Hello World� program that does nothing but show a window with the canonical text:


We will create settings for the application window�s size and location properties, and we will persist them between runs of the program. The project code can be downloaded from the link at the top of this article.

Step One: Create the Settings

The easiest way to create settings is to use the Visual Studio Settings Designer. To get to the designer, open the project�s Properties pages, and select the Settings tab:


As you can see from the Settings grid, settings can have Application scope or User scope. Application settings are those that apply across all users, and that do not change from run to run of the program. Once an Application setting is set in the designer, it can�t be changed in code.

User settings are those that change from user to user, and from run to run of an application. They can be changed in code. User settings are commonly used to store user preferences, such as window size and location. That�s what we�re going to do here.

Fill out the Settings grid so that it looks like this:


The grid is self-explanatory. Note the default values in the Value column. I simply copied these from the Properties of the form. Note that you must include default values in the Values column! If you leave them out, the designer code will declare the settings, but it won�t instantiate them, and any code that calls them will throw a runtime exception.

Once you have entered the settings on the grid, save the project and close the Properties pages.

Step Two: Load the Settings at Runtime

The code to load the settings at runtime is very simple. The designer created a class for us that holds our settings. The class is located in a Properties namespace under our project name. Our first step is to add a using statement for this class:

using UserSettingsDemo.Properties;
Node that the Visual Studio code editor can add this statement for us automatically. If we haven�t added the statement, then the first time we type �Settings�, the code editor will present a smart tag that can enter the using statement automatically:


Once the using statement has been added, we simply need to add a few lines of code to the window�s event handlers.

Create a FormLoad event handler for the target window, and add the following code to the handler:

private void FormMain_Load(object sender, EventArgs e)
{
    // Set window location
    if (Settings.Default.WindowLocation != null)
    {
        this.Location = Settings.Default.WindowLocation;
    }

    // Set window size
    if (Settings.Default.WindowSize != null)
    {
        this.Size = Settings.Default.WindowSize;
    }
} 
The code is self-explanatory. Note that we find our settings in a Properties class that the designer created for us. This class can hold multiple sets of settings for a user; we want the Default set.

Step Three Save the Settings at Runtime

Saving settings is almost as easy. However, there is a minor complication when saving a window�s size. We will see that in the code sample that follows.

The persistence code for settings is generally placed in the FormClosing event handler for the target window. Create the handler, and add the following code to it:

private void FormMain_FormClosing(object sender, FormClosingEventArgs e)
{
    // Copy window location to app settings
    Settings.Default.WindowLocation = this.Location;

    // Copy window size to app settings
    if (this.WindowState == FormWindowState.Normal)
    {
        Settings.Default.WindowSize = this.Size;
    }
    else
    {
        Settings.Default.WindowSize = this.RestoreBounds.Size;
    }

    // Save settings
    Settings.Default.Save();
}
The WindowLocation setting is self-explanatory, but the WindowSize property has a wrinkle. If a window is normal size, we can read its size property in the usual manner. But if a window is minimized or maximized, the size property will return an inaccurate value. So, .NET provides a RestoreBounds property that will return the size of the window in its normal state. But�and here�s the wrinkle�the RestoreBounds property returns a valid value only when the window is minimized or maximized. As a result, we have to test the WindowStateproperty, and call either the Size or RestoreBounds property based on the results.

Note that we have to call the Settings� Save() method to save the settings to the config file. And the config file is not the Application.exe.config file�only application settings go there. User settings are saved to different settings files for each user, which are stored in an arcane location. This FAQ explains how to find the settings file, in case you need to get to it.

Data Binding

Many settings can be data-bound from the Visual Studio Properties window. For example, we could have data bound our form�s location property (but not its size property) by setting a binding in the ApplicationSettings property:


The Size property can�t be data-bound because whether we use the Size or RestoreBounds property isn�t decided until runtime. But for many properties, data binding provides the simplest and easiest approach. Just remember that you will still need to save the Settings from code before your app closes:

// Save settings
Settings.Default.Save();

Conclusion

And that�s about all there is to creating, loading, and saving user settings in C# 2.0. It�s just about as easy as using the VB.NET My.Settings namespace, and it provides a simple procedure for persisting just about any user setting you might create. And it means I can now go back to pretending I�m not jealous of some of the convenience features built in to VB.NET!


License


This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here


About the Author








David Veeneman


Software Developer (Senior)
Foresight Systems
United States United States

Member

David Veeneman is a financial planner and software developer. He is the author of "The Fortune in You