일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
Tags
- 시그널
- 파일시스템
- pgpool-ii
- postfix
- 리눅스
- PERL
- php-oracle 연동
- ext3
- pgbench
- Nexenta
- LVS
- 펄
- ZFS
- pgsql
- Openfiler
- Replication
- CVSROOT 세팅
- connection tunning
- OCFS2
- clustering
- 펄 코딩스타일
- mailfiler
- 오라클
- inotify
- perltidy
- 가상파일시스템
- 포기해버린꿈
- pvfs
- tomcat
- ext4
Archives
- Today
- Total
avicom의 신변잡기
인덱스 dbf 파일을 지웠을 때 조치법 본문
조치법이라고 할 수도 없지만,
제약조건이 걸린 테이블에 묶인 인덱스 dbf 파일을 지워버렸을 경우엔 인덱스를 다른 테이블스페이스로 옮길 수도, 삭제할 수도 없다
이번 건은 실로 멍청한 실수라고 하겠지만 테스트 DB여서 다행..ㅋㅋ
인덱스 정보를 담고있는 실제 파일이 삭제되고, 백업도 없는 상황에선 해당 테이블을 지우는 수밖에 없다.
constraints가 이리저리 얽힌 경우에 마이그레이션을 하기 위해서는 일단 원본에서 rows만 뽑아낸 다음 target tablespace에 table scheme를 만들고 data만 insert한 후에 relation을 맺는 게 상책인 듯..
그냥 exp/imp를 하게 되면 테이블에 걸린 제약조건으로 인해 제대로 imp가 되지않을 수도 있다.
제약조건이 걸린 테이블에 묶인 인덱스 dbf 파일을 지워버렸을 경우엔 인덱스를 다른 테이블스페이스로 옮길 수도, 삭제할 수도 없다
이번 건은 실로 멍청한 실수라고 하겠지만 테스트 DB여서 다행..ㅋㅋ
인덱스 정보를 담고있는 실제 파일이 삭제되고, 백업도 없는 상황에선 해당 테이블을 지우는 수밖에 없다.
constraints가 이리저리 얽힌 경우에 마이그레이션을 하기 위해서는 일단 원본에서 rows만 뽑아낸 다음 target tablespace에 table scheme를 만들고 data만 insert한 후에 relation을 맺는 게 상책인 듯..
그냥 exp/imp를 하게 되면 테이블에 걸린 제약조건으로 인해 제대로 imp가 되지않을 수도 있다.