База и её реплика

[Zeka]

Где-то слышал, что две реплики одной базы на одном сервере могут стать источником больших проблем.
Может кто-нибудь сказать, действительно ли это так и какие эти самые проблемы могут быть?

Меня больше интересует следующий вопрос - а что если на одном сервере расположена и база и её реплика? Есть какие-то подводные камни?

ПС: Я не админ

 

[Sergey Berezka]

как минимум id реплик отличаться должны

 

[puks]

как минимум id реплик отличаться должны

Тогда они, формально, будут копиями, а не репликами.

 

[Constantin A Chervonenko]

Где-то слышал, что две реплики одной базы на одном сервере могут стать источником больших проблем.
Может кто-нибудь сказать, действительно ли это так и какие эти самые проблемы могут быть?

1.Клиент с сервером такого безобразия сделать не дадут (создать реплику на том-же сервере). Но мы не ищем лёгких путей - добавляем базу на файловом уровне
2.Если внешний сервер затевает репликацию с сервером-держателем двойной реплики, то какая именно из копий базы поучаствует в сеансе - неизвестно. Как правило - та, что ближе к корню DATA; но иногда ...
3.Результат: после нескольких месяцев спокойной жизни ВДРУГ в куче баз по всей сети возникают "зомби" - давно удалённые документы.

Спортивнее всего насоздавать лишних реплик адресных книг соседних доменов - для сохранности

 

[am4]

1.Клиент с сервером такого безобразия сделать не дадут (создать реплику на том-же сервере).

Да запросто (в другой каталог).

2.Если внешний сервер затевает репликацию с сервером-держателем двойной реплики, то какая именно из копий базы поучаствует в сеансе - неизвестно. Как правило - та, что ближе к корню DATA; но иногда ...

Тут да, не очевидно

Не совсем понятна постановка задачи, может линками проще обойтись?

 

[Zeka]

2.Если внешний сервер затевает репликацию с сервером-держателем двойной реплики, то какая именно из копий базы поучаствует в сеансе - неизвестно. Как правило - та, что ближе к корню DATA; но иногда ...

Так при описании реплики вроде можно указать, какие фолдеры с какими серверами реплицыровать...
Хм... Судя по всему, здесь проблемма и начнётся...

Не совсем понятна постановка задачи, может линками проще обойтись?

Есть база. Надо запустить DECS для переноса данных в DB2. DECS зараза, при переносе данных, имеет склонность обрезать поля в ноутсовских документах так, что бы по длине они были не больше ширины соответствующих столбиков в DB2. Соответственно даные могут потеряться. Это обрезание полей можно запретить, но тогда DECS вообще не будет перенесить документы с черезмерно длинным полями в DB2.
Кроме того есть ещё несколько ситуаций когда DECS может поковеркать данные.
Поэтому возникла "гениальная" идея сделать однонапрвленую реплику базы и разрешить DECS'ку делать в ней чё он хочет и как он хочет.

 

[Karpeyev]

2. ... какая именно из копий базы поучаствует в сеансе - неизвестно. Как правило - та, что ближе к корню DATA; но иногда ...

У меня был случай: создали 2 реплики на одном сервере в разных папках.
Реплицированлись при этом обе реплики, одновременно.

 

[VladSh]

2.Если внешний сервер затевает репликацию с сервером-держателем двойной реплики, то какая именно из копий базы поучаствует в сеансе - неизвестно. Как правило - та, что ближе к корню DATA; но иногда ...
3.Результат: после нескольких месяцев спокойной жизни ВДРУГ в куче баз по всей сети возникают "зомби" - давно удалённые документы.

Тут да, не очевидно

Хм... Судя по всему, здесь проблемма и начнётся...

Никаких проблем не будет. Просто надо на сервере настроить репликацию таких баз (с обинаковыми Replicaid) с самим собой (сервер в полях Source server и Destination server тот же самый).
Такое используется, когда, например, на сервере установлено несколько комплектов Системы, базы с документами, контролями и т.п. разные, а базы со справочными данными одинаковые.
Но смогут ли помочь БД с одинаковыми репликами для DECS.. - не знаю. Правило из личного опыта: по минимуму использовать готовые реализации от IBM. Под тот же DECS люди програмят и никаких подобных проблем не испытывают (во всяком случае я на такое не натыкался, и о таком не слышал).

 

[Baneslaer]

