Oracle 10g의 압축방식은 block level에서 이뤄지는데다,
direct path insert같은 load를 할 때만 효력이 있었던 듯 하고...
Oracle에서 block level compress를 하는 과정은
load 시 중복 값을 block에서 발견하면 이를 block header에 기록한 후
실제 데이터는 block header를 pointer로 가리켜놓는 식인데
한 block에 동일한 데이터가 많이 들어갈 수록 압축 효율이 높아지게 된다.
Oracle의 block level compress로 인한 태생적 한계는
특정한 값이 block에 반복하여 insert/update 하는 경우에 압축을 하는 것 같다.
DB2에서는 table 또는 partiion based로 dictionary를 만들기 때문에
block level보다 합리적으로 동작하고 압축률이 높아지는데
스토리지를 절약하는 것 이외에도 여러가지 장점
- 버퍼풀에서도 압축된 상태이므로 메모리를 아낀다던가,
백업 시간이 단축된다던가 하는(TB급 DB를 관리할 때는 이 점이 제일 좋다) - 을 가진다.
direct path insert같은 load를 할 때만 효력이 있었던 듯 하고...
Oracle에서 block level compress를 하는 과정은
load 시 중복 값을 block에서 발견하면 이를 block header에 기록한 후
실제 데이터는 block header를 pointer로 가리켜놓는 식인데
한 block에 동일한 데이터가 많이 들어갈 수록 압축 효율이 높아지게 된다.
Oracle의 block level compress로 인한 태생적 한계는
- Table, Range partition에서의 중복값을 compress하지 못함
- 여러 block에서 반복되는 값이라 하더라도, 각 block header에 dictionary를 만들어야 함
- column value 단위로 찾으므로, 문자열 일부분을 압축할 수 없음
- load시에만 작동하고, insert/update시에는 작동하지 않음
특정한 값이 block에 반복하여 insert/update 하는 경우에 압축을 하는 것 같다.
DB2에서는 table 또는 partiion based로 dictionary를 만들기 때문에
block level보다 합리적으로 동작하고 압축률이 높아지는데
스토리지를 절약하는 것 이외에도 여러가지 장점
- 버퍼풀에서도 압축된 상태이므로 메모리를 아낀다던가,
백업 시간이 단축된다던가 하는(TB급 DB를 관리할 때는 이 점이 제일 좋다) - 을 가진다.
