Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 10 11 12 13 14 [15] 16 17 18 19 .. 21   вперед  Ctrl
 Re: Oracle vs MS SQL?  [new]
Apex
Member

Откуда: Made in USSR
Сообщений: 3910
pkarklin
[f these transactions are not replicated in a timely manner, they can prevent the truncation of the log.

Ну я так понимаю в этом и проблема, не?
13 дек 12, 10:14    [13623741]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL?  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4919
Блог
pkarklin
Alexander Ryndin
а в MSSQL хоть тресни никуда ты этот REDO без починенной репликации не унесешь.

А в этой модели (в принципе аналогичной MS SQL, где в качестве "очереди" используется бд distribution):
Нет. Не аналогична ни разу. Что будет, если встанет бд distribution? Эту distribution нужно лицензировать?
Зачем мне distribution, если у меня всего 2 сервера (биллинг и репортинг)?

Ну и раз уж мы заговорили про репликацию, то в Oracle архивные журналы(заметьте не измененные данные, а именно журналы) можно выкидывать (руками или средствами СУБД, при переключения журнала или в режиме потока с нулевой задержкой) на соседний сервер СУБД, где из этих журналов будут извлечены изменения. Так можно делать и в GoldenGate, и в Streams. На нагруженных СУБД именно так и делают, потому как никому не нужна дополнительная нагрузка на боевом сервере.

А вот репликация MSSQL и MSSQL CDC делает с точки зрения неприкосновенности священной коровы боевого сервера особенно страшные вещи. Первая, насколько я понимаю, использует что-то типа внутренних триггеров. Вторая пишет изменения в таблицу CDC внутри СУБД MSSQL (тем самым увеличивая объем журналов источника, поскольку эти таблички тоже журналируются)
13 дек 12, 10:23    [13623793]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL?  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4919
Блог
pkarklin
Yo.!
арклоги базе не нужны, они нужны только для рестора или для накатывания на стендбай. базе побарабану если вы их будете уносить на /dev/null сразу после создания.


Как отреагирует на этот унос реплакация в Oracle, если данные из них еще недоставлены до "очереди"?
Для репликации Oracle их можно положить хоть на удаленный сервер по NFS. Их, кстати, туда обычно всегда кладут параллельно с локальными дисками. Это позволяет восстановить данные с минимальной потерей даже в случае локальной ядерной бомбы, попавшей в сервер. А вот для MSSQL придется танцевать с backup, работающим каждые 15 минут.
13 дек 12, 10:28    [13623818]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL?  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Apex
Ну я так понимаю в этом и проблема, не?


Именно об этой "проблеме" говорил Yo.!, упоминая о пухнущем логе. Как оказалось, от падения процесса streams в Oracle тоже есть проблемы.
13 дек 12, 10:29    [13623830]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL?  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4919
Блог
pkarklin
Apex
Ну я так понимаю в этом и проблема, не?


Именно об этой "проблеме" говорил Yo.!, упоминая о пухнущем логе. Как оказалось, от падения процесса streams в Oracle тоже есть проблемы.
1) Архивные журналы могут лежать не на быстрых, очень дорогих (помним о латентности журнала) дисках, а в дешевой корзине. Ну и плюс копия в сетевой корзине. Согласитесь процесс копирования файла гораздо проще, чем извлечение изменений из этих журналов.
2) Ну и я всегда могу решить, что реплика не так важна и руками убить журналы, если не хватает места. А такой аварийный стоп-кран для биллинга всегда должен быть предусмотрен. Ведь биллинг - это, в первую очередь, база для честного отъема денег, а всякие репортинги, хранилища - они могут и подождать
13 дек 12, 10:36    [13623883]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL?  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Alexander Ryndin,

автор
Нет. Не аналогична ни разу. Что будет, если встанет бд distribution? Эту distribution нужно лицензировать?
Зачем мне distribution, если у меня всего 2 сервера (биллинг и репортинг)?


