Joker_YaПросто мне не очень нравиться когда вещи давно реализованные в других СУБД MS анонсирует как чуть-ли не божественное озаренье, а толпы фанатов начинают петь дифирамбы вторя ей.
В том то и дело, что никому не нравится отставание MSSQL от конкурирующих СУБД и я пока слабо видел "толпы поклоников, поющих дифирамбы". Вы же это утверждаете, как некий неприложный факт и собственно говоря топик этот создали почем зазря, просто очередной повод к флейму "Кто то рулез, кто то мастдиа".

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

vadiminfoВозможно, Вы будете не правы и по другим причинам. В частности, Оракл в удаленных, а точнее распределенных БД врядли среди из последних. По крайней мере, известные по литературе технологии он поддерживает соотвественно. Репликация через мыло - это, действительно, смешно.
Репликация через мыло, FTP или файлы не становятся смешными для удаленных точек, работающих через модемы, GPRS или передачей информации через курьеров. Сюда относятся удаленные офисы в глубинках, ноутбуки, КПК и прочее. Для Оракла действительно смешно, потому что он этого не умеет и не будет уметь из за своей архитектуры. Ну а вот Оракл на КПК - это действительно смешно (шутка конечно) :)

vadiminfoНо и ее можно там пролабать при желании, хотя хто, интересно, может говорить о таких с позволения сказать распеределенных транзакциях и чего они стоят?
Полноценно стОят, смею Вас заверить. Двустороння репликация по лог-файлу, причем не только DML, но и DDL операторов, с триггерами разрешения конфликтов версий, расширенными операторами управления репликациями, возможностью ограничения области видимости информации для удаленных узлов, вплоть до автоматического перемещения информации при смене области видимости информации (смене кода узла) между удаленными узлами, выгрузки с консолидированной БД полной информации по узлу в случае потери информации на узле и невозможности восстановления бакупа - фактически репликации ASA создают прозрачную схему работы удаленных узлов, где консолидированная БД является суммой информации всех удаленных узлов, а удаленные узлы являются частью консолидированной БД и обладают только информацией, полагающейся им в пределах заявленной области видимости. С учетом того, что удаленный узел (офис) так же может быть консолидированной БД по отношению к нижестоящим узлам (например КПК и ноутбукам сотрудников) и уже на принадлежащей ему информации вводить понятия области видимости ... то я глубоко сомневаюсь, что нечто подобное можно ничего не изобретая и не кодируя легко запустить на том же Оракле его стандартными средствами, особенно если учесть, что сеансы репликации могут идти с удаленных узлов в любой заявленной периодичностью (хоть раз в месяц или год).

vadiminfoИ врядли он от кого то отстает, а возможно в каких-то вопросах и опережает и, возможно, на года, включая самого ASA. В том числе и мобильные с нотебуками. И позиционировать его туда есть не тока толк, но и факт. У нас распределенные БД в некоторых проектах.
Вот чтобы решить, кто отстает, а кто впереди в данном секторе неплохо бы изучать конкурирующие в нем продукты. Я не спорю, что слабо знаю Оракл, но никто из знакомых специалистов по Ораклу смотря на наши решения на ASA еще не подписался на то, чтобы в короткое время мог бы развернуть аналогичные решения без существенных трудозатрат. Плюс можно назвать как дополнительный фактор - наоборот частенько глядя на ASA, они призадумываются и пишут руководству служебку о переводе удаленных офисов на ASA, мотивируя это низкой стоимостью сервера, нулевым администрированием, нетребовательностью к ресурсам, оффлайн репликациями и возможностью проводить оффлайн репликации с консолидированной БД в центральном офисе на Оракле. Очень кстати выгодный вариант получается в такой связке по многим параметрам, которые неплохо расписываются на бумаге.

