database.sarang.net
UserID
Passwd
Database
DBMS
MySQL
PostgreSQL
Firebird
Oracle
Informix
ㆍSybase
MS-SQL
DB2
Cache
CUBRID
LDAP
ALTIBASE
Tibero
DB 문서들
스터디
Community
공지사항
자유게시판
구인|구직
DSN 갤러리
도움주신분들
Admin
운영게시판
최근게시물
Sybase Q&A 1726 게시물 읽기
No. 1726
대량 데이터 작업시
작성자
이은영(eunylee)
작성일
2006-11-15 16:27
조회수
9,230

insert 시.. dbms는 어떤 동작을 하나요?


대량(천만에서 2천만)의 건수를 작업할건데요...뭐 당연히 중간에 commit을 할거임으로 logsegment 같은게 full 나거나 하지 않겠죠??


그외 대량 건수 작업시 뭘 또 주의해야할까요??


그리고 작업은 아래와 같이 할건데. 효율적인 방법이 맞을까요?


A라는 테이블에 기존 data지우구 부을거랍니다


그래서 A의 스키마와 같은 B를 만들구..이때 B는 index는 추가로 만들지 않고 pk a만 생성해서 pk index만 만들구요 그 B테이블에 insert작업을 해주구 ( 1000건 단위로 commit)  그 후에  A를 drop하고 B를 rename해준 후 index를 생성해주려 합니다.


괜찮을까요??


조언좀 부탁드려여

이 글에 대한 댓글이 총 5건 있습니다.

Hello,
Sorry for replying back in English but i do not have access to the Korean fonts right now.  If you like me to translate this, i'll be more than happy to do so sometime later.  Please let me know...

it seems to me that this is a one time change you are planning to make... 

Although your plan should work, here is something else to consider....

you can use view and bcp to control
1) size of the transaction
2) performance

The technique is typically used by the shops with large tables/minimal log space.

process-
1) create a view to convert necessary data to fit your new table structure.
2) create new table with indexes. (will cause slow bcp)
3) bcp the data out from the view
4) bcp the data in using -b flag to control the size of your transaction.
5) drop the old table.  -> This is must.  if you rename the original table, you can break the SYBASE Query Tree.  Please, do not be confused with the Query Plan.
6) run update statistics/update index statistics
7) run sp_recompile table_name

한임경(SPID)님이 2006-11-16 04:37에 작성한 댓글입니다.
이 댓글은 2006-11-16 06:15에 마지막으로 수정되었습니다.

1. 대량의 데이타 insert


우선 bcp로 하시는게 더 빠를거구요


fast bcp 하시려면 db option이 'select into'로 설정되어야 하고


index나 trigger이 없어야 합니다


bcp in하시고 index를 만드시는게 좋습니다.


안된다면 unique index만 나두시고 insert후에 다른 index를 만드시는게


효과적입니다



2. 다른 테이블로 옮기시는 작업


pk를 만드신다는 것도 (default로 unique index가 생깁니다)


그러므로 pk 만드시지 마시고 insert하시고


(컬럼에 다른 속성이 없으면 select * into 가 더 빠릅니다)


insert한후에 alter table로 pk를 잡아주시는 것이 좋습니다.



이것도 bcp 가 좋겠죠...위의 예처럼




그리고 드롭하기 전에 관련된 procedure나 trigger을 다시 생성해야합니다



위의 분처럼 sp_recompile table_name해도 효과가 없습니다



이건 query plan만 다시 만드는 겁니다.




그러므로 drop 후에 다시 procedure나 trigger을 생성해주어야 합니다


(참조하는게 objectid를 참조 하기 때문입니다)



그리고 index를 나중에 만드는 경우는 update statistics를 하실 필요가 없지요

지연님이 2006-11-16 09:04에 작성한 댓글입니다. Edit

안녕하세요~ :)

지연님께서 말씀하신 objectid 를 참조한다는걷은 재가 5 번에서 설명한거갇은데요 .... 아마재가 설명을 잘 뫃한것갇내요 ... 두분깨 죄송합니다 ....

5) drop the old table.  -> This is must.  if you rename the original table, you can break the SYBASE Query Tree.  Please, do not be confused with the Query Plan.

이은영씨깨다시 설명들이갯읍니다 ... 설명들이기전에 ... 벌써아시갯지만 ...제가 한국말 쓰는게 많이 서투름니다 ... 사람들도 도와줄겸 한국말쓰는것도 배울겸 ... 겸사겸사 들왔으니 이해혀주십시요... ^^

지연님께서 말한 "objectid 참조'를 영어로 "query tree" 라합니다 ...  
다시말하지만 이걷은 "query plan" 이 절데아닙니다 ...

"query tree"를 망가트리지않을려면 두가지 방법이 있읍니다.

하나는 은영씨께서 plan 하신데로 전 테이블을 drop 하는것입니다...
관련된 procedure나 trigger 을 다시 생성할필요는없읍니다.
SYBASE 가 알아서 re-resolve 합니다....

