SQL Server 2000 관리

에러 메세지
2006/11/09 22:49:45, Application Error, Error, ID=1000
??? ndmpserver.exe 0.0.0.0 ndmpserver.exe 0.0.0.0 00001eb5

2006/11/09 22:49:51, SQLSERVERAGENT, Error, ID=318
Unable to read local eventlog (reason: システム コールに渡されるデータ領域が小さすぎます。).

해결책
SQL Server エージェント エラー イベント ID が無視できます。 318 が エラーは、ほかのアプリケーションのため、発生します。
SQL Server が実行された場所同じコンピュータで実行されているエラー。 エラーを禁止するには。
他のアプリケーションで発生されたアプリケーション エラーをトラブルシューティングし、解決します。
참고 링크
http://support.microsoft.com/kb/811484/ja


에러 메세지
エラー : 5180、レベル : 22、状態 : 1
無効なフィールド ID 7、データベース 'tempdb' では FCB を開けませんでした。

詳細な情報は、http://go.microsoft.com/fwlink/events.asp の [ヘルプとサポート センター] を参照してください。

참고링크
http://support.microsoft.com/kb/278366/ja

SQL Server 인덱스

http://support.microsoft.com/kb/601427/ko

SQL Server 인덱스
이 문서가 적용되는 제품 보기.
기술 자료 ID : 601427
마지막 검토 : 2004년 3월 4일 목요일
수정 : 1.0
이 문서는 이전에 다음 ID로 출판되었음: KR601427
요약
이 자료는 SQL Server Data와 Index Structure들이 어떻게 물리적으로 디스크 드라이브상에 위치하는지에 대하여 설명합니다.
추가 정보
SQL Server 7.0의 Data page 와 Index page는 모두 8 Kilobytes 크기입니다. SQL Server Data Page들은, Text Data와 Image Data를 제외한, 모든 Data를 포함합니다. Text와 Image 데이터의 경우에는 Text/Image Column과 관련되는 Row를 포함하는 SQL Server Data Page는, Text/Image 데이터를 포함하는 하나 이상의 8-KB page들의 Binary Tree (또는 B-Tree) 구조에 대한 Pointer를 가지고 있게 됩니다.
SQL Server Index에는 두 가지 형태가 있으며, 두 가지 모두 8-KB Index page들로 이루어진 B-Tree 구조입니다. 차이점은 B-Tree 구조의 Leaf Level에 있습니다.

- Clustered Index

Table에는 오직 하나의 Clustered Index만 존재합니다. 1. Clustered Index를 가지고 Key를 검색하여 데이터를 읽어 오게 되면, Clustered Index의 Leaf Level이 Data Page이기 때문에, Pointer jump가 필요 없습니다.
2. Clustered Index의 Leaf Level은 그 Clustered Index를 구성하는 Column들의 순으로 이미 정렬되어 있습니다. Clustered Index의 Leaf Level은 그 Table의 실제 8KB data page들을 포함하기 때문에, 전체 Table의 Row data가 물리적으로 Clustered Index에 의해 결정된 순서대로 디스크 드라이브에 정렬되어 있습니다. 그러므로, Clustered Index의 값에 기반을 두고 Table로부터 많은 양의 Row들을 fetch해 오는 경우에 (적어도 64 KB이상인 경우), Sequential Disk I/O가 사용되기 때문에 I/O Performance 이득을 얻을 수 있습니다. 이것이 많은 수의 Row들을 읽어 오기 위해 Range Scan을 수행하는 Column에 대해 Clustered Index를 선택해야 하는 중요한 이유입니다.

- Nonclustered Index