vadiminfoЭто Вы поддались искушению пропаганды. Так нельзя. А то мы все начнем уподробляться вульгарным рекламщикам.
В том то и дело, что не поддался. Я не пытаюсь на ASA прокручивать террабайтные БД, она просто не потянет из за отстутствия множества необходимого функционала (пока во всяком случае). Однако в плане создания проектов, рассчитанных на сеть удаленных филиалов, подьем информации в центр и при желании интеграцию с существующими консолидированными БД даже других производителей (Oracle, MSSQL, DB2, Sybase ASE) этот сервер дает множество преимуществ по стоимости разработки и стоимости сопровождения таких проектов. У нас в FAQ лежит в PDF часть переведенного BOL для ASA по главе SQLRemote (оффлайн репликация ASA-ASA, хотя другой механизм репликации MobiLink, т.е. ASA-ДругойСУБД в принципе тоже самое). При желании всегда можно скачать и почитать, насколько все это легко выглядит при использовании ASA и уже самому зная Оракл сравнить, насколько и кто отстал в данном направлении ;)

Yo!!2ASCRUS

что-то память у вас короткая:
/topic/94750&pg=-1#739145
А что - там можно вводить область видимости движения информации по подписчикам (узлам), вешать триггеры на обработку конфликтов версий информации (например когда в консолидированной и удаленной БД была изменена одна и та же запись и в ходе репликации это обнаружилось), реплицировать на удаленные узлы любые операторы, в том числе и DDL ? На приведенной картиночке я просто пока вижу, что берутся логи работы одной БД и накладываются на другую, это не то, что называется репликацией в ASA.

Кстати хочу подчеркнуть достаточно важный ньюанс - говоря о репликациях в ASA и Оракле по всей видимости мы все таки имеет в виду достаточно разные термины и вещи.

Yo!! ASCRUS
А что - там можно вводить область видимости движения информации по подписчикам (узлам), вешать триггеры на обработку конфликтов версий информации (например когда в консолидированной и удаленной БД была изменена одна и та же запись и в ходе репликации это обнаружилось), реплицировать на удаленные узлы любые операторы, в том числе и DDL ? На приведенной картиночке я просто пока вижу, что берутся логи работы одной БД и накладываются на другую, это не то, что называется репликацией в ASA.

и еще тучу вещей которые сайбез не умеет. вы не торопитесь, перечитайте тот топик, там все есть, зачем повторятся ?
например опустите глаза на один топик и найдете такую ссылку:

http://zeus.sai.msu.ru:7000/database/oracle/streams/
Ну во первых в приведенной статье я не увидел ничего нового для репликаций ASA, так что Ваши утверждения, что в Sybase и в помине нет, по меньшей мере поспешны. Во вторых все равно я не увидел области видимости информации - фильтры увидел, да, не спорю. Но области видимости нет. Проверяется просто - например там есть фраза:
авторПричем эти правила используют содержимое элемента потока, т е мы можем указать, что в конкретный узел попадают только изменения для конкретных объектов. Кроме того, изменение, например, значения поля “Страна” в записи с “UK” на “Russia” приведет к тому, что эти изменения потекут и будут применены не в Англии, а в российских узлах.
Для ASA смена кода подписчика информации будет означать не только, что изменения теперь "потекут" в Россию, а и то, что при смене значения поля подписки без разницы на каком узле, на узел США пойдет команда DELETE для данной записи, а на Россию пойдет INSERT, то есть будет автоматически произведено физическое перемещение записей между узлами. Имелось ли в виду здесь тоже самое ?

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

Хотя я рад, что в Оракле наконец таки реализовали то, что в ASA успешно реализовано и работает уже более 10-и лет, причем по архитектуре и функционалу все отработано на крепкую пятерку. Единственное правда интересно, насколько долго все это настраивается. Например, буквально вчера меня попросили для одного моего проекта подключить новый удаленный узел в России, однако если до этого все узлы имели более менее стабильный канал связи и работают по выделенке, с этим узлом это оказалось проблематично и было принято решение первым его пустить по оффлайн репликациям (и скорее всего не последним). За пару часов я настроил на центральной БД подписку, сделал удаленного подписчика, выгрузил уже с консолидированной БД новую БД удаленного подписчика уже с необходимой структурой и данными под этот узел, с опциями работы репликации через наш FTP сервер, запустил на стенде, протестировал, что все работает, вместе с ASA, выгруженной БД и клиентской частью собрал в готовый инсталяционный пакет и завтра человек, который даже не является техническим специалистом поедет туда, запустит инсталяцию и покажет как работать с клиентским приложением, причем уложится на все про все в полдня. Мы же уже вступим в связь с сотрудниками данного узла сразу после установки системы через форумы, встроенные прямо в наше ПО, которые прекрасно работают через репликацию и позволяют операторам общаться с вышестоящими узлами и разработчиками из любых режимов программы, что очень удобно :)

