Как обойти барьер базы данных Lotus Notes 60 Гб - PullRequest
4 голосов
/ 17 марта 2009

Есть ли способы обойти верхний предел размера базы данных в базах данных Notes? Мы сжимаем базу данных, которая по-прежнему приближается к 60 гигабайтам. Большое спасибо, если вы можете предложить предложение.

Ответы [ 10 ]

8 голосов
/ 17 марта 2009

Даже если вы сможете найти способ преодолеть ограничение в 64 ГБ, это не будет рекомендуемым решением. Разделить приложение на несколько баз данных гораздо лучше, если вы хотите повысить производительность и сохранить стабильность вашего сервера Domino. Если вы считаете, что вам нужно иметь все в одной базе данных для поиска, пожалуйста, найдите поиск по домену и поиск по нескольким базам данных в справке Domino Administrator.

  • Может быть, некоторые части данных "старые" и могут быть помещены в одну или несколько архивных баз данных?

  • Может быть, у вас много больших вложений, и вы можете хранить их в серии баз данных вложений?

  • Может быть, у вас есть много сложных представлений, которые можно упростить или исключить и, таким образом, сэкономить много места и на некоторое время сохранить все в одной базе данных? (Удалите сортировку по столбцам там, где это не нужно, использование «щелчка по заголовку столбца для сортировки» - верный способ увеличить размер индекса представления.)

7 голосов
/ 11 июня 2009

Я предполагаю, что ваша база данных велика из-за вложенных файлов. В этом случае посмотрите в DAOS - он будет хранить все файловые вложения в файловой системе (функциональность сервера - прозрачна для клиентов и существующих приложений).

В качестве бонуса находит дубликаты и сохраняет их только один раз.

Подробнее здесь: http://www.ibm.com/developerworks/lotus/library/domino-green/

3 голосов
/ 07 марта 2013

64 ГБ на самом деле не является абсолютным пределом, вы можете превысить его, я видел 80 ГБ и даже близко к 100 ГБ, хотя после того, как вы преодолели 64 ГБ, у вас могут возникнуть проблемы в любое время. Ограничение на самом деле не Notes, это лежащая в основе файловая система, я видел это на AS400, но самое замечательное в Notes - это то, что если у вас случился огромный сбой, вы все равно можете получить доступ ко всем документам и вытащить все в новые копии, используя запланированные агенты, даже если вы больше не можете открывать представления на клиенте.

Лучшее, что вы можете сделать, - это регулярное архивирование, если это вложения файлов, то все, что старше двух лет, не обязательно должно быть в основной системе, просто краткий синопсис и ссылка, вы можете даже иметь 5-летний архив, 2-летний архив 1 год архив и т. д., данные будут продолжать накапливаться, и ими нужно управлять независимо от того, какую платформу вы используете для их хранения.

3 голосов
/ 17 марта 2009

Я предполагаю, что 80-90% этого пространства занимают вложенные файлы. Я предлагаю перенести все вложения в общий файловый ресурс при условии, что каждый может получить доступ к этому общему ресурсу или на FTP-сервер, к которому каждый может подключиться.

Это не идеально, потому что безопасность становится проблемой - теперь вам нужно управлять учетными данными для базы данных Notes и внешнего общего файлового ресурса - однако это будет стоить усилий с точки зрения администратора Notes.

В документах Notes просто укажите ссылку на файл. Если пользователи добавляют эти файлы через форму Notes, возможно, вы можете добавить некоторый фоновый код для извлечения файла из документа после его сохранения и заменить его ссылкой на этот файл.

3 голосов
/ 17 марта 2009

Просто удар в темноте:

Использовать метод хранения DB2 вместо сервера Domino?

2 голосов
/ 19 июня 2009

Если проблема действительно связана с большими вложениями файлов, я, безусловно, рекомендую рассмотреть реализацию DAOS на вашем сервере / в базе данных. Он доступен только для Domino Server 8.5 и более поздних версий. С другой стороны, если ваша база данных содержит более 100 000 документов, вам может потребоваться серьезно подойти к разделению данных на несколько NSF - при этом количестве документов вы должны быть очень осторожны с дизайном представления, кодом поиска и т. Д. .

Некоторые задокументированные успехи с DAOS: http://www.edbrill.com/ebrill/edbrill.nsf/dx/yet-another-daos-success-story-from-darren-duke?opendocument&comments

1 голос
/ 19 августа 2016

Один путь можно было бы, на один раз, начать с пользователя. Все ли пользователи должны иметь доступ ко всем этим данным все время? Если нет, пришло время разделить или заархивировать. Если да, то, вероятно, есть недостаток в дизайне приложения.

Технически, я бы добавил к предыдущим комментариям предложение проверить много опций сжатия . Быстро и грязно: отмените все индексы просмотра, но обязательно перестройте хотя бы один для представления по умолчанию, если вы не хотите, чтобы ваши пользователи бунтовали. См. Обновление

1 голос
/ 10 сентября 2013

Я бы также посмотрел на удаление ненужных представлений и их индексов. Просмотр индексов может занимать 80-90% вашего дискового пространства. Если вы не можете удалить их, упростите их сортировку / формулы и удалите все ненужные параметры сортировки столбцов. Я уменьшил вдвое 50 ГБ до 25 ГБ с помощью нескольких простых изменений, подобных этому, и практически никто не заметил.

1 голос
/ 27 декабря 2009

Если ваша база данных достигает 60 ГБ. Не используйте решение Domino, вам нужно переключиться на реляционную базу данных. Вам необходимо архивировать или перемещать документы по нескольким базам данных. Хотя вы можете получить до 60 ГБ, вы не должны этого делать. Падение производительности для активных баз данных значительно. Не такая большая проблема для статических баз данных.

0 голосов
/ 04 февраля 2013

Еще одна вещь, которую нужно проверить: убедитесь, что вы проверили

[x] Использовать сжатие LZ1 для вложений

в свойствах db.

...