Nonclustered Index는 어떤 Key값에 근거하여 크기가 큰 SQL Server Table들로부터 선택성이 높은 소수의 Row들을 Fetch해 오는데 유용합니다. Nonclustered Index들은 8-KB Index page들로 이루어진 Binary Tree들입니다. Index Page들의 Binary Tree의 Leaf Level은, 그 Index를 구성하는 Column들의 모든 데이터를 포함합니다. Nonclustered Index가 Key값과 일치하는 정보를 읽어 오는데 사용될 때, Key에 일치하는 데이터를 Index의 Leaf Level에서 찾을 때까지 그 Index B-Tree를 따라가게 됩니다. 만약 그 Table로부터 그 Index의 부분이 아닌 Column들이 필요한 경우에는, Pointer Jump가 발생합니다. 이 Pointer Jump는 디스크상에서 Nonsequential I/O Operation을 필요로 하게 됩니다. 어떤 경우에는, 다른 디스크로부터 데이터를 읽어 올 필요가 있는 경우도 있습니다. 여러 Pointer들이 동일한 8-KB Data Page들로 연결된다면, 그 Page를 Data Cache로 한번만 읽어 오면 되므로, I/O Performance Penalty가 적어집니다. Nonclustered Index를 사용한 검색을 포함하는 SQL Query에 의해 리턴된 각각의 Row에 대해, 한번의 Pointer Jump가 필요합니다. 그러므로, Table로부터 하나 혹은 소수의 Row들을 리턴하는 SQL Query인 경우에 Nonclustered Index가 적합하다는 것입니다. 그리고 많은 수의 Row들을 리턴하는 것이 필요한 Query들의 경우에는 Clustered Index가 더 적합한 것입니다. 좀 더 자세한 정보는 SQL Server Books Online에서 "Nonclustered Index" 를 찾으면 얻을 수 있습니다.

- Covering Indexes

Nonclustered Index에만 해당되는 특별한 경우가 Covering Index입니다. Covering Index는, 어떤 SQL Query를 충족시키는데 필요한 모든 Column들이 포함되는 Nonclustered Index를 의미합니다. Covering Index들은 많은 양의 I/O를 절약할 수 있고, 그러므로 Query의 Performance를 많이 향상시킬 수 있습니다. 그러나, 새로운 Index(그 Index와 관련된 B-Tree Index Structure 유지)를 만들어야 하는 비용을, Covering Index로 얻을 수 있는 I/O Performance 이득과 비교하여 균형을 고려하여 선택해야 합니다. 만약 어떤 Covering Index가 SQL Server상에서 아주 자주 수행되는 Query 또는 여러 Query들의 Performance를 향상시킬 수 있다면 Covering Index를 생성하는 것이 좋습니다.

Covering Index의 예:
1. select col1, col3 from Table1 where col2 = 'value'
2. create Index Indexname1 on Table1 (col2, col1, col3)
또는 1. SQL Server가 Data Page가 아닌 Index Page로부터 필요한 모든 data를 얻을 수 있으므로, SQL Server가 디스크 I/O Operation을 절약할 수 있습니다.
2. 위의 Covering Index는 디스크상에 물리적으로 col2를 기준으로 필요로 하는 모든 데이터를 구성하고 있으므로, 하드 드라이브가 순차적으로 (col2 = 'value') 라는 조건과 관련되는 모든 Index Row들을 리턴할 수 있게 됩니다. 이것이 I/O Performance를 상당히 향상시킬 수 있게 되는 것입니다.

SQL Server Enterprise Manager에서 Create Index Wizard를 사용하여 Index를 생성합니다. SQL Server Enterprise Manager 메뉴 바에서 Tools/Wizards를 선택하고, Database wizard가 나타나도록 Database 옆에 있는 + 아이콘을 클릭한 다음, Create Index Wizard를 더블-클릭합니다.
이 예에서 만들어진 "indexname1" 이라는 Index는, select문의 모든 Column들과 WHERE 조건을 포함하기 때문에 Covering Index가 됩니다. 이것은, 이 Query를 수행할 때 SQL Server가 Table1과 관련되는 Data Page들을 액세스할 필요가 없으며, 그 Query를 충족하는데 필요로 하는 모든 정보를 Indexname1이라는 Index로부터 얻을 수 있다는 것을 의미합니다. SQL Server가 Indexname1과 관련되는 B-Tree를 traverse해서 col2가 "value" 와 동일한 Index Key들의 range를 찾기만 하면, SQL Server가 그 covering Index의 Leaf Level로부터 필요한 모든 데이터 (col1, col2, col3)를 Fetch해 올 수 있다는 것을 알게 됩니다. 이는 두 가지 측면에서 I/O Performance 향상을 제공해 줍니다.
일반적으로 그 Table의 한 Row의 Byte수에 비하여 covering Index의 모든 Column들의 Byte수를 합한 것이 작고, Covered Index를 이용하는 Query가 자주 수행되는 것이 확실한 경우에는 Covering Index를 사용하는 것이 합리적입니다.
그러나, 많은 Covered Index들을 만들기 전에 다음 내용을 참고할 것을 권장합니다.