Такое используется, когда, например, на сервере установлено несколько комплектов Системы, базы с документами, контролями и т.п. разные, а базы со справочными данными одинаковые.

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

 

[Zeka]

Никаких проблем не будет. Просто надо на сервере настроить репликацию таких баз (с обинаковыми Replicaid) с самим собой (сервер в полях Source server и Destination server тот же самый).

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

 

[VladSh]

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

Да неужели? ))
А если мне надо из БД Контрагентов создать Входящий документ (такое часто бывает, т.к. PickList не даёт возможности использовать фильтры, а в самой базе искать нужный док по полнотекстовому поиску легко и удобно), в каком комплекте мне его создавать?

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

Повторюсь. Проблем не было. На сервере стояло 4 комплекта баз с одинаковыми репликами; реплицировались все реплики (сразу или нет - деталей не помню, т.к. давно это было).
Если хотите перестраховаться, то отключите репликацию сервера самим с собой, внутри баз с одинаковыми репликами сделайте агента, который будет толкать репликацию вручную.

 

[Baneslaer]

Да неужели? ))
А если мне надо из БД Контрагентов создать Входящий документ (такое часто бывает, т.к. PickList не даёт возможности использовать фильтры, а в самой базе искать нужный док по полнотекстовому поиску легко и удобно), в каком комплекте мне его создавать?

Повторюсь. Проблем не было. На сервере стояло 4 комплекта баз с одинаковыми репликами; реплицировались все реплики (сразу или нет - деталей не помню, т.к. давно это было).
Если хотите перестраховаться, то отключите репликацию сервера самим с собой, внутри баз с одинаковыми репликами сделайте агента, который будет толкать репликацию вручную.

Не совсем понял что имеется в виду, так как документооборот у всех свой.
насколько я понял, у вас 2 базы - контрагенты и Канцелярия(Входящая/исходящая корреспонденция).
И создаете вы док непосредственно из базы Контрагентов?
А что мешает запретить создание доков из базы контрагентов, пусть создают из Канцелярии.
При этом в канцелярии сделать категоризованную вьюху по контрагентам, если пользователям тяжело искать.

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

 

[VladSh]

Не совсем понял что имеется в виду, так как документооборот у всех свой.

Почему такое предположение? В главном офисе (где это всё установлено) руководители и ответственные лица могут работать во всех комплектах.

насколько я понял, у вас 2 базы - контрагенты и Канцелярия(Входящая/исходящая корреспонденция).

Ну вообще баз далеко не две )

И создаете вы док непосредственно из базы Контрагентов?
А что мешает запретить создание доков из базы контрагентов, пусть создают из Канцелярии.
При этом в канцелярии сделать категоризованную вьюху по контрагентам, если пользователям тяжело искать.

Запретить мешает то, о чём я писал выше:

(такое часто бывает, т.к. PickList не даёт возможности использовать фильтры, а в самой базе искать нужный док по полнотекстовому поиску легко и удобно)

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

Когда на сервере устанавливают несколько комплектов систем, то по фен-шую все справочники создают как копии, кроме справочника организации.

Китайские традиции, несомненно, надо уважать, но не всегда выходит по "по фен-шую"... Иногда бывают случаи и одинаковых справочников. И бывают случаи разных справочников организаций.

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

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

 

[Baneslaer]

документооборот у всех свой, имелось в виду, что у разных организаций своя структура баз и свои системы, какая именно у вас могу только догадываться.

Ну вообще баз далеко не две ) - в Этом посте говорили именно про связку двух баз. Ясно что их может быть несколько сотен. Придираться к отдельно вырванным из контекста предложениям твое хобби?

Средств для поиска документа в базе предостаточно, так и не понял что вам неудобно?

По сути, у вас сейчас разные справочники организаций используются? Демагогия, мне неинтересна.

Маневрирование доступами очень интересная штука. Особенно, когда сегодня одинаковые справочные значения нужны 2 филиалам, а завтра только одному. И Так каждый день надо дергать админа чтобы прописывал нужную видимость документа. Особенно, для секретарей разных филиалов придется играться с доступами.

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


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

 

[VladSh]

Средств для поиска документа в базе предостаточно, так и не понял что вам неудобно?

Ваше предложение: запретить создавать доки из справочника контрагентов. Вопрос: имеется организация, например она называется "ООО Весёлый пельмешко", каким образом найдут её пользователи в пиклисте или в категоризированной вьюхе, если один помнит, что в названии есть слово "пельмешко", а другой - "весёлый"?
Это простой пример, есть и посложнее.

