문제

Notes 데이터베이스의 데이터베이스 크기 상한을 피할 수 있는 방법이 있습니까?우리는 여전히 크기가 60GB에 육박하는 데이터베이스를 압축하고 있습니다.제안해주시면 정말 감사하겠습니다.

도움이 되었습니까?

해결책

64GB 제한을 넘을 수있는 방법을 찾을 수 있더라도 권장 솔루션은 아닙니다. 성능을 향상시키고 Domino 서버의 안정성을 유지하려면 응용 프로그램을 여러 데이터베이스로 분할하는 것이 훨씬 좋습니다. 검색을 위해 동일한 데이터베이스에 모든 것을 갖추어야한다고 생각되면 Domino Administrator 도움말에서 도메인 검색 및 다중 대사 검색을 찾아보십시오.

  • 데이터의 일부가 "오래된"일부이며 대신 하나 이상의 아카이브 데이터베이스에 넣을 수 있습니까?

  • 어쩌면 큰 첨부 파일이 많고 일련의 첨부 데이터베이스에 저장할 수 있습니까?

  • 어쩌면 당신은 간소화되거나 제거 될 수있는 복잡한 견해를 가지고있어 많은 공간을 절약하고 당분간 동일한 데이터베이스에 모든 것을 보관할 수 있습니까? (필요하지 않은 경우 열에서 정렬을 제거하십시오. "열 헤더를 클릭하여 정렬하십시오"를 사용하여보기 인덱스의 크기를 높이는 확실한 방법입니다.)

다른 팁

파일 첨부 파일로 인해 데이터베이스가 크다고 가정합니다. 이 경우 DAOS를 살펴보십시오. 모든 파일 첨부 파일을 파일 시스템 (서버 기능 - 클라이언트 및 기존 응용 프로그램에 투명)에 저장합니다.

보너스로서는 복제를 찾아 한 번만 저장합니다.

여기에 추가 : http://www.ibm.com/developerworks/lotus/library/domino-green/

어둠 속에서 찌르기 :

Domino 서버 대신 DB2 스토리지 방법을 사용하십니까?

해당 공간의 80-90%가 파일 첨부 파일에 의해 취해 졌다고 생각합니다. 내 제안은 모든 첨부 파일을 파일 공유로 옮기는 것입니다.

보안이 문제가되기 때문에 이상적이지 않습니다. 이제 메모 데이터베이스와 외부 파일 공유에 대한 자격 증명을 관리해야하지만 노트 관리자의 관점에서 노력할 가치가 있습니다.

노트 문서에서 파일에 대한 링크 만 제공하십시오. 사용자가 메모 양식을 통해 이러한 파일을 추가하는 경우, 저장된 후 문서에서 파일을 추출하여 해당 파일에 대한 링크로 바꾸는 배경 코드를 추가 할 수 있습니다.

64GB는 실제로 절대 한계가 아닙니다. 당신은 그 이상으로 갈 수 있습니다. 나는 80GB를 보았고 심지어 100GB에 가깝게 보았습니다. 제한은 실제로 메모가 아닙니다. 기본 파일 시스템입니다. AS400에서 이것을 보았지만 메모의 가장 큰 장점은 큰 충돌을 일으키면 모든 문서에 액세스하고 모든 것을 사용하여 새로운 사본으로 끌어 당길 수 있다는 것입니다. 더 이상 클라이언트에서 열릴 조회수를 얻을 수없는 경우에도 예정된 에이전트.

최고의 최고 보관은 정기적 인 아카이브입니다. 파일 첨부 파일이라면 2 년이 넘는 것은 메인 시스템에있을 필요가 없습니다. 간단한 시놉시스 및 링크 만 있으면 5 년 아카이브, 2 년 보관 1 년 아카이브 등을 가질 수도 있습니다. 저장에 사용하는 플랫폼에 관계없이 데이터는 계속 축적되며 관리해야합니다.

문제가 실제로 큰 파일 첨부 파일 인 경우 서버 / 데이터베이스에서 DAO를 구현하는 것이 좋습니다. Domino Server 8.5 이상에서만 사용할 수 있습니다. 반면에 데이터베이스가 10 만 개가 넘는 문서가 포함 된 경우 데이터를 여러 NSF로 나누는 것을 진지하게 살펴볼 수 있습니다. 해당 문서 수에 따라보기 설계, 조회 코드 등에 대해 매우주의해야합니다. .

일부는 DAOS와의 성공을 기록했습니다.http://www.edbrill.com/ebrill/edbrill.nsf/dx/yet-another-daos-success-story-from-darren-duke?opendocument&comments

데이터베이스가 60GB에 도달하는 경우 .. Domino 솔루션을 사용하지 마십시오. 관계형 데이터베이스로 전환해야합니다. 여러 데이터베이스에서 문서를 보관하거나 이동해야합니다. 60GB에 도달 할 수는 있지만 그렇게해서는 안됩니다. 활성 데이터베이스의 성능은 중요합니다. 정적 데이터베이스에는 그다지 문제가되지 않습니다.

또한 불필요한 뷰와 해당 인덱스를 제거하는 방법도 살펴보겠습니다.보기 인덱스는 디스크 공간의 80-90%를 차지할 수 있습니다.제거할 수 없는 경우 정렬 배열/공식을 단순화하고 불필요한 열 정렬 옵션을 제거하십시오.이와 같은 몇 가지 간단한 변경으로 50GB를 25GB로 절반으로 줄였고 실제로 사용자는 눈치채지 못했습니다.

한 번은 사용자를 시작하는 경로 일 수 있습니다. 모든 사용자가 항상 모든 데이터에 액세스해야합니까? 아니오라면, 분할 또는 보관 시간입니다. 그렇다면 응용 프로그램 설계에 결함이있을 수 있습니다.

기술적으로, 나는 이전 의견에 확인할 제안을 추가 할 것입니다. 압축을위한 많은 옵션. 빠르고 더러운 : 모든보기 지수를 무시하지만 사용자가 폭동을 원하지 않으면 기본보기에 대해 최소한 재건하십시오. 보다 updall

확인해야 할 사항 중 하나 : 확인했는지 확인하십시오.

x] 부착물에 LZ1 압축을 사용하십시오

DB 속성으로.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top