- Automatic Covering Indexes 또는 Covered Queryies

SQL Server 7.0의 새로운 Query Processor는 Index Intersection을 제공합니다. Index Intersection은 Query Processor로 하여금 주어진 Table로부터 여러 개의 Index들을 고려하여 여러 Index들에 기반을 둔 Hash Table을 구축하고, Hash Table을 사용하여 주어진 Query에 대해서 I/O를 감소시킬 수 있도록 해 줍니다. Index Intersection으로부터 나온 Hash Table은 하나의 Covering Index를 가지게 되고, Covering Index가 하는 것과 동일한 I/O Performance 혜택을 제공합니다. Index Intersection은 Database에 대하여 수행될 모든 Query들을 미리 결정하는 것이 어려운 경우에 많은 유연성을 제공해 줍니다.

이 경우에 따라야 할 좋은 전략은, 자주 Query되는 모든 Column들에 대해서 단일 Column, Nonclustered Index들을 정의하고, Covered Index가 필요한 경우에는 Index Intersection으로 하여금 처리하도록 하는 것입니다.
추가정보를 얻으려면, SQL Server Books Online에서 "query tuning recommendations" 와 "designing an Index"를 찾으면 됩니다.

Index intersection을 이용하는 예:
1. select col3 from Table1 where col2 = 'value'
2. Create Index Indexname1 on Table1(col2)
3. Create Index Indexname2 on Table1(col3)
위의 예에서 "indexname1" 과 "indexname2" 은 "table1" 이라는 SQL Server Table에 만들어진 Nonclustered, single- Column Index들입니다. 그 Query가 수행될 때, Query processor가 Index Intersection을 사용하는 것이 유용할 것이라는 상황을 인식합니다. Query Optimizer는 그 Query를 수행하는데 있어서 I/O을 절약하기 위하여 자동적으로 두개의 Index들을 함께 Hashing합니다. 이러한 상황이 발생하는 데에는 Query Hint가 전혀 필요 없습니다. Covering Index들 (선언된 covered Index이건 Index intersection에 의한 것이건)에 의해 처리되는 Query들은 "covered queries" 라고도 합니다.

- Index 선택

Index를 잘 선택하는 것이 디스크 I/O에 가장 큰 영향을 미치게 되므로, 결국 Performance 향상에 있어서 가장 중요한 요소가 됩니다. 이전에 왜 Nonclustered Index가 적은 수의 Row들을 읽어 오는 데 적합하고, Clustered Index가 Range-Scan에 적합한지를 설명했다.

Index를 설정할 때에는 가능한 한 적은 수의 Column들에 대하여, 그리고 Index 길이를 가능한 한 짧게 만들어 주는 것이 좋습니다. 특히 SQL 7.0 의 경우에는, Nonclustered Index 가 Row 데이터 위치정보로서 Clustered Index를 사용하기 때문에, Clustered Index의 바이트 길이를 짧게 만드는 것이 좋습니다.
Nonclustered Index의 경우에는, 선택성(selectivity) 을 고려해야 합니다. 크기가 큰 Table에 대해서 적은 종류의 data 를 가지는 Column 인 경우에 Nonclustered Index를 만들어 주는 것은 I/O를 감소시키는 데 있어서 비효율적입니다. 어떤 경우에는 Index를 사용하는 것이 sequential Table scan 을 수행하는 것보다 I/O를 증가하도록 할 수도 있습니다. Nonclustered Index 의 좋은 예로는 회사의 사번, 주민등록번호, 고객번호, 전화번호 등을 들 수 있습니다.
Clustered Index 는 실제적으로 Table 데이터를 정렬하여 저장하기 때문에, Nonclustered Index에 비해, 유일한 값의 종류가 많지 않은 Column에 대해서 Range Query를 수행하는 경우에 효과적입니다. 예를 들어, 회사지사, 판매날짜 등을 들 수 있습니다. Clustered Index를 어떤 Column에 대해서 만들 때에는, "그 Column의 순서에 의거하여 많은 수의 Row들을 Fetch하는 Query문들이 많은가" 라는 분석을 해야 합니다.

Clustered Index를 사용하는 것이 효과적인 유형의 Query문들:
WHERE < Column_name> > some_value
WHERE < Column_name> BETWEEN some_value AND some_value
WHERE < Column_name> < some_value

