[오라클] CONNECT BY 절


http://blog.naver.com/jadin1?Redirect=Log&logNo=70018085041  

CONNECT BY절을 이용해서 계층 구조 테이블을 SELECT 해보자(  흔히 답변 달리는 게시판들에 필요 할 거라 생각된다. )

[MYSQL] 설치시 1045( 3306포트 defined에러관련 )


http://warmz.tistory.com/228  

위 블로그를 참고해서 설치해주면 잘 설치된다. 저도 이리해서 설치 완료 했습니다. 

[MSSQL] MDF, LDF를 이용한 DB 복원( DB 복사에도 사용 할 수 있다 )


exec sp_attach_db 'DB명', 'MDF경로','LDF경로'

exec sp_attach_db 'ogoods_suryang_fifo', 'C:\Program Files (x86)\Microsoft SQL Server\MSSQL.1\MSSQL\Data\ogoods_suryang_fifo.mdf','C:\Program Files (x86)\Microsoft SQL Server\MSSQL.1\MSSQL\Data\ogoods_suryang_fifo_log.ldf'


기본 사용 방법은 위와 같으며 DB 복사의 경우 기존 DB를 중지시키고 DB를 복사한 후 이름을 변경하고 위와 같이 DB명을 다른이름으로 지정 해 준다. 

MySql 설치 및 DB 만들기, 테이블 만들기


http://killmewild.blog.me/30097725904  

요 사이트를 한번 다 훑터 보면 설치부터 DB 테이블 만들수 있을것이다. 

SELECT문 WITH(???LOCK) 절


출처 : http://zephome.tistory.com/141 

평소에 잘모르고 무심코 사용을 했었는데 다시 한번 생각해보게 되네요.
DBguide.net Q&A 게시판

Question

안녕하세요?
막 DB를 만지기 시작한 초보입니다.
다름이아니고 궁금한게 있어서 그런데요,
쿼리문을 쓰다보면 쿼리문 뒤에 With (***Lock) 옵션을 붙이잖아요~
예를들어
select * from dbo.Test    with (nolock)
혹은
update dbo.Test  with (updlock) set a=10

이런식으로 NOLOCK, ROWLOCK, UPDLOCK 등을 쓰는걸 봤는데요,
각각의 간략한 의미와 어떤 문에 붙여야하는지 어드바이스 좀 해주세요 !
예를들어
 "  NOLOCK 은 SELECT  문에서 LOCK 걸리는걸 막아준다  "  같은거요~
부탁드립니다!



Answer

오랫만에 인사드립니다.
제가 3개월간의 파견근무를 마치고 다시 회사로 돌아왔습니다.
그동안 MSSQL 분야 질문에 대한 답변을 소홀하게 했던 점 송구하게 생각합니다.
다른 분들이 잘 설명을 주셨는데,사족을 좀 붙여보고자 합니다.

1) NOLOCK (=READUNCOMMITTED)
MS SQL 서버의 경우 데이터의 일관성을 보장하기 위해 SELECT 작업을 할 때도 공유잠금(S)을 설정합니다.
이러한 경우,
SELECT 하는 동안에는 동일한 대상(행,페이지,테이블 등)에 다른 spid에서 배타적잠금(X)를 설정할 수 없습니다.
하지만, 이러한 특성 때문에 동시사용자가 많은 경우에서 차단(Blocking) 현상이 발생할 가능성이 있습니다.
즉,  
1) 임 배타적잠금이 걸린 대상에 대해서는 공유잠금(S)을 설정할 수 없기 때문에 차단이 발생하는 경우와,
2) 공유잠금이 걸린 대상에 배타적잠금을 설정하는 경우가 모두 차단현상이 발생하는 문제가 발생합니다.
이를 해결하기 위해
SELECT 쿼리의 FROM 절 다음의 각 테이블의 NOLOCK 옵션을 사용하게 되면
SELECT 쿼리를 할 때 공유잠금을 설정하지 않고 데이터를 읽게 됩니다.
이를 통해, 위의 두 가지 경우 차단현상이 발생하지 않고 작업을 수행할 수 있습니다.

2) ROWLOCK
SQL Server는 기본적으로 행 단위 잠금을 사용합니다.
다만, 내부적인 기준에 따라 행 단위 잠금보다 더 상위 단위(페이지, 테이블) 대상에 대해서 잠금을 설정해야 한다면 페이지잠금, 테이블 잠금을 자동적으로 승격하여 사용하게 됩니다.
이러한 경우, 특별하게 사용자가 이를 통제하여 행단위잠금을 강제하기 위해서 사용하는 옵션입니다.
이 옵션은 채번과 같은, 매우 고유한 업무에 대해서만 제한적으로 사용되어야 합니다.