둘째는 전 테이블을 drop 안할경우 ...
지연님이 말씀하신데로 꼭 괄련된 SP 와 trigger 을 다시 생선하셔야합니다.

그리고 지연님깨서 말씀하신데로 sp_recompile 는 query plan 만 다시만드는걷이지요...재가 sp_recompile 를하라한것은 DBA 들이 index 를 create 하거나, reorg rebuild 아님 테이블 statistics 이 바낄경우에 항상 쓰는 "best practice" 라할까요 ....많약 SP 안에 "with recompile" option 을 ase server 전채적으로쓰실경우에는 sp_recompile 를 쓰실필요가 없으십니다....

참고로 FAST BCP 를 쓰실생각이있으시면 ... 조심하십시요 ..
test server 들은 주로 "trunc log on checkpoint" 가 set 되있어서 아무문재업이 쓰실수있으시나 ..
production server 갇은경우에는 option 이 off 되어있기때문에 select into 나 index 가 업는 테이블로 bcp 를하실경우 "non-logged transaction"이발생하여 transaction dump 를뫃하고 꼭 database dump를 하셔야만됩니다 ...

재가 설명을 잘뫃햇다면 .. 다시한번 죄송한말씀을 드립니다 ....


 

한임경(SPID)님이 2006-11-16 12:46에 작성한 댓글입니다.
이 댓글은 2006-11-16 13:01에 마지막으로 수정되었습니다.

table을 rename하시건 drop을 하시건

다시 tri와 sp를 만드셔야 합니다.


rename을 하시고 table을 create하시거나

또는 새로 table을 만들어도

objectid가 같지가 않습니다.


한번 만들어진 query tree는 (syntax check등의 파싱만한)

파싱시의 objectid를 참조하기 때문에 무조건 다시 만들어야 합니다


그리고 dump는 위의 분 말씀이 맞습니다


log를 안남기므로 반드시 dump database를 먼저 수행해야

dump tran이 됩니다~~


위의분 이정도면 한국말 잘하시는거 같은데요~~



드디어 sybase q&a를 다른 나라에서도 보시는 군요~

지연님이 2006-11-16 19:41에 작성한 댓글입니다.
이 댓글은 2006-11-16 19:52에 마지막으로 수정되었습니다. Edit

안녕하세요 ^^ 예~... 또접니다 ..

한국말도 뫃쓰면서 ... 재가 쫌끈질기넘입니다 ... ㅎㅎ

그래도 위에 잘쓴다해주시니 기븐이 좋내용~~


지연님깨서 재가하는말이 맛지만 다시만드는게더좋타하면 재가동이햇갯지만.... 무조건다시만들어야만한다는 말에 이글을남김니다 ..그러고보묜 저도 똑갓이 우겨대긴햇지만.... 않해도 된다고요...


해서 이글을 읽으시는 분들이 햇갈리지않케...다시말하갯읍니다 ..


재가 re-resolve 한다는 뜻은 다른말로 (영어로) Query Tree 를 Resolution 한다는말입니다.  Resolution 이라는 말은 미국 SYBASE 본사에서도 쓰는말이며... 미국 SYBASE solve case "10893576" 도 설명되어있는말입니다 .. 


Building the Query Tree: Resolution


The process of building a query tree is called resolution. This process parses

the SQL into a more efficient format and resolves all objects involved into their

internal representations. For example, table names are resolved into their object

IDs and column names are resolved into their column IDs.


#1 The procedure does not re-resolve when a table it references is renamed. The procedure will continue to return the data from the old table since the query tree points to the table based on object id.


#2 When a new table (with a new object id) is created using the original table name, the procedure still references the renamed table since it is using object id.


#3 When the old table is dropped, the object id to which the query tree pointed no longer exists. This forces the procedure to be re-resolved and the query tree will then point to the new object id.


The procedure is automatically re-resolved when the old table is dropped.




SYBASE 가 테이블을 (object id) 찾지뫃할시에는 Resolution 에 의해 Query Tree 가 다시 만들어진다 적혀저있읍다 ...


더블어 재가 이글아래에가 간단하게 시험한 결과도 올렿읍니다 ...


다시말씀들이지만 table 이 drop 된시에는 모든 SP 를 다시 만들 필요는 업다는 예기입니다...


하지만 ... 이글을 읽으시는 분들한테는 이러개 예기를하고십읍니다 ..


I.  지연씨깨서 말씀하신걷처럼 SP 를 다시만드는것 아마도 더 좋을겁니다 ...이는....


A.  best practice (한국말로 멀라설명해야할지)