Clustered Index 선택, Sequential Key Data, Hot Spot을 보는 방법:

Clustered Index 선택은 두 가지 주요한 결정을 포함합니다: 1. 그 Table의 어느 Column이, Range Scan을 위해 순차적인 I/O를 제공하는 측면에서 Clustered Index를 만들면 가장 혜택을 받을 수 있는지를 결정합니다.
2. Hot Spot을 피하면서 Table 데이터의 물리적인 위치에 영향을 주기 위해 Clustered Index를 사용하는 것입니다.
Hot Spot은 많은 Query들이 동시에 동일한 영역의 디스크에 데이터를 읽거나 쓰려고 하는 경우에 발생합니다. 이는 하드 디스크가 동시에 처리할 수 있는 것보다 많은 디스크 I/O 요청들을 받게 되기 때문에, 디스크 I/O 병목현상(Bottleneck)을 유발하게 됩니다.

- FILLFACTOR와 PAD_INDEX의 중요성

만약 많은 양의 Insert 작업이 발생하는 경우라면, Page 분할(Splitting)을 방지하기 위하여 Index Page에 여분의 공간을 확보하는 것이 필요합니다. Page Splitting 은 Index Page나 Data Page에 새로 추가될 Row를 수용할 공간이 없어서, SQL Server가 새로운 Page를 할당해서 기존 Page에 있던 데이터들을 두개의 Page에 나누는 작업을 하는 것을 말하는 것으로서, 이러한 작업은 System 자원과 시간을 낭비하는 요인이 됩니다.
그러므로, Index를 만들 때 fillfactor와 pad_index 설정을 고려하는 것이 필요합니다. CREATE INDEX와 DBCC REINDEX 문의 FILLFACTOR 옵션을 사용하면 Index Page와 Data Page에 여분의 공간을 확보할 수 있습니다.
Performance Monitor에서 "SQL Server: Access Methods - Page Splits." 값을 주기적으로 관찰하여 0보다 큰 값이 발견되면, Page 분할이 발생하는 것이므로 DBCC SHOWCONTIG를 사용하여 자세하게 분석하는 것이 필요합니다.
과도한 Page 분할이 Table에서 발생하면, Index를 다시 생성해 주는 작업을 수행해 줄 것을 권장합니다.

oracle tip

lsnrctl status

alter session set cursor_sharing=FORCE;
alter session set cursor_sharing=EXACT;

select * from v$session where type= 'USER'
alter system kill session '331,6631'

터미널에서 에러코드 확인
[xxx:/oracle/OraHome1] oerr ora 07445

UTF8과 AL32UTF8의 차이점
UTF8은 유니코드 3.0 까지만 지원 하고 오라클에서도 더이상 개발하고 있지 않음
AL32UTF8은10g의 경우 유니코드 4.0 까지 지원 하며 계속 업데이트 중임

DB 문자셋 변경

MS SQL서버 디비별 문자셋 변경 방법
참고
http://ssw.com.au/SSW/KB/KB.aspx?KBID=Q711843

우선 디비 생성 스크립트 스키마 테이블 유저 제약 관련 스크립트 익스포트

1. 디비가 사용중인지 아닌지 Check 사용중인 sid kill
sp_who
kill 55

2.디비 detach
sp_detach_db @dbname='TDE_GM'

3.데이터 파일과 로그 파일명 변경
TDE_GM_Data.MDF
TDE_GM_Data.LDF
에 OLD를 붙여서 변경 후 새로운 디비 이름으로 attach

EXEC sp_attach_db
@dbname = N'TDE_GMOLD',
@filename1 = N'E:SqlDataMSSQLDataTDE_GM_DataOLD.MDF',
@filename2 = N'E:SqlDataMSSQLDataTDE_GM_LogOLD.LDF'


4.위에서 익스포트한 스크립트에 문자셋 관련부분 변경후
디비 생성

5.DTS로 데이터 COPY

생각보다는 간단한작업..

MSSQL 일본어 설정

http://www.kawabata.com/yoshihiro/blog/PermaLink.aspx/cf14534f-ff6e-4123-8946-8205986f7665
の内容

照合順序の指定
SQL Server の 照合順序のオプションを簡単にまとめました