По сути, у вас сейчас разные справочники организаций используются?

В разных случаях по разному. Одни справочники общие, другие - нет. Должно работать так, как хочет заказчик.

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

Альтернатива - играться с перебрасыванием доков?

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

Вы невнимательно читаете.
Главный офис отслеживает документооборот, притом некоторые лица могут в нём участвовать. Также репликация - это способ хранения информации у себя, если что...
Ответ тот же: при создании документов в основных базах из справочных баз не всегда есть возможность понять, в какой базе нужно создавать документ; привязка конкретного пользователя к базе не подходит, т.к. он может работать в нескольких комплектах. Если комплект лежит в одной папке на сервере, тогда понятно, в какой базе с документами создавать док.

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

Вообще в нормальных организациях думают наперёд над тем, что будет, если организации разбегутся, как например случилось в Днепропетровске в одном крупном холдинге в 2004-м году: одни директора были за Януковича, другие - за Ющенко, в результате по этой, как бы фонарной, причине, холдинг распался - одни люди ушли со своими заводами в одну сторону, другие со своими - в другую...
А также люди думают, на каких условиях работает там ПО на филиалах, прописывают права в договорах сублицензирования для определённых условий... и, естественно, такой подход, в виде разделения комплектов, вполне оправдан и, в некотором роде, даже красив.

P.S. Про счётчики я ничего не говорил, это отдельная тема.

 

[Akupaka]

2.Если внешний сервер затевает репликацию с сервером-держателем двойной реплики, то какая именно из копий базы поучаствует в сеансе - неизвестно. Как правило - та, что ближе к корню DATA; но иногда ...

Ну как же неизвестно? Реплицируются все реплики. Другое дело, когда нужно контролировать процес, вот тут могут быть неприятности.

Просто надо на сервере настроить репликацию таких баз (с обинаковыми Replicaid) с самим собой

Думаю, это не очень удачное решение. Лучше использовать некий второй сервер. Хотя, тут все зависит от топологии репликации.

И какую из двух баз он найдёт - большой вопрос.

Все найдет, как уже выше писали.

Zeka,
ты бы свою задачу конкретизировал, а то догадки какие-то строишь, а смысл не понятен.

 

[Zeka]

Zeka,
ты бы свою задачу конкретизировал, а то догадки какие-то строишь, а смысл не понятен.

Описывал я её вроде...

Надо было переносить данные в DB2. Хотели использовать DECS. Но работать с ним надо крайне акуратно, иначе он очень легко может поковеркать значения полей в ноутсовской базе. Поэтому хотели сделать одностаронюю реплику, что бы если ДЕЦС и попортит данные, то только в этой реплике.
В общем отказались мы от этого убогого ДЕЦСка и написали агентик который прекрасно и безопасно переносит данные.

 

[Akupaka]

Zeka ,
действительно описывал, извини, я пропустил.
А решение с агентом вполне верное.

Односторонняя репликя сервера на самого себя в этом случае врядли получилась бы как надо.

 

[Constantin A Chervonenko]

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

Вот-вот. В док-то Connection указывается путь к базе на сервере-инициаторе, про целевой сервер там ничего нет, И быть не может! Там только его имя и, возможно, адрес. О файловой системе удалённого сервера ничего не известно. Возможно, тамошний админ перенёс базу в другой каталог? А может там и каталогов-то нету?? Только тома и минидиски какие-нибудь. Потому что аппаратную платформу тоже поменяли!
В общем, вызываемому серверу известен ТОЛЬКО ReplicaID базы.
Поиск базы он производит неслучайным образом (от корня DATA, и далее). Поэтому ОБЫЧНО результат предсказуемый. Но ИНОГДА... то-ли эта база занята, то-ли наоборот - лишняя реплика уже открыта (закеширована)...

Connection сам с собой никогда не проверял (а сейчас - и не смогу, не админю более). Даже если это и работает (?), то реплик должно быть не более двух. С третьей опять возникнет ситуация непредсказуемости

 

[Akupaka]

С третьей опять возникнет ситуация непредсказуемости

У мну на сервере около 50 реплик одной БД и другой сервер вполне себе "перебирает" все и претензий не предъявляет. И когда этот с 50-ю репликами реплицирует на другой сервер, тоже не испытывает проблем.