Действительно. Ну Вы подумайте какая связь?! Yo.! привел пример, когда упавшая репликация может помешать очистке файла лога. Попытка выяснить об аналогичной конфигурации в Oracle привела к тому, что падение процесса начитки изменений так же приводит к проблеме. Что будет, если встанет бд distribution, я даже процитировал. Лицензируются не базы. Действительно, зачем Вам distribution и транзакционная репликация, если достаточно Log Shippingа?!

автор
Ну и раз уж мы заговорили про репликацию, то в Oracle архивные журналы(заметьте не измененные данные, а именно журналы) можно выкидывать (руками или средствами СУБД, при переключения журнала или в режиме потока с нулевой задержкой) на соседний сервер СУБД, где из этих журналов будут извлечены изменения. Так можно делать и в GoldenGate, и в Streams. На нагруженных СУБД именно так и делают, потому как никому не нужна дополнительная нагрузка на боевом сервере.


Это аналог озвученного выше Log Shippinga и ниразу не похоже на транзакционную репликацию в MS SQL.

автор
А вот репликация MSSQL и MSSQL CDC делает с точки зрения неприкосновенности священной коровы боевого сервера особенно страшные вещи. Первая, насколько я понимаю, использует что-то типа внутренних триггеров. Вторая пишет изменения в таблицу CDC внутри СУБД MSSQL (тем самым увеличивая объем журналов источника, поскольку эти таблички тоже журналируются)


Неправильно думаете. Ни про первую, ни про вторую. Чтобы думать правильно достаточно было прочитать в моей цитате о Log Reader Agent и в документации про CDC, который ни на каких триггерах не строится.

Change data capture enables the capture of changes in the source system by asynchronously reading the transaction log of the source database. For this, change data capture uses the same log reader that is used in transactional replication. Because change data capture works on existing table schemas, the source database or application doesn’t need to be changed to enable change data capture. Because the log reader job works asynchronously, DML transactions are far less impacted than with synchronous solutions like triggers. All changes to the source tables are recorded in special change tables, so no comparison between source and target system for changes is needed.

автор
Вторая пишет изменения в таблицу CDC внутри СУБД MSSQL (тем самым увеличивая объем журналов источника, поскольку эти таблички тоже журналируются)


У Вас есть этому подтверждение?
13 дек 12, 11:06    [13624081]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL?  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Alexander Ryndin
1)Архивные журналы могут лежать не на быстрых, очень дорогих (помним о латентности журнала) дисках, а в дешевой корзине. Ну и плюс копия в сетевой корзине. Согласитесь процесс копирования файла гораздо проще, чем извлечение изменений из этих журналов.


Аналогичная картина и для Log Shippingа в MS SQL. Бэкапы лога могут лежать где угодно и копироваться куда угодно. И лог шиппинг не имеет никакого отношения к проблемме с падением транзакционной репликации и неочисткой лога, ибо при лог шиппинге такой проблемы просто не существует. Но вы, почему то упорно протипостовляете теплое мягкому.

Alexander Ryndin
2) Ну и я всегда могу решить, что реплика не так важна и руками убить журналы, если не хватает места. А такой аварийный стоп-кран для биллинга всегда должен быть предусмотрен. Ведь биллинг - это, в первую очередь, база для честного отъема денег, а всякие репортинги, хранилища - они могут и подождать


Я сильно удивлюсь, что на биллинговую бд кто-то будет навешивать транзакционную репликацию. Для целей репортинга достаточно логшиппинга, который априори не имеет озвученных проблем с неочисткой лога.
13 дек 12, 11:19    [13624174]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL?  [new]
Yo.!
Guest
pkarklin
Попытка выяснить об аналогичной конфигурации в Oracle привела к тому, что падение процесса начитки изменений так же приводит к проблеме.