CI
大文字、小文字を区別しない。全角アルファベットの大文字、小文字も区別しない
例: 「A」 と 「a」 を同一視する
CS
大文字、小文字を区別する。全角アルファベットの大文字、小文字も区別する
例: 「A」 と 「a」 を区別する
AI
アクセント、濁音、破裂音を区別しない。
半角カナの濁音、破裂音も区別しない
例: 「ハ」、「バ」、「パ」を区別しない
AS
アクセント、濁音、破裂音を区別する。
例: 「ハ」、「バ」、「パ」を区別する
KS
ひらがなとカタカナを区別する。半角でも区別する
KS に対して、KI という指定はない
例: 「は」と「ハ」を区別する
WS
文字幅を区別する。つまり全角、半角を区別する。
WS に対して、WI という指定はない
例: 「a」と「ａ」を区別する
BIN
バイナリで比較する。つまりすべて区別する。
指定書式
書式: Japanese_BIN
書式: Japanese_(CI | CS)_(AI | AS)[(_KS | _WS | _KS_WS)]
例: Japanese_BIN
例: Japanese_CI_AS_KS

exp/imp

리눅스 포털에서 퍼온 내용입니다.
오늘 개발 서버에 리얼서버 데이터를 퍼올일이 있어서..
10g부터 적용되는 dbpump를 적용해 봤는데..
expdp는 잘되는데 impdp가 잘 않되서...(데이터 갱신이 않됬음.로그는 문제가 없었는데.....)
그리고 database link를 테스트 해 봤는데..
10g부터는 권한 관련 부분이 변화가 있었는지 잘 않되서...음...
결국은 exp/imp...

http://www.superuser.co.kr/home/superuserboard/view.html?id=361&code=oracle&start=450&position=

import, export사용(imp, exp)

linux라는 사용자로 연결한다
SQL> connect linux/linux
연결되었습니다.
SQL> set pagesize 30

linux가 가진 테이블은 다음과 같다
SQL> select * from tab;
TNAME TABTYPE CLUSTERID
------------------------------ ------- ----------
S_CUSTOMER TABLE
S_DEPT TABLE
S_EMP TABLE
S_IMAGE TABLE
S_INVENTORY TABLE
S_ITEM TABLE
S_LONGTEXT TABLE
S_ORD TABLE
S_PRODUCT TABLE
S_REGION TABLE
S_TITLE TABLE
S_WAREHOUSE TABLE
TEST TABLE
13 개의 행이 선택되었습니다.
SQL> quit
Oracle8 Release 8.0.5.0.0 - Production
PL/SQL Release 8.0.5.0.0 - Production에서 분리되었습니다.
[linux@localhost db]$ ls -l /usr/local/Oracle
total 2
drwxr-xr-x 3 oracle dba 1024 Sep 22 13:23 app
drwxr-xr-x 3 oracle dba 1024 Sep 22 13:26 oradata
[linux@localhost db]$ ls -l /usr/local/Oracle/oradata
total 1
drwxr-xr-x 2 oracle dba 1024 Sep 22 13:34 kang
[linux@localhost db]$ ls -l /usr/local/Oracle/oradata/kang
total 131172
-rw-r----- 1 oracle dba 1435648 Oct 5 23:46 control01.ctl
-rw-r----- 1 oracle dba 1435648 Oct 5 23:46 control02.ctl
-rw-r----- 1 oracle dba 1435648 Oct 5 23:46 control03.ctl
-rw-r----- 1 oracle dba 15730688 Oct 5 23:44 rbs01.dbf
-rw-r----- 1 oracle dba 512512 Oct 5 23:41 redokang01.log
-rw-r----- 1 oracle dba 512512 Oct 5 23:42 redokang02.log
-rw-r----- 1 oracle dba 512512 Oct 5 23:44 redokang03.log
-rw-r----- 1 oracle dba 83888128 Oct 5 23:44 system01.dbf
-rw-r----- 1 oracle dba 1050624 Oct 5 23:42 temp01.dbf
-rw-r----- 1 oracle dba 26216448 Oct 5 23:42 tools01.dbf
-rw-r----- 1 oracle dba 1050624 Oct 5 23:42 users01.dbf

linux의 테이블을 export한다. OCP에서는 이 툴을 이용하는 백업을 논리적(logical) 백업이라고 한다
그냥 명령인자없이 주면 interactive하게 진행할 수 있다.
이 경우 direct백업(특별한 경우가 아닌 이상, 이 방법으로 하면 속도가 빨라진다.)이 불가능하다(디폴트로 N)
[linux@localhost db]$ exp linux/linux
Export: Release 8.0.5.0.0 - Production on 화 Oct 5 23:46:43 1999
(c) Copyright 1998 Oracle Corporation. All rights reserved.