Вдогонку - помимо самого механизма удаленных репликаций очень важно, чтобы сама архитектура БД позволяла гибкую реализацию репликаций - например в ASA есть глобальные счетчики, которые автоматически ведут инкрементные счетчики в разрезе заявленного кода БД и заявленного размера партиции для узлов по таблице, причем счетчики работают граммотно и не сбивают свой диапазон, когда в таблицу вставляются значения, не попадающие под разрез данного узла. Есть и соотвествующее событие, которое позволяет перехватить ситуацию переполнения счетчика и например, автоматически перевести код БД на новый свободный. На триггерах можно перехватывать конфликты обновлений версий записи, в которых можно увидеть какие поля записи конфликтуют и какие у них значения в консолидированной БД и записи, приехавшей из удаленной БД по репликации. И т.д. и т.п. - все встроено в архитектуру, все отработано, ни о чем думать не нужно, просто берем и пользуемся. Ко всему прочему это означает легкость в освоении - например, на обучение специалиста MSSQL основам ASA у меня уходит пару дней (обычно это привыкание к другому визуальному инструментарию, перечисление всего того, что нет в MSSQL, расширений WatcomSQL по сравнению с TSQL, отличий архитектуры самого сервера и различий в блокировочных механизмах). На обучение настройки репликации же вообще выходит пара часов, так как особо и учить не чего. Другое дело, что очень много времени уходит на обучение правильного проектирования БД, которая будет использоваться как консолидированная, так и удаленная БД и необходимо учесть все ньюансы.

Александр Гoлдун
vadiminfo пишет:

> Репликация через мыло - это, действительно, смешно.

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


Posted via ActualForum NNTP Server 1.2
Все дело в том, что я никак не могу ему обьяснить, что репликация в ASA пакетная, т.е. не требуется видеть другой сервер, а все с лога ложится в пакет, он криптуется, упаковывается, отсылается, другой сервер его получает через MAIL, FTP или файлы и в обратном порядке применяет как набор SQL операторов. Отсюда и странные выводы о том, что якобы транзакционная модель работать не будет и что все смешно :)

Yo!!непонял, у меня не один инсерт в секунду, вы который имеете ввиду, за какое время и т.п. ? через стримс можно весь таблеспейс переместить.
Вопрос о не перемещении информации, а об автоматическом обнаружении изменения области видимости информации и ее перемещении между БД узлов. Например у Вас есть яблоко, в консолидированной БД принято решение, что яблоко должно принадлежать мне, соотвествующе автоматически Вам из консолидированной БД будет послан оператор на удаление яблока, а мне на вставку.

Yo!!про 10 лет промолчу, помню уже смеялись, а вот про архитектуру спрошу. как сайбез захватывает изменения ? по старинке тригерами ?
Про Sybase ничего не знаю, у СУБД ASA репликации 10 лет прекрасно работают (с 95-ого года, вот ссылочка ). Насчет триггеров не очень понял - изначально репликация по жизни работала по лог-файлу, откуда "по старинке" триггера взялись то ?

авторпросьба свои слова хоть раз подкрепить ссылкой на технический ресурс
Да я вроде много раз давал ссылки:
SQLRemote по русски для 8-ой версии
Техническое описание ASA9 - там расписаны futures на 2 вида репликации и Application Messages API для передачи еще чего то помимо самих данных. Да и еще куча продуктов, ориентированных на удаленные узлы - тоже оффлайн администрирование станций и КПК.