Галактика в вопросах и ответах

Сейчас есть структура Enterprise 7.12 на MS SQL.

Есть задача перевести все это дело на Oracle.
Всвязи с этим вопросы следующие:

Как все это дело там будет работать? То есть. Нужно ли под каждую галактическую базу создавать свой экземляр и свою базу данных, а потом при помощи галактического Enterprise делать всякие объединения таблиц?

Или все галактические базы засунуть в одну БД Oracle но под разные схемы (и вообще будет ли так галка работать)?

Какие плюсы и минусы того и другого способа, если они оба работоспособны?
Минус первого способа, как я понимаю, в том, что каждый экземпляр будет "жрать" оперативку (ну допустим от 400Мб до 1Гб), а баз 7 штук -> сервак нужно конкретно апгрейдить.
Второй способ - не уверен, что он вообще будет работоспособен.

Пасибо всем откликнувшимся. Жаль что ни у кого такая штука не юзается. Ну хоть мысли может есть какие? Похоже прийдется методом проб и ошибок все запускать...

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

Могу сказать как у нас:
Галактика 7.11 с Enterprise.
Oracle 9i одна база с 11 схемами.
Все работает без проблем. Сервер 4 Xeon 8G RAM Ось RedHat Adv Server 3

Спасибо, ясно. Еще вопрос, как организуется сам Enterprise?
Галактика через триггеры, как в SQL, реализует Enterprise, или дает PUBLIC синонимы для общих таблиц а остальные только в схеме доступны? Или комплексно - триггеры+public?

И еще. Начал ставить тестовую базу на Oracle (вообще пустую). Так там данные получились примерно 137 Мб, а индексы на 1,2 Гб. Это нормально считается? При пустой то базе! То есть, если буду переводить живую ( с SQL), где данные занимают 3Гб, надо под индексы резервировать 30 Гб ?!?! Хотя в SQL они, эти индексы "всего" 4,7 Гб на этот объем данных. Так у меня на Enterprise никаких винтов не хватит.

Johny писал(а):Спасибо, ясно. Еще вопрос, как организуется сам Enterprise?
Галактика через триггеры, как в SQL, реализует Enterprise, или дает PUBLIC синонимы для общих таблиц а остальные только в схеме доступны? Или комплексно - триггеры+public?

Походу ни через то, ни через другое.
В таблице X$FILES slave-баз поле XF$LOC2 содержит ссылку на master-схему.

Johny писал(а):И еще. Начал ставить тестовую базу на Oracle (вообще пустую). Так там данные получились примерно 137 Мб, а индексы на 1,2 Гб. Это нормально считается? При пустой то базе! То есть, если буду переводить живую ( с SQL), где данные занимают 3Гб, надо под индексы резервировать 30 Гб ?!?! Хотя в SQL они, эти индексы "всего" 4,7 Гб на этот объем данных. Так у меня на Enterprise никаких винтов не хватит.

По-поводу "пустой" базы: не такая уж она и пустая
Там куча системных аналитик, планов счетов и т.д.
А на данные размером 3 Гига у нас размер индексного пространства 11 Гиг.
И вся база (12 схем) занимает порядка 60 Гигов.

Кстати, заметили, что при переносе данных, при undo retention 3 hours размер undo tablespace стал огромен (порядка 20 Гб), поэтому перед переносом можно уменьшить указанный параметр. Потом вернете.

да уж экономичная штука Oracle.

да уж экономичная штука Oracle

См. http://www.tyumbit.ru/gal_forum/viewtopic.php?t=3218

Попробуй использовать сжатие таблиц начиная с первого релиза 9 это можно делать.

Попробуй использовать сжатие таблиц начиная с первого релиза 9 это можно делать.

Мысль интересная, правда это возможно со 2 релиза.
А пользовался кто-нибудь сжатием таблиц?

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

А пользовался кто-нибудь сжатием таблиц?

У меня инстанции отдано 2,5 Г
Триггеры формирующие журнал пришлось корректировать чтобы при обновлении Lastdate, Lastnum и т.д. записей в журнал не делалось иначе в журнале mnplan за месяц набирает 3,5 Г места приче в основе - мусор по изменению этих полей.
Сама база молодая и маленькая таблицы - 11Г индексы - 9 Гб

Добрый день. Просветите: а в чем преимущество от использования Enterprise?

И сразу вопрос, преимущество перед чем? Это просто несколько другая архитекура БД

Это не преимущество, а производственная необходимость, продиктованная суровыми условиями жизни!

Приходит как-то начальство Холдинга (7 контор) к админу и говорит. Значит так, с завтрашнего дня хотим, чтобы вся бухгалтерия была раздельной! Ну и давай еще договора чтобы раздельно, а вот, например, складской учет чтобы сквозной был, ну и там по мелочи.

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

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

ЗЫ:
Начальство довольно а вам засада. Ведь послезавтра начальство приходит и говорит: А давай-ка разделим еще и складской учет. А вот договора-то мы зря побили, давай обратно переделывай.