연결할 곳: Oracle8 Release 8.0.5.0.0 - Production
PL/SQL Release 8.0.5.0.0 - Production
배열 인출 버퍼 크기 입력: 4096 >
엑스포트 파일: expdat.dmp > 그냥 엔터(디폴트 화일명은 expdat.dmp이다)

논리적 백업은 3가지가 있는데 아래에 있는 user, table과 아래에 나오지 않은 full백업이 있다
(full백업은 보통 dba만이 할 수 있다, 만일 백업만을 전담할 사용자를 둔다면, exp_full_database, imp_full_database 권한을 주면 된다.).
user는 사용자가 가진 스키마의 모든 것들을 export하는 것이고, table은 말 그대로 사용자의 지정된 table만을 export하는 것이다.
full은 전체 DB를 백업한다


(2)U(사용자), 또는 (3)T(테이블): (2)U > 여기서는 2을 선택했다
권한부여 엑스포트 (yes/no): yes > 그냥 엔터
테이블 데이터 엑스포트 (yes/no): yes > 그냥 엔터
확장 영역 압축 (yes/no): yes > 그냥 엔터
KO16KSC5601 문자 설정과 KO16KSC5601 NCHAR 문자 설정에서 엑스포트가 종료되었습니다
. LINUX 사용자를 위해 외래 함수 라이브러리 이름을 엑스포트합니다
. LINUX 사용자에 대한 개체 유형 정의를 엑스포트 합니다
LINUX의 개체를 엑스포트하려고 합니다 ...
. 데이터베이스 링크 엑스포트 중
. 순차 번호 엑스포트 중
. 클러스터 정의 엑스포트 중
. LINUX의 테이블을 엑스포트하려고 합니다 via 규정 경로...
. . 테이블 S_CUSTOMER(를)을 엑스포트 중 15 행이 엑스포트됨
. . 테이블 S_DEPT(를)을 엑스포트 중 12 행이 엑스포트됨
. . 테이블 S_EMP(를)을 엑스포트 중 25 행이 엑스포트됨
. . 테이블 S_IMAGE(를)을 엑스포트 중 19 행이 엑스포트됨
. . 테이블 S_INVENTORY(를)을 엑스포트 중 114 행이 엑스포트됨
. . 테이블 S_ITEM(를)을 엑스포트 중 62 행이 엑스포트됨
. . 테이블 S_LONGTEXT(를)을 엑스포트 중 33 행이 엑스포트됨
. . 테이블 S_ORD(를)을 엑스포트 중 16 행이 엑스포트됨
. . 테이블 S_PRODUCT(를)을 엑스포트 중 33 행이 엑스포트됨
. . 테이블 S_REGION(를)을 엑스포트 중 5 행이 엑스포트됨
. . 테이블 S_TITLE(를)을 엑스포트 중 8 행이 엑스포트됨
. . 테이블 S_WAREHOUSE(를)을 엑스포트 중 5 행이 엑스포트됨
. . 테이블 TEST(를)을 엑스포트 중 16 행이 엑스포트됨
. 동의어 엑스포트 중
. 뷰 엑스포트 중
. 저장 프로시저 엑스포트 중
. 참조 무결성 제약조건 엑스포트 중
. 트리거 엑스포트 중
. 이후 테이블 처리를 엑스포트 중
. 스냅샷 엑스포트 중
. 스냅샷 로그 엑스포트 중
. 작업 대기열을 엑스포트 중
. 리프레쉬 그룹과 자식 엑스포트 중
엑스포트가 경고 없이 정상적으로 종료되었습니다.
[linux@localhost db]$ ls -l
total 96
-rw-rw-r-- 1 linux linux 3340 Aug 15 22:30 JdbcTest.class
-rw-r--r-- 1 linux linux 3112 Aug 15 22:43 JdbcTest.java
drwxrwxr-x 2 linux linux 1024 Oct 1 01:10 db_ex
-rw-rw-r-- 1 linux linux 40960 Oct 5 23:46 expdat.dmp
-rw-r--r-- 1 linux linux 41841 Jun 30 11:59 summit.sql
-rw-rw-r-- 1 linux linux 4096 Oct 5 23:46 사용자관리-백업_리스토어.txt