B. 똑갇은 테이블을 자주 drop & recreate 해주시묜 SP 크기가 커질수있다는점입니다.... 하지만 여기서 또참고로하셔야할것은 SP 가 #TEMP 테이블을 쓸경우에는 항상 Resolution 을한다는 말입니다 ... 한마디로 말해서는 따지고보묜 이래도 안좋코 저래도 않좋타는 예기조 ....  그러나 재가알기로는 SP size 가 커진다하혀 그리크개 문재될일은 거이 업다들었읍다... 이는 SYBASE 11 떼 그런점들을 고쳫기때문입니다 ....  


II.  SP 를 다시만드는것이 좋치만 허나 이는 현실적이지뫃합니다 ...


테이블하나 바꼏다해서 그테이블 reference 하는 모든 SP 를 다시만들어야한다묜 그것은 현실적이지 뫃하다는 것입니다 ...특히 SP 가 #TEMP 테이블을 쓴다묜 그 #TEMP table schema 를 먼저만들어야되기때문에 이런 SP 가 많으묜 많은 시간을 소비할수도 있다는것입니다....이러한 SP들이 100, 1000, 10000 가된다 생가해보십시요


재가지금 괄리하고있는 손님들부터시작하여 재가 오래전에 근무하던회사들 재가알고있는 DBA 들 Program 하시는분들 모두 Resolution 방식을 많이쓰며 테이블이 바낄시에는 그테이블떼문에 바낀 SP들만 다시만듭니다 ... 


다시말해서 모든 SP 를 다시만들수있는 system 이나 process 가 안되있다면 거이모두 Resolution 방식을 많이쓴다 예기조 ....


trigger 은 테블을드랍할실때 자동적으로 drop 되는줄기역되내요 ... 하여서 이것은 꼭다시만들어야지요.... 자동적으로 drop 안될시도 다시만들어줘야될이유는 IF_UPDATE 때문입니다.....


Summery 를하자면 SP 를 다시만드는겋이좋치만 너무무리를하며 만들필요는업다는것입니다


아래는 재가 아까말한결과입니다 ... 



 

==============================================


1>  create table xyz

2> ( a char (1))

3> go

1> create procedure sp_xyz

2> as

3> select * from xyz

4> go

1> exec sp_xyz

2> go

a

-


(0 rows affected)

1> select name, id from sysobjects where name in ("xyz", "sp_xyz")

2> go


name                           id

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

xyz                              418124914

sp_xyz                          1262651925


1> select * from sysdepends

2> go

id          number depid       depnumber status selall resultobj readobj

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

  1262651925      1   418124914         0      1      1         0       0


=====================================================================

1> create table xyz_x

2> (

3> a char(1)

4> )

5> go

1> select name, id from sysobjects where name = "xyz_x"

2> go

name                           id

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

xyz_x                           1793465847


=====================================================================

1> drop table xyz

2> go

1>

2> select name, id from sysobjects where name in ("xyz", "sp_xyz", "xyz_x")

3> go

name                           id

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

sp_xyz                          1262651925

xyz_x                           1793465847


1> select * from sysdepends

2> go

id          number depid       depnumber status selall resultobj readobj

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

  1262651925      1   418124914         0      1      1         0       0


=======================================================================


1> sp_rename xyz_x, xyz

2> go



1> select name, id from sysobjects where name in ("xyz", "sp_xyz", "xyz_x")

2> select * from sysdepends

3> go

name                           id

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

sp_xyz                          1262651925

xyz                             1793465847


(2 rows affected)

id          number depid       depnumber status selall resultobj readobj

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

  1262651925      1   418124914         0      1      1         0       0



=========================================================================

1> exec sp_xyz

2> go

a

-


(0 rows affected)

(return status = 0)

1> select name, id from sysobjects where name in ("xyz", "sp_xyz", "xyz_x")

2> select * from sysdepends

3> go

name                           id

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

sp_xyz                          1262651925

xyz                             1793465847


(2 rows affected)

id          number depid       depnumber status selall resultobj readobj

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

  1262651925      1  1793465847         0      1      1         0       0

한임경(SPID)님이 2006-11-17 15:08에 작성한 댓글입니다.
이 댓글은 2006-11-17 15:40에 마지막으로 수정되었습니다.
[Top]
No.
제목
작성자
작성일
조회
1731알려주세요! [2]
흠~
2006-11-17
4731
1729다시 질문드려여 [3]
이은영
2006-11-16
5683
1728좀 도와주세용 ㅠ-ㅠ [1]
초보자
2006-11-16
4246
1726대량 데이터 작업시 [5]
이은영
2006-11-15
9230
1725COM+ 와 Sybase [1]
손동길
2006-11-14
5188
1724테이블명이 A2006, A2007,A2008 식으로 년도별로 바뀔경우... [3]
GOODI
2006-11-14
5540
1723truncate table에 관해서 문의드립니다. [1]
누리
2006-11-14
5426
Valid XHTML 1.0!
All about the DATABASE... Copyleft 1999-2024 DSN, All rights reserved.
작업시간: 0.020초, 이곳 서비스는
	PostgreSQL v16.2로 자료를 관리합니다