최근 Teradata를 사용하여 프로젝트에 할당되었습니다. 나는 DELETE ALL 대신 DROP + CREATE를 엄격하게 사용하라는 말을 들었다. 이것은 나에게 반 직관적이며, 아마도 그것이 틀렸다고 생각합니다. 나는 두 가지 방법을 비교하기 위해 웹을 검색했지만 아무 것도 발견하지 못했습니다. 이것은 DELETE ALL이 위의 문제로 고통받지 않는다는 나의 믿음 만 강화합니다. 그러나 이것이 사실 인 경우이를 증명해야합니다 (실질적으로나 이론적으로 모두).Teradata DELETE ALL 대 DROP + CREATE
내 질문은 : 두 가지 방법 사이에 공간 할당에 차이가 있습니까? 그렇지 않다면 그것을 증명하는 공식 문서 (사용자 가이드, 기술 사양 등)가 있습니까?
감사합니다.
매우 비슷한 주제에 대해 http://teradataforum.com/teradata/20120403_105705.htm에 대한 토론이 있습니다 (실제로는 "일부 공간 할당 됨"부분에 답변하지 않지만). 그들은 실제로 DELETE ALL하지만, 다른 (성능) 이유를 권장합니다
: 거기에 자주 실용되는 것은 아니지만,
가 빨리 될 것 "모두 삭제" 그것들의 성능에 많은 차이가 있습니다.
그러나 정기적으로 실행되는 프로세스 (일별 일괄 처리)에서는 특히 "모두 삭제"접근 방식을 권장합니다. 이렇게하면 데이터가 제거되고 정의가 그대로 유지되므로 작업량이 줄어 듭니다. 정의를 제거하면 여러 사전 테이블에 액세스해야하며 물론 객체를 다시 만들 때 동일한 테이블 (일반적으로)에 액세스해야한다는 것을 기억하십시오.
성능 측면을 제외하면 드롭/작성 방식의 단점은 개체에 대한 후속 액세스가 역할 보안을 통해 제어되는 경우에도 Teradata가 AccessRights 테이블에 "기본 행"을 삽입한다는 것입니다./또는 데이터베이스 레벨 보안. AccessRights 테이블이 쉽게 커지고 매우 비뚤어 질 수 있다는 것을 잘 알고있을 것입니다. 내 경험에 의하면 많은 사이트에는 정기적으로이 테이블을 정리하여 중복 된 행을 제거하는 프로세스가 있습니다. 일반적으로 배치 (일괄 처리) 프로세스가 정기적으로 객체를 삭제/작성하면 이전에 정리 된 프로세스로 제거 된 테이블에 행을 추가하는 것이고 나중에 같은 프로세스에서 제거됩니다. 이 모든 것은 마치 시간 낭비와 같습니다.
인상은
가 모두 삭제 단순히 잘못된 :-) 다른에서 TRUNCATE와 유사하다 때문에, 당신은 어떤 참조 어떤 장소에서 "삭제가 할당 된 공간을 남긴다"찾을 수 없습니다 정확 DBMSes 및 대부분의 경우 fastpath 처리를 사용하십시오.
DBC.DiskSpace에서보고되는 공간이 테이블 헤더 일 수 있습니까? 새 테이블을 채우지 않고 DROP 및 CREATE를 수행하면 해당 공간이 존재하게됩니다. –