3) UPDLOCK
UPDLOCK은 SELECT하는 대상에 대해 곧바로 배타적잠금을 설정할 예정인 경우, SELECT하는 대상에 다른 세션에서 배타적 잠금을 설정하지 못하도록 통제하기 위해서 사용합니다.
즉 
1) SPID 51 : SELECT * FROM 테이블
2) SPID 52 : UPDATE 테이블 SET...
3) SPID 51 : UPDATE 테이블 SET...
이러한 경우 51번의 업데이트 작업은 52번의 업데이트 작업이 완료될 때까지 차단되고 대기해야 합니다.
이 때
1) SPID 51 : SELECT * FROM 테이블 WITH(UPDLOCK)
2) SPID 52 : UPDATE 테이블 SET...
3) SPID 51 : UPDATE 테이블 SET...
을 사용하면, 
52번 업데이트 작업이 51 번에서 설정된 UPDLOCK으로 인해 차단되고, 3번 UPDATE 작업은 계속하여 진행할 수 있게 됩니다.

이러한 잠금과 관련한 옵션은 데이터 일관성과 병행성이라는 두 마리 토끼를 잡기 위해 노력하면서, 데드락과 같은 문제가 발생하지 않도록 하기 위해, 각 업무환경에 따라 매우 주의하여 사용되어져야 합니다.
감사합니다.

P.S> 추가적인 질문은 언제든지 게시판에 올려 주시면 됩니다

[ODBC] 윈도우7 64비트에서 ODBC 원본 드라이버 안보일경우...


  내 피시의 경우 window 밑에 system32의 odbcad32가 바로가기 지정 되어 있었다. 이걸 syswow64밑의 odbcad32로 바꾸어 보니 정상적으로 드라이버들이 로드된것이 확인 되었다.




[MSSQL] 2000 -> 2008 변경후 사용자 삭제가 안될 경우


1. 스키마를 삭제하고 사용자를 삭제 해 본다.
    ( http://blog.naver.com/darkancia?Redirect=Log&logNo=110055939417 )

2. http://cherni0911.blog.me/130044580691
3. http://blog.naver.com/findaday?Redirect=Log&logNo=56034507,
   
http://blog.naver.com/lovzip?Redirect=Log&logNo=20056017177

MSSLQ2005 로그축소(MSSQL2000 로그축소, MSSQL2008 로그축소)


MSSQL 2005 의 경우

use [DB명];
sp_helpfile;                                       <- 로그파일 정보 확인

backup log [DB명] with no_log;
dbcc shrinkfile ([로그파일명], 10);          <- [로그파일명]을 10MB로 축소

MSSQL 2000 의 경우

use [DB명];
sp_helpfile;                                       <- 로그파일 정보 확인

backup log [DB명] with truncate_only;
dbcc shrinkfile ([로그파일명], 10);          <- [로그파일명]을 10MB로 축소

MSSQL 2008 의 경우

USE AdventureWorks;
GO
-- Truncate the log by changing the database recovery model to SIMPLE.
ALTER DATABASE AdventureWorks
SET RECOVERY SIMPLE;
GO
-- Shrink the truncated log file to 1 MB.
DBCC SHRINKFILE (AdventureWorks_Log, 1);
GO
-- Reset the database recovery model.
ALTER DATABASE AdventureWorks
SET RECOVERY FULL;
GO

 

[MSSQL] 백업 시스템 (전체 백업 및 트랜잭션로그 백업)


출처 : http://kuaaan.tistory.com/120
 얼마전에 개발서버에서 HDD가 가득찬 적이 있었습니다. 알고 보니 .mdf 파일은 수백메가 수준인데 .ldf 파일이 무려 30기가가 넘게 쌓여 있더군요. shrink 문을 날려도 줄지도 않고... 게다가 일단 트랜잭션 로그파일이 차게 되면 insert, select, delete 등 select를 제외한 아무 작업도 되지 않습니다. HDD 공간을 확보해도 인덱스라도 한번 재구성하고 나면 금방 다시 차버립니다.

데이터베이스의 로그 파일이 꽉 찼습니다. 데이터베이스의 트랜잭션 로그를 백업하여 사용 가능한 일부 공간을 확보하십시오

 뭔짓을 해도 위와 같은 에러만 나죠. 아주 미칩니다. ㅋㅋ
 그래서... .ldf 파일 사이즈를 줄이는 방법을 구글링해서 해결하기는 했죠. 그런데... 갑자기 트랜잭션 로그란 놈이 뭐하는 놈인지 궁금하더라구요. 이렇게 막 지워도 되는건지 겁도 나고... 제가 업이 DBA가 아닌 개발자라... 평소에 이런 방면에 대해서는 잘 몰랐거든요. 그래서 하루저녁 정도 백업 관련 자료를 찾아보면서 공부한 내용을 정리해 보았습니다.

1. SQL Server DBA가 수행해야 할 세가지 백업
 DB가 깨졌을 때를 대비하여 DBA는 다음의 세가지 백업을 수행해야 합니다.
1) Full Backup
말 그대로 풀 백업입니다. .mdf 파일에 들어있는 모든 데이터를 백업받죠.
그런데 풀백업이 이루어지는 동안에도 트랜잭션이 계속 진행되기 때문에 실제로는 아직 커밋되지 않은 작업이 백업시 포함될 수 있습니다. 나중에 이 백업을 리스토어했을 때 커밋되지 않은 데이터가 들어있다면 좀 이상해지겠죠? 그래서 실제로 풀백업을 받을 때는 현재 진행중인 트랜잭션에 대한 트랜잭션 로그도 함께 백업됩니다.
풀 백업이 중요한 것은, 풀 백업이 보관되어 있지 않다면 Differential Backup이나 트랜잭션 로그 백업을 아무리 열심히 받았어도 아무 소용이 없기 때문입니다.