kang이라는 사용자로 import를 수행한다.
[linux@localhost db]$ imp kang/kang
Import: Release 8.0.5.0.0 - Production on 화 Oct 5 23:48:1 1999
(c) Copyright 1998 Oracle Corporation. All rights reserved.

연결할곳: Oracle8 Release 8.0.5.0.0 - Production
PL/SQL Release 8.0.5.0.0 - Production
임포트 파일: expdat.dmp >
삽입 버퍼 크기를 입력하십시오 (최소치는 4096) 30720>
엑스포트 파일은 규정 경로를 거쳐 EXPORT:V08.00.05 에 의해 생성되었습니다
경고: 개체는 다른 사용자 LINUX(이)가 엑스포트한 것입니다.
임포트 파일의 내용만 표시합니다. (yes/no): no >
개체 존재로 인해 발생한 생성 오류는 무시합니다. (yes/no): no >
권한부여 임포트 (yes/no): yes >
테이블 데이터 임포트 (yes/no): yes >
엑스포트 파일 전체를 임포트합니다. (yes/no): no >
사용자명:linux 여기서 kang이라고 입력하지 않도록 주의한다
테이블(T) 또는 분할(T:P)명을 입력하십시오. 널 목록은 사용자의 모든 테이블을 의미합니다.
테이블(T) 또는 분할(T:P)명을 입력하거나 완료 시에는 .을 입력하십시오.
. LINUX 개체를 KANG(으)로 임포트하는 중입니다.
. . 테이블 "S_CUSTOMER"(를)을 임포트 중 15 행이 임포트되었습니다
. . 테이블 "S_DEPT"(를)을 임포트 중 12 행이 임포트되었습니다
. . 테이블 "S_EMP"(를)을 임포트 중 25 행이 임포트되었습니다
. . 테이블 "S_IMAGE"(를)을 임포트 중 19 행이 임포트되었습니다
. . 테이블 "S_INVENTORY"(를)을 임포트 중 114 행이 임포트되었습니다
. . 테이블 "S_ITEM"(를)을 임포트 중 62 행이 임포트되었습니다
. . 테이블 "S_LONGTEXT"(를)을 임포트 중 33 행이 임포트되었습니다
. . 테이블 "S_ORD"(를)을 임포트 중 16 행이 임포트되었습니다
. . 테이블 "S_PRODUCT"(를)을 임포트 중 33 행이 임포트되었습니다
. . 테이블 "S_REGION"(를)을 임포트 중 5 행이 임포트되었습니다
. . 테이블 "S_TITLE"(를)을 임포트 중 8 행이 임포트되었습니다
. . 테이블 "S_WAREHOUSE"(를)을 임포트 중 5 행이 임포트되었습니다
. . 테이블 "TEST"(를)을 임포트 중 16 행이 임포트되었습니다
사용 가능한 제약 조건에 관해서...
임포트가 경고 없이 정상적으로 종료되었습니다.
[linux@localhost db]$ sqlplus
SQL*Plus: Release 8.0.5.0.0 - Production on 화 Oct 5 23:48:37 1999
(c) Copyright 1998 Oracle Corporation. All rights reserved.
사용자명 입력: kang
암호 입력:
Connected to:
Oracle8 Release 8.0.5.0.0 - Production
PL/SQL Release 8.0.5.0.0 - Production

정말 import가 되었는지 확인하자
SQL> select * from tab;
TNAME TABTYPE CLUSTERID
------------------------------ ------- ----------
S_CUSTOMER TABLE
S_DEPT TABLE
S_EMP TABLE
S_IMAGE TABLE
S_INVENTORY TABLE
S_ITEM TABLE
S_LONGTEXT TABLE
S_ORD TABLE
S_PRODUCT TABLE
S_REGION TABLE
S_TITLE TABLE
S_WAREHOUSE TABLE
TEST TABLE
13 개의 행이 선택되었습니다.


다시 system으로 접속해서 kang이라는 사용자를 지운다.
이때 kang이라는 사용자의 schema에는 테이블이 존재하므로 cascade옵션을 사용해야 한다

SQL> connect system
암호 입력:
연결되었습니다.
SQL> drop user kang;
drop user kang
*
1행에 오류:
ORA-01922: 'KANG'(을)를 삭제하려면 CASCADE를 지정하여야 합니다