не совсем понял почему такое пристальное внимание к репликации, ведь это лишь одна из тысячи причин по которой лог мсскл может разбухнуть. я встречал разбухший лог без всяких репликаций.
на счет оракловой стримс репликации. тут есть громадная разница с мсскл в том плане, что залипшая репликация мсскл вполне штатная ситуация. типа пропала связь, репликация в половине случаев залипает. никакого форсмажера, нормальное поведение. в оракле же вычитка REDO системный процесс и не зависит от внешних баз, если он упал это что-то экстраординарное. значит какой-то косяк с железом, типа память битая либо баг, который нужно патчиком лечить. т.е. ставить равенство между залипание в мсскл и крахе системного процесса в оракле нельзя.
13 дек 12, 11:24    [13624207]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL?  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Yo.!
не совсем понял почему такое пристальное внимание к репликации, ведь это лишь одна из тысячи причин по которой лог мсскл может разбухнуть. я встречал разбухший лог без всяких репликаций.


Ну, тогда, м.б. следует привести одну из той другой тысячи. Ибо обычно эта причина в 1001 раз означает, что некто не разобрался с моделями восстановления и у него пухнет лог.


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


Это (падение Log Reader) внештатная ситуация, которая отслеживается и предпринимается попытка перезапуска. И бд distribution обычно лежит на том же сервере и в случае потери связи с подписчиком пухнет она, а не лог основной бд.
13 дек 12, 11:31    [13624255]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL?  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4919
Блог
pkarklin
Alexander Ryndin,
автор
Нет. Не аналогична ни разу. Что будет, если встанет бд distribution? Эту distribution нужно лицензировать?
Зачем мне distribution, если у меня всего 2 сервера (биллинг и репортинг)?
Действительно. Ну Вы подумайте какая связь?! Yo.! привел пример, когда упавшая репликация может помешать очистке файла лога. Попытка выяснить об аналогичной конфигурации в Oracle привела к тому, что падение процесса начитки изменений так же приводит к проблеме. Что будет, если встанет бд distribution, я даже процитировал. Лицензируются не базы. Действительно, зачем Вам distribution и транзакционная репликация, если достаточно Log Shippingа?!
Насколько я знаю в этом случае сервер репортинга
1) будет полной копией основного. А в репортинге (там ведь задачи слегка другие) - хотелось бы иметь немного другие индексы, не все данные с основной системы
2) Supports limited read-only access to secondary databases (during the interval between restore jobs). Хехе. Так это даже не Active Data Guard, позволяющий делать restore и читать данные одновременно.
3) открыт на запись в лучшем случае на чтение. Большинство отчетных и bi-систем хотят что-то писать в репортинг. Минимум метаданные - максимум промежуточные и конечные результаты.
pkarklin
автор
А вот репликация MSSQL и MSSQL CDC делает с точки зрения неприкосновенности священной коровы боевого сервера особенно страшные вещи. Первая, насколько я понимаю, использует что-то типа внутренних триггеров. Вторая пишет изменения в таблицу CDC внутри СУБД MSSQL (тем самым увеличивая объем журналов источника, поскольку эти таблички тоже журналируются)
Неправильно думаете. Ни про первую, ни про вторую. Чтобы думать правильно достаточно было прочитать в моей цитате о Log Reader Agent и в документации про CDC, который ни на каких триггерах не строится.

Change data capture enables the capture of changes in the source system by asynchronously reading the transaction log of the source database. For this, change data capture uses the same log reader that is used in transactional replication. Because change data capture works on existing table schemas, the source database or application doesn’t need to be changed to enable change data capture. Because the log reader job works asynchronously, DML transactions are far less impacted than with synchronous solutions like triggers. All changes to the source tables are recorded in special change tables, so no comparison between source and target system for changes is needed.
Ок, про триггеры я поторопился. Но то, что на каждый INSERT в источнике репликации мы получаем второй INSERT в CDC-таблицу (а в случае с UPDATE имеем 2 INSERTа со значениями BEFORE и AFTER ) в базу-источник. Поверьте, админы биллинга вас с лестницы спустят за такое самоуправство. Нам они не позволяют ничего делать не то что в СУБД, а даже на сервере источника репликации. Архивные журналы на другом сервере в папочку складывают и крутись как хочешь.
pkarklin
автор
Вторая пишет изменения в таблицу CDC внутри СУБД MSSQL (тем самым увеличивая объем журналов источника, поскольку эти таблички тоже журналируются)
У Вас есть этому подтверждение?
Подтверждения этому нет, но это логично, иначе, как обеспечивается сохранность захваченных данных? Справедливости ради нужно сказать, что Oracle умеет не журналировать изменения в очередях сообщений, в которых хранит данные для репликации, но там есть специальный, описанный механизм. В MSSQL я такого механизма не знаю - ткните в документацию
13 дек 12, 11:32    [13624260]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL?  [new]
OYM
Member