HDD로 풀백업을 수행하는 SQL은 다음과 같습니다. (물론 GUI로도 가능합니다.)
  1. BACKUP DATABASE [DATABASENAME] TO DIST = 'C:\Temp\BackupFileName'  

만약 백업받을 파일을 백업장치로 등록하면 다음과 같이 간단하게 할 수 있습니다.
  1. EXEC sp_addumpdevice 'disk',    
  2.          '[BACKUPDEVICENAME]''C:\Temp\BackupFileName'  
  3. BACKUP DATABASE [DATABASENAME] TO [BACKUPDEVICENAME]  

2) Differential Backup (차등 백업? 차분 백업?)
이건 OS 백업받을 때의 Differential Backup과 유사합니다. "가장 마지막에 Full Backup 받은 이후의 변경 부분에 대한 백업"입니다. 마지막에 받은 Differential Backup 이후의 변경사항을 백업받는 것이 아닙니다. (SQL Server에는 Incremental Backup이란 개념이 없습니다.)
만약 10월 1일에 풀백업을 받은 후 10월 5일, 10일 15일에 Differential 백업 을 받았다면 DB를 15일자로 되돌리기 위해서는 10월 1일 풀백업을 Restore한 후 15일자 Differential 백업을 Restore하면 됩니다. (Intremental Backup과 달리 5일, 10일, 15일자를 모두 Restore할 필요가 없다는 거죠.)
  1. BACKUP DATABASE [DATABASENAME] TO [BACKUPDEVICENAME] WITH DIFFERENTIAL  

3) Transaction Log Backup (로그 백업)
트랜잭션 로그 백업에 대해 이해하려면 먼저 트랜잭션 로그란 놈에 대해서 이해를 해야겠죠?
트랜잭션 로그란 SQL Server에서 실행되는 모든 SQL문을 기록한 로그입니다. 어느 세션이 어떤 SQL을 실행했는지가 순차적으로 기록됩니다. 우리가 트랜잭션을 Rollback 시켰을 때 Begin Tran 시점 이전으로 되돌릴 수 있는 것은 트랜잭션을 시작한 이후의 모든 작업내용이 트랜잭션 로그에 기록되어 있기 때문입니다.
트랜잭션 로그는 다음과 같이 하여 백업받을 수 있습니다. (물론 GUI로도 가능합니다.)
  1. BACKUP LOG [DATABASENAME] TO [BACKUPDEVICENAME]  
 
로그 백업은 위의 데이터 백업과는 다른 몇가지 특성이 있습니다.

① 일단 백업된 트랜잭션 로그는 자동으로 삭제됩니다. 이때 ldf파일 사이즈가 줄어들지는 않지만 ldf 내에서 로그가 삭제되기 때문에 해당 ldf 파일에는 새로운 로그를 기록할 수 있는 빈 공간이 확보됩니다. 따라서, 주기적으로 트랜잭션 로그를 백업받으면, 별도로 로그를 삭제하지 않더라도 ldf 파일이 계속 커지는 것을 방지할 수 있습니다.

② 트랜잭션 로그는 가지고 있는 최신 풀백업 혹은 풀백업 + DifferentialBackup 세트로 부터 복원을 원하는 시점까지의 모든 백업본이 존재하지 않으면 아무 의미가 없습니다. 백업받은 로그 중 한 세트라도 분실하면 소용 없다는 의미입니다. 물론 풀백업을 한번도 받은적이 없다면 트랜잭션 로그는 소용없습니다.

③ 트랜잭션 로그가 온전하다면 Fault가 발생한 Database를 Fault 발생 직전의 시점으로 복원할 수 있습니다. 또한, 특정 시점으로의 Rollback 등 미세한 복원이 가능합니다.

  ※ 파일 백업은... 논외로 치겠습니다. ^^;


2. 트랜잭션 로그를 이용한 데이터 복원

트랜잭션 로그를 구체적으로 어떤 식으로 써먹을 수 있는지 두가지 예를 들어 살펴보겠습니다.

  1) 장애 시점까지의 DB 복구
다음과 같이 백업을 받고 있습니다.
① 10월 1일 DB Full Backup
② 10월 5일 Differential Backup
③ 10월 7일 Transaction Log Backup
④ 10월 9일 Differential Backup
⑤ 10월 10일 Transaction Log Backup
⑥ 10월 11일 Transaction Log Backup

만약 10월 12일에 DB에 Fault가 발생했다고 가정하겠습니다.
Q : DB를 Fault 발생 시점으로 완전하게 복구할 수 있을까요?
A : Yes~! .ldf파일의 트랜잭션 로그만 손상되지 않았다면 가능합니다.
복구 절차는 다음과 같습니다.

  • 현재 활성화된 트랜잭션 로그를 백업
  • 가장 최근에 수행한 전체 데이터베이스 백업을 복원
  • 차등 백업이 있으면 가장 최근의 것을 복원
  • 가장 최근에 차등 또는 전체 데이터베이스를 백업한 후에 만든 트랜잭션 로그 백업을 모두 차례대로 적용
  • 가장 최근에 로그를 백업한 후에 변경된 사항을 모두 수동으로 다시 실행

  • 위의 케이스에서는 다음과 같이 되겠지요.

    ① Fault가 발생한 시점의 트랜잭션 로그를 백업
    ② 10월 1일자 DB Full Backup을 Restore
    ③ 10월 9일자 Differential Backup을 Restore
    ④ 10월 10일자 트랜잭션 로그를 Restore
    ⑤ 10월 11일자 트랜잭션 로그를 Restore
    ⑥ ①에서 백업받은 트랜잭션 로그를 Restore

    Fault 발생지점까지 복원시키는 자세한 방법은 여기를 참고하세요.


      2) 특정 시점까지의 장애복구 (STOPAT)
    10월 12일에 실수로 중요 테이블을 Delete 시켰다고 가정합니다. 혹은 Update 하다가 실수로
    Where 절을 깜빡잊고 안적었다던지.. 하여간... 이런 상황. 백업받은 상황은 위와 동일하다고 가정합니다. 

    이러한 경우에도 복원이 가능할까요?
    넵! 트랜잭션 로그를 복원할 때는 "STOPAT"이라는 옵션을 통해 특정 시점까지만 복원이 가능합니다.

    문제가 발견된 시간을 기록하고, 해당 DB를 중지시킨 후 즉시 트랜잭션 로그를 백업받음
    ② 10월 1일자 DB Full Backup을 Restore
    ③ 10월 9일자 Differential Backup을 Restore
    ④ 10월 10일자 트랜잭션 로그를 Restore
    ⑤ 10월 11일자 트랜잭션 로그를 Restore
    ⑥ ①에서 백업받은 트랜잭션 로그를 "STOPAT" 옵션을 주어 ①에서 기록한 시간 직전까지만 Restore함.

    ⑤에 해당하는 작업은 다음과 같이 하면 됩니다.
    1. RESTORE LOG [DATABASENAME]   
    2. FROM  [BACKUPDEVICENAME]   
    3. WITH FILE = 3, STOPAT = '2009-10-15 14:15:23' , RECOVERY  

    지정 시간까지 복원시키는 방법에 대한 자세한 내용은 여기를 참고하세요.

    위의 SQL 문 중에서 FILE=3 이라는 옵션은 "LogBackupDeviceName"이라는 백업 디바이스의 백업세트 중 세번째 파일을 이용해 백업하라는 의미입니다. 백업 세트 내에 들어있는 파일 목록을 확인하는 방법은 다음과 같습니다.
    1. RESTORE FILELISTONLY FROM [BACKUPDEVICENAME];  
    RESTORE 문의 옵션에 대한 자세한 내용은 여기를 참고하세요. 


    3. 트랜잭션 로그를 삭제하여 로그파일(*.ldf 파일) 사이즈 줄이기

     위에서 얘기한 바와 같이 트랜잭션 로그를 백업받으면 자동으로 트랜잭션 로그가 삭제됩니다. 하지만 평소에 트랜잭션 로그를 백업받지 않던 DB서버에서 HDD 가 가득 찼다던지... 하면 트랜잭션 로그를 백업받을 여유가 없을 뿐더러... 무엇보다도 트랜잭션 로그를 삭제한다고 해서 무조건 .ldf 파일 사이즈가 줄어들지는 않는다는 것이 문제입니다. ^^

     트랜잭션 로그를 백업받지 않고 파일 사이즈를 줄이는 방법은 다음과 같이 두 단계로 이루어집니다.

    1) 로그 삭제 (BACKUP LOG ~)
     .ldf 파일 내에서 로그를 삭제합니다. 
     위에서 얘기한 바와 같이 "BACKUP LOG" 문을 실행하면 트랜잭션 로그를 백업한 후 자동으로 로그를 삭제하지만, 다음과 같은 옵션을 주면 백업받지 않고 로그만 삭제할 수 있습니다.
    1. DBCC SQLPERF(LOGSPACE) -- 현재 로그파일의 상태를 확인한다.   
    2. BACKUP LOG [DATABASENAME] WITH NO_LOG  -- 실제로 로그를 삭제하는 명령   
    3. --BACKUP LOG [DATABASENAME] WITH TRUNCATE_ONLY 위의 SQL과 동일한 효과  

    2) 로그파일 축소 (DBCC SHRINK~~)
     .ldf 파일의 사이즈를 축소합니다.
     위의 로그 삭제 작업은 ldf 파일 내에서 로그를 삭제하여 공간을 확보하지만 정작 ldf 파일의 사이즈는 줄어들지 않기 때문에 HDD의 여유공간을 확보하지 않습니다. 로그를 삭제한 후 아래와 같이 로그 파일에 대해 SHRINK 작업을 수행하면 위에서 삭제한 트랜잭션 로그의 공간만큼 실제로 ldf 파일을 축소시켜 HDD의 공간이 확보됩니다.
    1. SP_HELPDB [DATABASENAME] -- 대상 파일이름 확인 (name 컬럼)   
    2. DBCC SHRINKFILE([LOGFILENAME], 5, TRUNCATEONLY) -- 5MB까지 파일을 축소   
    3. -- DBCC SHRINKFILE(DBName_log, 5, TRUNCATEONLY) -- 보통은 이렇게...  
     
     위에서 얘기했듯이, 트랜잭션 로그는 풀백업 시점에서부터 장애 시점까지의 모든 로그가 보관되어 있지 않다면 소용이 없기 때문에, 로그파일을 삭제한 후 장애가 발생하면 장애 시점까지의 복원이 불가능해집니다. 따라서, 트랜잭션 로그를 삭제하여 HDD 공간을 확보한 후에는 반드시 풀 백업을 새로 받는 것이 좋습니다.

     로그를 삭제하지 않고 무조건 SHRINK DATABASE를 한다고 해서 ldf파일의 공간이 줄어들지는 않습니다. 왜냐하면, "SHRINK 는 불필요한 공간을 정리하는 작업"이기 때문입니다. 디스크 조각모음을 시킨다고 해서 필요한 로그를 마음대로 삭제해 버리면 안되겠죠? ^^

     다음과 같은 경우에는 SHRINK 작업을 수행하면 트랜잭션 로그가 삭제되고, .ldf 파일이 축소됩니다. 즉, SQL Server는 다음의 세 가지 경우에는 남아있는 트랜잭션 로그를 무용지물이라고 판단합니다. 세가지 경우의 상황에서 장애가 발생했다고 상상해보세요. 트랜잭션 로그가 있어도 장애 복구에 도움이 되지 않는 다는 것을 알 수 있습니다.
     반대로 다음의 세가지 중 한가지 경우에도 해당이 안된다면 SHRINK 작업을 수행하더라도 .ldf 파일의 사이즈가 줄어들지 않습니다. 왜? 이 트랜잭션 로그가 장애 복구에 필요할 수도 있기 때문이죠. 

    ① BACKUPLOG 문으로 로그를 지운 경우 : 이미 로그가 백업되었고, 백업된 로그는 내부적으로 삭제되기 때문에 .ldf 파일이 축소될 수 있습니다. WITH NO_LOG 옵션을 준 경우도 마찬가지입니다.
    ② 복구모델이 SIMPLE인 경우 : 복구모델이 SIMPLE이라는 것은 현 시점의 트랜잭션 로그가 보관되지 않는다는 의미이기 때문에 지나간 트랜잭션 로그도 소용 없다고 판단할 수 있습니다. 
    ③ 한번도 DATABASE 풀백업을 받은 적이 없는 경우 : 풀백업이 없다면 트랜잭션 로그 보관은 의미가 없습니다.

    4. SQL Server의 복구 모델
    SQL Server에서는 다음의 세가지 복구모델을 지원합니다. 이 복구모델에 따라 트랜잭션 로그를 기록하고 보관하는 방식이 달라집니다.

    1) 전체 (Full)
    모든 작업에 대해 트랜잭션 로그가 기록되고, 필요시 복원하거나 원하는 시점까지 복원이 가능합니다. 기본 설정이며, 로그가 가장 많이 기록되고 성능은 가장 떨어집니다.
    2) 대량로그 (Bulk Log)
    전체 모델과 거의 유사하나 대량의 로그가 기록되는 다음의 작업들에 대해 로그를 남기지 않기 때문에 로그가 더 적게 남고, 성능이 전체 모델보다 더 높습니다.
    . SELECT INTO
    . BCP 혹은 BULK INSERT
    . CREATE INDEX 혹은 INDEXED VIEW
    . TEXT 및 이미지 작업
    3) 단순 (Simple)
    단순 복구모델에서는 CheckPoint (DBMS가 메모리와 HDD 의 Sync를 맞추는 시점) 발생시마다 Sync 후 트랜잭션 로그를 삭제합니다. 따라서, 트랜잭션 로그를 사용한 DB 복원이 불가능하며, 장애 발생시 풀백업 혹은 Differential 백업을 받은 시점까지만 복원이 가능합니다. (BACKUP LOG 문도 실행되지 않습니다.)
    만약 DB를 백업받지 않는 서버라면 (장애나면 데이터 포기?? ^^) 단순 복구모델로 설정해도 좋을 듯 합니다. 어차피 풀백업이 없으면 트랜잭션 로그도 소용 없으니까요.

    현재 운영중인 DB의 복구모델을 변경할 때는 각 복구모델을 변경한 후에 장애가 발생해도 복구가 가능하도록 하기 위해 복구모델 간의 관계를 잘 따져보아야 하는데 이부분에 대한 자세한 내용은 여기를 참고하세요.

    인스톨팩토리 + 오라클 인스턴트 클라이언트 작업시


    오라클 인스턴트 클라이언트를 인스톨 팩토리로 배포 할 경우
    위와같이 개인사용자 환경변수 등록이 가능하다.
    또  간혹 오라클 캐릭터 셋이 안맞는 경우가 존재하는데
    그럴때는 다시 키값을 하나 추가한 후 값의 이름을 NLS_LANG,
    값을 KOREAN_KOREA.KO16MSWIN949 이런식으로 맞추어서

    넣어주면된다. 조금더 오라클 관련 값을 추가 하고 싶다면
    http://blog.naver.com/oct8?Redirect=Log&logNo=100042831960 링크를 확인 바란다.

    [MSSQL] 프로시저의 예외 처리


    프로시저의 예외처리 및 새로운 기능 MSSQL2005 :
    http://cafe.naver.com/ebasenet.cafe?iframe_url=/ArticleRead.nhn%3Farticleid=169

    예외처리 사용 방법 :

    -------------------------------------------------------------------------------------------------------------------
    프로시저의 기본적인 내용 : http://wishkjh.blog.me/80013950564

    파워빌더에서 프로시저 호출시 OUTPUT 관련 :
    http://blog.naver.com/ok_yoonbari?Redirect=Log&logNo=150080934966

    [MSSQL] 말일 구하는 방법


    참조블로그 : http://blog.naver.com/urlham/100065338331

    인덱스 관련



    [인덱스]-색인
    책에서 원하는 내용을 빨리 찾으려면 인덱스를 이용(책의 인덱스와 비슷한 개념)
    DB도 사용자가 원하는 내용을 빨리 찾으려면 색인이란 정보를 미리 만들어서 원하는 데이터를 빨리
    찾을 수 있게 할 수 있다.

    DB의 고급 퍼포먼스 성능 튜닝과 관련된 작업

    데이터베이스내의 테이블에서 원하는 정보를 좀더 빨리 찾아줄수 있게
    데이터의 위치 정보를 모아놓은 데이터베이스내의 객체 object이다
    DB의 전반적인 성능의 핵심이 되고 반드시 알아야 할 기술

    *인덱스는 정렬되어 있다.
    예1) 사진에서 원하는 데이터를 찾을때
    예2) 책에서 책뒷부분의 인덱스 페이지


    table scan  -- 전부다 검색

    index seek  -- 원하는 페이지만 검색

    ===========================================
    *포인트쿼리   point query
     조회되는 데이터가 한두개
     select * from tb_member where uid='kim'    --값이 하나

    *범위쿼리   range query
     조회되는 데이터가 다수 
     select * from tb_member where regdt='2008/06/19' -- 값이 다수

    *커버드쿼리  covered query
     조회의 대상과 조회의 결과가 컬럼이 일치하는 상태
     인덱스 측면에서 제일 빠른 성능을 냄

     select * from tb_member where uid='kim' and upw='1234'--커버드 쿼리 아님 포인트쿼리

     select uid from tb_member
     where uid='kim' and upw='1234' : 커버드 쿼리
     

    1. clustered index 클러스터 인덱스
    형식) create clustered index 인덱스명
    on 테이블명(칼럼명 오름/내림)
    해당 컬럼을 기준으로 정렬, 테이블당 1개씩만 허용.
    데이터를 여러개 조회하는 범위 쿼리이건, 하나만 조회하는 포인트 쿼리건 둘다 성능 발휘, 아껴서 사용
    primary key  설정시 그 컬럼에 자동으로 클러스터드 인덱스가 만들어진다.
    이 컬럼은 데이터 입력, 수정, 삭제시 항상 정렬을 유지한다.
    기본적으로 인덱스는 정렬되어 있다. <<-- 이자체가 인덱스

    즉 그 인덱스가 사전식으로 정렬 된다.

     

    2. nonclustered index 넌클러스터 인덱스  인덱스 페이지 따로 만든다. 용량이 더 차지 한다.(로그파일에 저장)
    기존의 테이블 + 넌클러스트 인덱스테이블
    형식)create nonclustered index 인덱싀름
       on 테이블명(칼럼명 정렬)
       -인덱스 페이지 따로 만든다.
       -레코드 원본은 정렬 안됨
       -테이블당 240개 정도 만들수 있다
       -포인트 쿼리는 성능발휘/ 범위 쿼리는 장담 할 수 없음


    예) 클러스터 인덱스는 책을 비유하자면 페이지를 알기 때문에 바로 그 페이지를 펴는 것과 비교되는것이고
    넌클러스터 인덱스는 뒤에 목차에서 찾고자 하는 내용의 페이지를 찾고 그 페이지로 이동 하는것과 같음
    테이블스캔은 처음부터 한장씩 넘기면서 내용을 찾는것과 같다.

    --포인트 쿼리일때 비교 : 포인트 쿼리에서는 별다른 속도 차이가 없다.

    --인덱스 추가 범위 쿼리일때 비교

    select * from w_zipcode where dong like '당산%'
    select * from c_myzip where dong like '당산%'
    select * from n_myzip where dong like '당산%'--%당산% 일때 처음에 %가 있으면 table scan 으로 된다. 따라서 속도시간이 늘어난다.

    create clustered index dong인덱스
    on c_myzip(dong asc)

    create nonclustered index dong인덱스2
    on n_myzip(dong asc)

    --어떤 컬럼에 인덱스를 걸어야 하는지??
    1.where절에서 자주 사용되는 컬럼 (예 : dong 컬럼 -> 자주 검색하기 때문에)
    2.like '%~~~' 조심 . %는 뒤에만 오게 해야 속도가 빨라진다.
    3.between A and B (클러스터인덱스가 유리)--범위 쿼리문에서는 클러스터드인덱스가 유리하지만 클러스터드인덱스는
    -- 그 테이블에서 한번만 사용되는 단점을 가지고 있다.
    4. order by가 항상 사용되는 컬럼
    5. join으로 자주 사용되는 컬럼
     FK( 1:1 대응이 많을 때 -- >  둘다 상관 없음(상황에 따라 넌클러스터드 인덱스를 사용)
      1:N 대응이 많을 때 -- > 클러스터드 인덱스 유리
    6. 100만건 중에 10개 조회/1000개 조회 --찾는 것이 적은 수에 주로 인덱스를 걸어주는 것이 상책이다.
     주의)  중복 데이터가 많은 컬럼 (성별)-->인덱스를 거는게 아님
       조회되는것이 많으면 그냥 처음부터 찾는것이 나은편.
    7.not 연산자 -> 긍정문을 바꿔서...
    8.insert, delete가 빈번한 컬럼은 인덱스에 좋은 영향은 아님

    *인덱스로 인해 얻는 손해
    1.만드는데 시간과 많은 공간이 필요하고, 만들고 난 후에도 추가적인 공간이 필요한다.
    2.데이타를 수정(insert, delete, update)하는 시간,
       특히 insert작업은 오히려 더 많이 걸린다.

    DB 설계시 정규화



    정규화(normalization)이란 무엇인가?
    DB 설계란 자료의 중복성과 비정규성을 제거하고 검색키를 설정하기 위해 데이타베이스의 logical schema를 작성하는 것입니다. 데이타베이스 설계시 가장 중요한 관심사는 릴레이션 구조를 결정하는 것이라고 할 수 있다. 데이타베이스에 어떤 릴레이션을 두고, 그 릴레이션에 어떠한 속성을 포함시킬 것인지는 데이타관리 및 사용의 성패에 큰 영향을 미친다. 바로 정규화이론은 어떠한 릴레이션 구조가 바람직한 것인지, 바람직하지 못한 릴레이션을 어떻게 분해하여야 하는지에 관한 구체적인 판단기준을 제공한다.

    정규화의 목적
    자료정규화작업의 가장 큰 목적은 자료저장의 중복성 배제이다. 정규화이론에서는 릴레이션의 형태가 여러단계로 구분된다. 가장 기본적인 정규화조건도 만족하지 못하는 릴레이션을 비정규형, 만족하는 릴레이션을 제1정규형이라고 부른다. 조건이 점점 엄격해짐에 따라 제2, 제3, 제4, 제5정규형으로 구분된다. 정규화이론에서는 보다 높은 단계의 정규형으로 나아갈수록 보다 바람직한 릴레이션 구조를 가진다고 간주한다. 즉 높은 단계의 정규형으로 나아갈수록 데이타의 본질적 의미가 릴레이션 구조에 보다 정확히 반영되고, 데이타 중복을 줄이고, 데이타 변경시 발생하는 문제점을 방지하고, 궁극적으로 데이타 무결성(data integrity)을 제고할 수 있다고 가정된다.

    제 1 정규형
    - 개별 테이블에서 반복되는 그룹을 제거합니다.
    - 관련 데이터의 각 집합에 대해 별도의 테이블을 만듭니다.
    - 기본 키를 사용하여 관련 데이터의 각 집합을 식별합니다.

    제 2 정규형
    - 여러 레코드에 적용되는 값 집합에 대해 별도의 테이블을 만듭니다.
    - 이러한 테이블을 연결할 때는 외래 키를 사용합니다.

    제 3 정규형
    - 키에 종속되지 않는 필드를 제거합니다.

    기타 정규형
    BCNF(Boyce Codd Normal Form)라고도 하는 제 4 정규형과 제 5 정규형도 있지만 이 형식은 실제 디자인에서 거의 고려되지 않습니다. 이러한 규칙은 무시해도 데이터베이스 디자인의 완벽성은 덜하겠지만 기능적으로는 영향이 없습니다.

    문제점

    때로는 정규화 이론에 어긋나는 릴레이션 구조를 선택해야 할, 실용적인 필요성이 우선하는 경우도 있습니다. 정규화 작업은 특히 처리속도와의 trade-off관계가 심사숙고의 대상이 되며 고도의 정규화를 추구하다보면 레코드의 종류가 늘어나고 프로그래밍도 복잡해 져서 결국은 전체적인 performance가 떨어지게 됩니다. 이는 양자간의 절충으로 어느정도 해결될 수 있지만 개발자와 사용자간에 깊이 생각해 보아야 할 문제라고 할수 있겠군요.

    From : 아이헬퍼스
    내용출처 : http://database.sarang.net/?inc=read&criteria=dbms&subcrit=columns&aid=862

     

    -----------------------

    예제참고 : http://vtheonev.blog.me/40117422434

     

    SQL튜닝 - 드라이빙 테이블 순서 관련(오라클)


    안녕하세요. 제가 답변을 드려봅니다.
    일반적으로 조인을 할 때, 예를들어 A와 B를 조인할 때 크기가 작은 쪽에서 큰 쪽으로 데이터가 흘러가는게 빠릅니다.

    예를들어 보겠습니다.

    <테이블 EMP>

    NO EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO
    1 7369 SMITH CLERK 7902 1980-12-17 800   20
    2 7499 ALLEN SALESMAN 7698 1981-02-20 1600 300 30
    3 7521 WARD SALESMAN 7698 1981-02-22 1250 500 30
    4 7566 JONES MANAGER 7839 1981-04-02 2975   20
    5 7654 MARTIN SALESMAN 7698 1981-09-28 1250 1400 30
    6 7698 BLAKE MANAGER 7839 1981-05-01 2850   30
    7 7782 CLARK MANAGER 7839 1981-06-09 2450   10
    8 7788 SCOTT ANALYST 7566 1982-12-09 3000   20
    9 7839 KING PRESIDENT   1981-11-17 5000   10
    10 7844 TURNER SALESMAN 7698 1981-09-08 1500.1 0 30
    11 7876 ADAMS CLERK 7788 1983-01-12 1100   20
    12 7900 JAMES CLERK 7698 1981-12-03 950   30
    13 7902 FORD ANALYST 7566 1981-12-03 30001   20
    14 7934 MILLER CLERK 7782 1982-01-23 1300   10


    <테이블 DEPT>
    NO DEPTNO DNAME LOC
    1 10 ACCOUNTING NEW YORK
    2 20 RESEARCH DALLAS
    3 30 SALES CHICAGO
    4 40 OPERATIONS BOSTON


    위에 2개의 테이블이 있는데 나그네님께서 말씀하신 첫번째 쿼리를 보겠습니다.

    SELECT A.EMPNO,
                 B.DEPTNO
    FROM   EMP  A,
                DEPT B
    WHERE  A.DEPTNO = B.DEPTNO
    AND       A.DEPTNO IN (10, 20);

    여기서 보시면 A.DEPTNO IN (10, 20) 으로 인해 A 테이블이 먼저 상수를 받습니다. 그리고 상수화된 DEPTNO를 DEPT 테이블에 넘겨주죠(조인)
    이 과정을 일반적으로 A 테이블이 드라이빙 걸렸다고 하는데요. 이 쿼리가 처리하는 전체 로우수를 보겠습니다.

    참고로 여기서 말씀드리는 로직은 Full Scan을 기준으로 설명드립니다.(Full Scan은 인덱스 없이 테이블 전체를 뒤져보는 로직입니다.)

    /*********************************************************************/
    /* 1. 첫번째 쿼리 분석                                                                         */
    /*********************************************************************/
    A.DEPTNO IN (10, 20) 를 통해 EMP 테이블에 (10, 20)인 데이터를 찾습니다. 그럼 EMP 테이블이 총 14 로우수이기 떄문에 전체를 다 뒤지므로 14가 됩니다. --- ①
    그리고 (10)을 찾아봤더니 3개 로우가 검색되었습니다. --- ②
    이 3개의 로우를 가지고 A.DEPTNO = B.DEPTNO 이 과정을 통해 DEPT 테이블에 (10)이 있는지 찾아봐야겠죠? 만족하는 로우는 1개 이지만 전체를 다 뒤져야 되므로 4번을 찾습니다. --- ③

    그리고 (20)에 대해서도 마찬가지로 ②, ③ 번 과정을 거쳤더니 5번, 4번이 나왔습니다.

    이를 토대로 (10, 20)에 대해 만족하는 로우를 찾기위해 검색한 총 로우수는 14 + (3 * 4) + (5 * 4) = 46 이 됩니다.


    /*********************************************************************/
    /* 2. 두번째 쿼리 분석                                                                         */
    /*********************************************************************/
    이제 두번째를 보도록 하겠습니다.

    SELECT A.EMPNO,
           B.DEPTNO
    FROM   EMP  A,
           DEPT B
    WHERE  A.DEPTNO = B.DEPTNO
    AND    B.DEPTNO IN (10, 20);


    두번째는 EMP부터 상수를 받는게 아니라 B.DEPTNO IN (10, 20) 이것처럼 DEPT부터 상수를 받았네요. 이를 통해 1번에서 했던 과정을 반복해보면 다음과 같은 값이 나옵니다.

    DEPT에서 (10, 20)을 찾기 위해 검색한 총 로우수 : 4
    (10)을 가지고 EMP에서 찾기 위해 검색한 총 로우수 : 1 * 14
    (20)을 가지고 EMP에서 찾기 위해 검색한 총 로우수 : 1 * 14

    -> 4 + (1 * 14) + (1 * 14) = 32 이 됩니다.




    여기서 보셨다시피 상수로 받는 테이블(드라이빙 테이블)이 조회조건에 의해 만들어진 집합 결과가 작은 쪽이 더 유리하다는 것을 알 수 있을 것입니다.
    현재는 EMP와 DEPT테이블에 데이터가 얼마 없어서 첫번째 쿼리와 두번째 쿼리의 응답속도 차이를 별로 못 느끼실테지만 100만건만 넘어가도 확연한 차이를 느끼실 수 있을겁니다.
    더 자세한 내용을 원하시면 '새로쓴 대용량 데이터베이스 솔루션' 책을 사셔서 공부하시면 될 것 같습니다.


    강정식(raxsoft)님이 2007-02-02 17:44:24에 작성한 댓글입니다.
    이 댓글은 2007-02-02 17:51:50에 마지막으로 수정되었습니다.

    출처 : http://database.sarang.net/?inc=read&aid=29631&criteria=oracle&subcrit=&id=&limit=20&keyword=100%B8%B8%B0%C7%B8%B8&page=1