SQL> drop user kang cascade;
사용자가 삭제되었습니다.

추가: 2001-12-20
imp에서 show패러미터는 export파일의 내용을 보여주고, 실제 import는 수행하지 않는다.
보여주는 내용이 SQL문으로 되어 있으므로 어떤 경우, 유용하게 사용될 수 있다.

imp system/xxxxxx full=y show=y file=full_20011220.dmp log=exp_content.sql


복구과정
1. 가장 최근의 exp파일에서 full=y inctype=system으로 imp를 수행하여 data dictionary와 DB구조들을 재생성
(이때 적용될 exp파일은 complete, cumulative, incremental의 종류에 관계없이 가장 최근의 exp파일이다.)
2. 가장 최근의 complete exp파일에서 full=y inctype=restore로 import한다.
(나머지 exp파일들에 대해 full=y와 inctype=restore로 계속 수행한다)
3. 가장 최근의 complete exp파일 이후로 수행된 cumulative exp파일들을 처리
4. 가장 최근의 cumulative exp파일 이후로 수행된 incremental exp파일들을 처리

export시 DB를 restricted session에 두고,(alter system enable restricted session)
exp 패러미터중 consistent를 Y에 두면 최소한의 읽기일관성 보장한다.
단, consistent패러미터는 complete, cumulative에서만 사용할 수 있다.
consistent패러미터는 incremental에서는 사용될 수 없으므로, incremental수행시에는
DB를 restricted session에 두고 수행하는 것이 좋다.


-- 읽기일관성 문제 예
테이블 데이터가 먼저 export되고, index는 그 다음에 수행된다.
따라서, 테이블데이터에 있지 않으나, 인덱스에는 해당 데이터가 있을 수도 있다.
export수행중, 변경된 데이터는 export파일에 저장되지 않는다.


conventional Vs direct
디폴트는 conventional path를 이용해 export된다.
conventional path는 SQL을 SQL*PLUS에서 수행하는 것과 동일한 방식으로 실행된다.
direct패러미터는 디폴트가 N이므로 명시적으로 Y값으로 설정해야 한다.
direct는 데이터 정의와 몇몇 SQL을 skip하여 수행되므로 백업의 속도가 빠르다.
direct path를 사용할 때는 buffer패러미터가 사용되지 않는다.


full=y로 수행된 export파일은 import시 user,table,full 모두에 사용될 수 있다

DB Link 관련

DBA 택이 님 페이지 에서 퍼온 내용입니다.

http://blog.naver.com/taek78?Redirect=Log&logNo=40024448851

먼저 oraA, oraB 의 서비스네임을 가진 데이타베이스 2개가 있다고 하자.

그리고 oraA 에서 oraB 의 데이타를 보려고 한다.

간단하게 설명하면 아래의 절차와 같다.

1 oraA 에서 oraB 로 접속 가능하게 설정한다.
2 oraA 에서 oraB 로 접속해본다.
3 oraA 에서 db link 를 만든다.
4 만든 db_link 로 테이블을 select 해본다.




1. oraA 서버상에 상대 오라클 서버(oraB)를 등록한다.

% vi $ORACLE_HOME/network/admin/tnsnames.ora 파일에 등록함 (oraA)



oraB =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = oraB의 ip 또는 host name )(PORT = 포트번호))
)
(CONNECT_DATA =
(SERVICE_NAME 또는 SID = remote SID)



2. 일단 접속해본다.

% sqlplus /@oraB

접속이 되면 빠져나온다.



3. DB Link 를 사용할 오라클 계정(oraA)으로 sqlplus에 로그인하고 다음과 같이 DB Link를 생성한다.

SQL> create database link <링크로사용할이름> connect to identified by using 'oraB(상대 서비스 네임)';



4. 잘 만들어 졌는지 확인

SQL> select * from tab@<링크이름>
oraB의 테이블정보와 일치하면 성공.


5. drop Database link 방법

잘못 만들었다면 지우고 다시 만든다.

SQL> drop database link <링크이름>;

6. Database link 현황 보기

SQL> select * from all_db_links;

SQL> select * from dba_db_links;



7. TNS-03505 에러 발생시

oraA와 oraB의$ORACLE_HOME/network/admin/sqlnet.ora 비교하여 NAMES.DIRECTORY_PATH= 의 값이 동일한지 확인