Откуда:
Сообщений: 236
Yo.!
pkarklin
Попытка выяснить об аналогичной конфигурации в Oracle привела к тому, что падение процесса начитки изменений так же приводит к проблеме.

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


Действительно хотелось бы услышать какая вторая массовая причина не позволяющая логу "очиститься".
13 дек 12, 11:51    [13624407]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL?  [new]
OYM
Member

Откуда:
Сообщений: 236
pkarklin
Василий Бенедиктович
прекрати троллить. почитай концепции, потом про стримсы и т. п..


А зачем читать?! Yo.! же сказал, что база встанет раком.


А если базу tempdb положить на RAID 10 из 10 дисков SAS 15KИ разделить ее на 8 файлов, а сам лог tempdb положить на отдельный массив RAID 1. База в этом случае также встанет колом или все таки шансы есть? Тем более Вы написали, что если используется режим снэпшота только для чтения "зафиксированных" данных, то tempdb не будет подвергаться сильной нагрузке.
13 дек 12, 11:54    [13624447]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL?  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4919
Блог
OYM
pkarklin
пропущено...


А зачем читать?! Yo.! же сказал, что база встанет раком.


А если базу tempdb положить на RAID 10 из 10 дисков SAS 15KИ разделить ее на 8 файлов, а сам лог tempdb положить на отдельный массив RAID 1. База в этом случае также встанет колом или все таки шансы есть? Тем более Вы написали, что если используется режим снэпшота только для чтения "зафиксированных" данных, то tempdb не будет подвергаться сильной нагрузке.
Смешивание temp и undo - очень плохая идея. Может в MSSQL и не так (хотелось бы услышать как), но в Oracle при backup открытой базы данных мы делаем также резервную копию UNDO. Это связано с тем, что при неполном восстановлении транзакций, которые были активны во время backup, нужно откатить. А откатывать их можно только из ранее сохраненных версий данных.


P.S. Кстати, мне кажется, pkarklin когда-то говорил, что используется не tempdb, а многострадальный log.
13 дек 12, 12:01    [13624510]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL?  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4919
Блог
... что при неполном восстановлении транзакций, которые были активны во время backup, нужно откатить...
читать как
... что при неполном восстановлении нужно откатить транзакции, которые были активны во время backup...
13 дек 12, 12:03    [13624523]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL?  [new]
Василий Бенедиктович
Guest
pkarklin,

я ответ получу на свой вопрос? (см. выше)

пс. может не стоит спорить об оракле, если не понимаешь даже что такое архивлог. и как логирование устроено в оракле.
13 дек 12, 12:10    [13624575]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67463
Блог
OYM
Как минимум 7 отдают предпочтения МС, из-за легкости хотя установки.
А notepad-у - за то, что он уже идёт в комплекте, верно?
13 дек 12, 12:14    [13624596]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL?  [new]
Василий Бенедиктович
Guest
товарищи мсскл'щики проясните ситуацию, что вы называете фразой - вычищается лог.

а то на фоне ораклового у меня как минимум кислая мина когда читаю такую фразу.

пс. не надоело сравнивать карьерный самосвал и маршрутную газель?

на вскидку приведите аналогии в мсскл:

streams,
physical standby,
active data guard,
rac (планирую словить море лулзов с примеров аналогов),
times ten,
...
13 дек 12, 12:19    [13624657]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL?  [new]
andy st
Member

Откуда:
Сообщений: 899
Yo.!
...тут есть громадная разница с мсскл в том плане, что залипшая репликация мсскл вполне штатная ситуация. типа пропала связь, репликация в половине случаев залипает....

