"조금"문제가 있습니다. 일주일 전에 데이터베이스가 전체 디스크 용량에 도달했습니다. 디스크 공간을 확보하려고 시도하는 여러 테이블의 행을 삭제했습니다. 내가 완전한 진공을 달리는 것을 시도한 후에는 완료되지 않았다.postgreSQL 진공 임시 파일?
내가 알고 싶은 것은. 내가 완전히 compliting에서 진공을 막을 때 수동으로 삭제해야 디스크에 임시 파일을두고 있습니까? 필자는 이제 불필요하게 큰 문제라고 말할 수있는 100 % 디스크 용량의 데이터베이스를 보유하고 있습니다.
디스크 공간을 확보하는 데 유용한 팁이 있습니까?
나는 SUSE를 postgres 8.1.4 데이터베이스와 함께 사용하고 있습니다. 모든
첫째 :
당신이 할 수 8.2, 8.3 또는 8.4에해도 - 적어도 순간 8.1.17 인 (8.1 최신으로 업그레이드하지만 8.1이 될 것이다 18 일에서 1-2 일 사이).
둘째 : 문제가 무엇인지 진단하십시오.
du 도구를 사용하면 정확하게 공간을 진단 할 수 있습니다. 너무 많은 공간을 차지하고있는 디렉토리는 무엇입니까?
df으로 확인한 다음 사용 된 공간의 총량을 확인한 다음 PostgreSQL 디렉토리의 용량을 확인하십시오. 당신은 당신이 그것에 대해 뭔가를 할 수있는 공간을 사용하고 PGDATA에있는 디렉토리를 알고, 이제
cd YOUR_PGDATA_DIR
du -sk *
cd base
du -sk *
cd LARGEST DIR FROM PREVIOUS COMMAND
du -sk * | sort -nr | head
:
가장 좋은 옵션이다.
로그 또는 pg_temp - 로그를 다시 시작하거나 로그를 제거합니다 (pg_clog 및 pg_xlog는 일반적인 의미의 로그가 아니며 절대 삭제하지 않습니다). 그 다음 기본 디렉토리에 뭔가가 있다면
는 : 기본 디렉토리에
수치 디렉토리는 데이터베이스와 관련이 있습니다. 당신은 그것을 확인하실 수 있습니다 : 당신이 공간의 대부분을 사용하고있는 데이터베이스를 알게되면
select oid, datname from pg_database;
, 그것을 연결하고 파일이 가장 많은 공간을 사용하고 있는지 확인하십시오.
파일 이름은 선택 사항 ".digits"접미사와 숫자가 될 것이다 -이 접미사가 (지금은)는 관련이없는, 당신은 실행하여 파일이 나타내는 정확하게 확인할 수 있습니다 : 당신이 어떤 테이블을 알게되면
select relname from pg_class where relfilenode = <NUMBER_FROM_FILE_NAME>;
을/indexes는 대부분의 공간을 사용합니다. VACUUM FULL을 사용하거나 CLUSTER 명령을 사용하면됩니다.
문제의 새로운 접선에서 query을 사용하여 많은 공간을 사용하는 데이터베이스의 내용을 확인할 수 있습니다. 그러면 삭제 된 정보가있는 작업 공간을 정리할 수있는 충분한 작업 공간을 확보하기 위해 TRUNCATE 후보를 찾을 수 있습니다.
많은 행을 삭제하지만 디스크 공간을 충분히 유지할 수 있도록 빈번하게 VACUUMing을 수행하지 않으면 색인 팽창이라는 조건이 생기므로 VACUUM FULL은 전혀 도움이되지 않습니다. 내가 제안한 쿼리가 대부분의 공간이 일반 테이블이 아닌 인덱스에 의해 점유되었다는 것을 알았을 때 거기에 있음을 알 수 있습니다. 이 문제를 해결하려면 모든 것을 다시 작성하기 위해 테이블 자체의 디스크 공간을 필요로하는 CLUSTER가 필요합니다.
답장 보내 주셔서 감사합니다. 내 문제는 디스크가 100 % 찼습니다. 진공 및 클러스터에는 실행할 수있는 디스크 공간이 필요합니다. 진공/클러스터를 실행하지 않고 DB에서 데이터를 완전하게 제거 할 수 있습니까? – jorgen
희생시킬 수있는 테이블을 찾아서 TRUNCATE하십시오. 즉시 공간을 확보 할 것입니다. –
도와 주셔서 감사합니다. – jorgen