Поднятая на MSSQL 2K SP3 в 2004 году обновляемая транзакционная репликация с отложенным обновлением на туеву хучу узлов работает и по сей день и слово "залипшая" при её описании ни разу за эти годы не встречалось. Видать что-то не так сделали... :(
13 дек 12, 12:19    [13624665]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL?  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4919
Блог
А еще, как оказалось, MSSQL в лог не пишет имя пользователя, который изменял данные.
Т.е. фиг поймешь, какой из админов начислил 10.000 людей по 1000$. Триггеры вешать не вариант - биллинг все таки. ;)
13 дек 12, 12:22    [13624687]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL?  [new]
Василий Бенедиктович
Guest
мсскл'щики ушли изучать матчасть и искать АНАЛ'оги в интырнэт. =D
13 дек 12, 12:37    [13624834]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL?  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Василий Бенедиктович
мсскл'щики ушли изучать матчасть и искать АНАЛ'оги в интырнэт. =D


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

ЗЫ. Успокойтесь, Вы нервничаете, значит Вы не правы.
13 дек 12, 12:44    [13624881]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL?  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Василий Бенедиктович
я ответ получу на свой вопрос? (см. выше)


На какой? Тынц можно?

Василий Бенедиктович
пс. может не стоит спорить об оракле, если не понимаешь даже что такое архивлог. и как логирование устроено в оракле.


Можно тынц, где я о чем то спорил, "как это в Oracle", а не спрашивал об аналогичности или отличии функционала\поведения?
13 дек 12, 12:46    [13624897]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL?  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Василий Бенедиктович
на вскидку приведите аналогии в мсскл:...


Будьте проще. Ждем аналоги SELECT TOP (N), NEXT VALUE FOR <sequence name> в DEFAULT и в INSERT ... SELECT, SET TRANSACTION ISOLATION LEVEL SERIALIZABLE, наконец.
13 дек 12, 12:50    [13624931]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL?  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
OYM
А если базу tempdb положить на RAID 10 из 10 дисков SAS 15KИ разделить ее на 8 файлов, а сам лог tempdb положить на отдельный массив RAID 1. База в этом случае также встанет колом или все таки шансы есть? Тем более Вы написали, что если используется режим снэпшота только для чтения "зафиксированных" данных, то tempdb не будет подвергаться сильной нагрузке.


Если рост tempdb (из-за занятости) упрется в размер дискового пространства то встанут все транзакции, требующие версий и вся работа, требующая временных объектов.

ЗЫ. Для примера. Высоконагруженная OLTP бд с включенной версионностью за 1 Tb имеет tempdb из 8ми файлов по 8мь Gb. Правда я не знаю, как они размазаны по 168 дискам.
13 дек 12, 12:54    [13624961]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs MS SQL?  [new]
OYM
Member

Откуда:
Сообщений: 236
Alexander Ryndin
OYM
пропущено...


А если базу tempdb положить на RAID 10 из 10 дисков SAS 15KИ разделить ее на 8 файлов, а сам лог tempdb положить на отдельный массив RAID 1. База в этом случае также встанет колом или все таки шансы есть? Тем более Вы написали, что если используется режим снэпшота только для чтения "зафиксированных" данных, то tempdb не будет подвергаться сильной нагрузке.
Смешивание temp и undo - очень плохая идея. Может в MSSQL и не так (хотелось бы услышать как), но в Oracle при backup открытой базы данных мы делаем также резервную копию UNDO. Это связано с тем, что при неполном восстановлении транзакций, которые были активны во время backup, нужно откатить. А откатывать их можно только из ранее сохраненных версий данных.


P.S. Кстати, мне кажется, pkarklin когда-то говорил, что используется не tempdb, а многострадальный log.


А чем плоха идея? Ну хранятся себе версии строк и времянки на диске в одной логической структуре, а в Оракле в 2 разных логических структурах (и из-за этого жесткий диск с UNDO начинает работать с бешенной скоростью?). Или Вы о том, что в Оракле вы гарантированно можете все разнести по разным дискам? Это можно обойти, имея 10 шпинделей для tempdb
13 дек 12, 12:55    [13624971]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 10 11 12 13 14 [15] 16 17 18 19 .. 21   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить