Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 61 62 63 64 65 [66] 67 68 69 70 .. 72   вперед  Ctrl
 Re: Access и FoxPro. Сравнение мощей  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
1024

просто не фурычат..". Они ни при каких не фурычат. Если система на 500000
записей умудрилась сделать пол-коммита, то это не значит, что при меньших
объемах все будет нормально. Не будет. Все будет точно так же плохо, только
с меньшей вероятностью. Отмазки типа "по 500000 записей никто не вставляет"
оставьте детсадовцам. Большой объем данных в эксперименте был нужен не для
того, чтобы ошибка возникла, а для того, чтобы эту ошибку за хвост поймать.
Так сказать не по щучьему веленью, а по
------------


нелогично. На атомобиле можно перевести тонну груза. Если грузить его тремя
тоннами то возможно повышение износа узлов автомобля. Но если нагрузить его
ста тоннами груза он не сдвинется с места. Вывод - автомобили не
предназначены для перевозки грузов


Переход количества в качество. В школе проходили.


Posted via ActualForum NNTP Server 1.3

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

Что же до поломки базы - ну да, может сломаться. Любая. Речь не про то.

Конечно, если база сломана, то нелепо требовать от сломанной базы обеспечение ACID. У каждой СУБД есть "штатный" режим работы. Однако если "отвал клиента" для фокса является настолько серьезной поломкой, что фокс даже атомарность транзакций не может обеспечить - значит транзакций в фоксе нет. Потому что любой клиент может отвалиться в любой момент. А любая транзакция может оказаться неатомарной, т.е. не транзакцией. Независимо от количества модифицированных записей.
23 мар 06, 16:19    [2482404]     Ответить | Цитировать Сообщить модератору
 Re: Access и FoxPro. Сравнение мощей  [new]
H5N1
Guest
Aki
Только давай по честному :-)

ты сам код теста на ВФП не придумывал - почерпнул тут готовый == дай мне код для Оракла = проверю очевидное если найду время


и кто ж мне тут код придумал !? местные лисоводы документацию несмогли прочесть, не то что код написать.
код для оракла: update table1 set column1='H5N1' ;

Aki

негоже человеку, который страниц надцать назад, говорил, что Мелкософт нагло врет в своих доках, ссылаться на какой-то www.tpc.org


что-то непонял, вы не знаете что такое tpc.org ? в tpc участвуют все крупнейшие производители rdbms, найди оракл хоть один глючек в транзакциях mssql (или наоборот) он бы такой шум поднял. а вот байки в msdn публиковать майкрософту никто не заприщает, на tpc у мс такой номер уже не пройдет, конкуренты непозволят, в этом и гарантия.
откройте отчет, хотя бы этот: http://tpc.org/results/FDR/TPCC/hp_tpcc_rx4640_fdr.pdf
почитайте, вам будет полезно
4 CLAUSE 3 RELATED ITEMS............................................................................................................................. 4-1
4.1 TRANSACTION SYSTEM PROPERTIES (ACID)..................................................................................................... 4-1
4.2 ATOMICITY ....................................................................................................................................................... 4-1
4.2.1 Completed Transaction 4-1
4.2.2 Aborted Transaction 4-1
4.3 CONSISTENCY ................................................................................................................................................... 4-1
4.4 ISOLATION ........................................................................................................................................................ 4-2
4.4.1 Isolation Test 1 4-3
4.4.2 Isolation Test 2 4-3
4.4.3 Isolation Test 3 4-3
4.4.4 Isolation Test 4 4-4
4.4.5 Isolation Test 5 4-4
4.4.6 Isolation Test 6 4-5
4.4.7 Isolation Test 7 4-5
4.4.8 Isolation Test 8 4-5
4.4.9 Isolation Test 9 4-6
4.5 DURABILITY...................................................................................................................................................... 4-6
4.5.1 Loss of Log and Data Disks 4-7
4.5.2 Instantaneous Interruption and Loss of Memory 4-8
23 мар 06, 16:25    [2482458]     Ответить | Цитировать Сообщить модератору
 Re: Access и FoxPro. Сравнение мощей  [new]
1024
Member

Откуда: Нижний Новгород
Сообщений: 14267

записях нужно ловить. Я так думаю.
-------------------------
очень хорошая дописка. Многие почему-то так не делают




работы. Однако если "отвал клиента" для фокса является настолько серьезной
поломкой, что фокс даже атомарность транзакций не может обеспечить - значит
транзакций в фоксе нет. Потому что любой клиент может отвалиться в любой
момент. А любая транзакция может оказаться неатомарной, т.е. не транзакцией.
Независимо от количества модифицированных записей.
--------------------------------------
речь шла про транзакции в дбф.

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




Posted via ActualForum NNTP Server 1.3

23 мар 06, 16:32    [2482510]     Ответить | Цитировать Сообщить модератору
 C++/Linux/FireBird  [new]
f_w_p
Member

Откуда:
Сообщений: 1603
1024
да фокспрошники тоже не говорят вроде о том что транзакции на дбф
предоставляют надёжность сравнимую с орклом. Сравнимую с MySQL или
Firebird - да.

Ну насчет MySQL пожалуй соглашусь. Надежность танзакций одинаковая, т.е. их полное отсутствие. А вот насчет FireBird вы пожалуй погорячились... Повыше у него надежность, повыше. Несоизмерима выше.
23 мар 06, 16:35    [2482542]     Ответить | Цитировать Сообщить модератору
 Re: Access и FoxPro. Сравнение мощей  [new]
H5N1
Guest
1024
мне ...[удалено модератором]
23 мар 06, 16:36    [2482544]     Ответить | Цитировать Сообщить модератору
 Re: Access и FoxPro. Сравнение мощей  [new]
Ц4
Guest
1024

В любом сервере можно
отключить средства обеспечивающие откат транзакций и проделать тоже самое.


Можно соответствующий скрипт для Oracle и MSSQL посмотреть?
23 мар 06, 16:36    [2482545]     Ответить | Цитировать Сообщить модератору
 Re: Access и FoxPro. Сравнение мощей  [new]
1024
Member

Откуда: Нижний Новгород
Сообщений: 14267

H5N1

----------
напрягаешь


Posted via ActualForum NNTP Server 1.3

23 мар 06, 16:42    [2482603]     Ответить | Цитировать Сообщить модератору
 Re: Access и FoxPro. Сравнение мощей  [new]
Justanotherguest
Guest
По поводу транзакционных войн. Вопрос знатокам Access - Пьяному Лоху и IgorM
Ситуация: Одна из клиентских сессий вывалилась посреди Commit. При последующем открытии базы Access, я так понимаю, сравнивает запись в заголовке базы о том, что присходила физ. запись в базу и инфу в ldb-файле о соответсвующей блокировке. Если не совпадает - то сообщение "Database is corrupted". Но что просиходит с работающими параллельно при этом падении? Они-то могут читать частично закомитченные данные? Или нет? Если могут, то вся защита Access летит в тартарары - за время их работы можно внести полную несусветицу в базу. И еще вопрос - кто флаг о физ. записи в заголовке снимает? Если 2-я сессия, парралельно работавшая в вылетевшей 1-й успешно закомитчила свои данные - она снимает этот флаг? Проводит ли тогда Access какие-либо проверки -ведь флага в заголовке уже нет - его сняли? И еще, что происходит если флаг в загловке стоит, а ldb-файл удален/испорчен?
23 мар 06, 16:43    [2482611]     Ответить | Цитировать Сообщить модератору
 Re: C++/Linux/FireBird  [new]
H5N1
Guest
f_w_p

Ну насчет MySQL пожалуй соглашусь. Надежность танзакций одинаковая, т.е. их полное отсутствие. А вот насчет FireBird вы пожалуй погорячились... Повыше у него надежность, повыше. Несоизмерима выше.


неа, у mysql innodb (oracle innodb ) есть бинарный лог, куда и пишется транзакция, т.е. в этом плане гораздо "круче" безлогово firebird. firebird же пишет в датафайл рядом со старой записью и только по комиту отмечает одним движением, что транзакция закомичена. тем самым добивается ACID.
23 мар 06, 16:45    [2482631]     Ответить | Цитировать Сообщить модератору
 Re: Access и FoxPro. Сравнение мощей  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
2 1024
В любом сервере можно
отключить средства обеспечивающие откат транзакций и проделать тоже самое.
На достаточно большом обёме либо поломаются сами файлы либо будет
неоткаченная транзакция. Вывод - ни в одном сервере транзакций нет, даже в
оракле. Можно ставить опыты.

Гыыыы... Ну да, если все транзакционные механизмы поотключать - то транзакций не будет. Кто б спорил. А если включить - то транзакции будут.
В фоксе можно что-то включить/выключить? Или там перманентно транзакций нет?

------------------------

2 f_w_p
Ну насчет MySQL пожалуй соглашусь. Надежность танзакций одинаковая, т.е. их полное отсутствие.

А что, в MySQL тоже пол-коммита бывает?
Даже если так, то все равно надежность MySQL повыше, ибо у него нормальным ("штатным") режимом работы СУБД является бесперебойная работа одного выделенного компутера (сервера), а для фокса необходима бесперебойная работа всех компутеров да еще и нормальная безглючная работа локальной сети, а иначе беда, беда, огорчение, транзакции неатомарными становятся.
23 мар 06, 16:47    [2482648]     Ответить | Цитировать Сообщить модератору
 Re: Access и FoxPro. Сравнение мощей  [new]
Sergey Ch
Member

Откуда: Благовещенск
Сообщений: 8894
Пьяный Лох
...а для фокса необходима бесперебойная работа всех компутеров да еще и нормальная безглючная работа локальной сети...

Не обязательно - можно все хранить на сервере а обращаться через Web Service (COM) или терминал... Тогда траназакции будут атомарными...
23 мар 06, 16:50    [2482683]     Ответить | Цитировать Сообщить модератору
 Re: Access и FoxPro. Сравнение мощей  [new]
H5N1
Guest
Sergey Ch

Не обязательно - можно все хранить на сервере а обращаться через Web Service (COM) или терминал... Тогда траназакции будут атомарными...


ага, на "типа сервере" заведется барабашка и станет откатывать неудачные транзакции
23 мар 06, 16:53    [2482701]     Ответить | Цитировать Сообщить модератору
 Re: C++/Linux/FireBird  [new]
f_w_p
Member

Откуда:
Сообщений: 1603
H5N1
неа, у mysql innodb (oracle innodb ) есть бинарный лог, куда и пишется транзакция, т.е. в этом плане гораздо "круче" безлогово firebird. firebird же пишет в датафайл рядом со старой записью и только по комиту отмечает одним движением, что транзакция закомичена. тем самым добивается ACID.

Ну БД на innodb это как бы не совсем MySQL:-)).
23 мар 06, 16:53    [2482702]     Ответить | Цитировать Сообщить модератору
 Re: Access и FoxPro. Сравнение мощей  [new]
1024
Member

Откуда: Нижний Новгород
Сообщений: 14267

режимом работы СУБД является бесперебойная работа одного выделенного
компутера (сервера),
--------------

так на дбф тоже всё откатывается если по сети работает. Ломается когда валят
сервер на котором файлы лежат.


Posted via ActualForum NNTP Server 1.3

23 мар 06, 16:54    [2482706]     Ответить | Цитировать Сообщить модератору
 Re: Access и FoxPro. Сравнение мощей  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
2 Justanotherguest
По поводу транзакционных войн. Вопрос знатокам Access - Пьяному Лоху и IgorM
Ситуация: Одна из клиентских сессий вывалилась посреди Commit. При последующем открытии базы Access, я так понимаю, сравнивает запись в заголовке базы о том, что присходила физ. запись в базу и инфу в ldb-файле о соответсвующей блокировке. Если не совпадает - то сообщение "Database is corrupted".

Да ничего там никто не сравнивает.
Пресловутое "database is corrupted" - это один бит в заголовке.

Но что просиходит с работающими параллельно при этом падении? Они-то могут читать частично закомитченные данные? Или нет?

Нет. На моей практике не было замечено использование "частично закомитченных данных", специально воспроизвести не удавалось. По факту, гарантированно получить "database is corrupted" в результате срубания транзакции - проблематично. Мне способы неизвестны.

Ложка дегтя. Падение базы может произойти в момент, когда у базы индексы всевозможные перестраивались (в результате внесенных изменений). Тогда, хоть данные и "нормальные" (либо все, либо никаких нет), нормальная работа все-таки нарушена будет. До восстановления базы, разумеется.
23 мар 06, 17:01    [2482759]     Ответить | Цитировать Сообщить модератору
 Re: Access и FoxPro. Сравнение мощей  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
Sergey Ch
Пьяный Лох
...а для фокса необходима бесперебойная работа всех компутеров да еще и нормальная безглючная работа локальной сети...

Не обязательно - можно все хранить на сервере а обращаться через Web Service (COM) или терминал... Тогда траназакции будут атомарными...

Можно, все можно...
Только зачем?

Зачем брать изначально ненадежный ФС, а потом для повышения надежности к нему прикручивать веб-сервисы и/или терминальные сервисы, если можно сразу всять более надежный КС? Зачем делать пули из говна, когда уже есть пули из свинца?

З.Ы. Зато свинцом огороды плохо удобрять.
23 мар 06, 17:05    [2482789]     Ответить | Цитировать Сообщить модератору
 Re: Access и FoxPro. Сравнение мощей  [new]
1024
Member

Откуда: Нижний Новгород
Сообщений: 14267

Нет. На моей практике не было замечено использование "частично закомитченных
данных"
--------------
у многих тут аналогично




, специально воспроизвести не удавалось. По факту, гарантированно получить
"database is corrupted" в результате срубания транзакции - проблематично.
Мне способы неизвестны.
---------------
выдернуть шнур при вставке 500тыс.записей в одну транзакцию. Воспроизодить
на одной машине (не по сети)


Posted via ActualForum NNTP Server 1.3

23 мар 06, 17:06    [2482793]     Ответить | Цитировать Сообщить модератору
 Re: Access и FoxPro. Сравнение мощей  [new]
Justanotherguest
Guest
Пьяный Лох

И все же, "на моей практике не было замечено использование "частично закомитченных данных", специально воспроизвести не удавалось", согласитесь, - это не ответ. Commit физически пишет в базу, клиент вырубается. Кто откатывает частично записанные данные, кто не дает их читать параллельно работающим юзерам? Я не совсем понимаю этот механизм
23 мар 06, 17:09    [2482826]     Ответить | Цитировать Сообщить модератору
 Re: Access и FoxPro. Сравнение мощей  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
2 1024
По факту, гарантированно получить
"database is corrupted" в результате срубания транзакции - проблематично.
Мне способы неизвестны.
---------------
выдернуть шнур при вставке 500тыс.записей в одну транзакцию. Воспроизодить
на одной машине (не по сети)

Да не падает аксес на таких операциях. И на миллионах не падает. И пол-коммита не делает.
23 мар 06, 17:15    [2482868]     Ответить | Цитировать Сообщить модератору
 Re: Access и FoxPro. Сравнение мощей  [new]
1024
Member

Откуда: Нижний Новгород
Сообщений: 14267

Да не падает аксес на таких операциях. И на миллионах не падает. И
пол-коммита не делает.
-------------------

мне почему-то кажется что если отрубить питание то падает всё. Повреждается
ли при этом файл базы данных? Не проверял. Лично моё мнение что в такой
ситуации велика вероятность повреждения любого файла или даже файловой
системы. Зависит от железа во многом.


Posted via ActualForum NNTP Server 1.3

23 мар 06, 17:19    [2482880]     Ответить | Цитировать Сообщить модератору
 Re: Access и FoxPro. Сравнение мощей  [new]
Aki
Guest
H5N1
Aki
Только давай по честному :-)

ты сам код теста на ВФП не придумывал - почерпнул тут готовый == дай мне код для Оракла = проверю очевидное если найду время


и кто ж мне тут код придумал !? местные лисоводы документацию несмогли прочесть, не то что код написать.
код для оракла: update table1 set column1='H5N1' ;


м-дя.. мы явно друг друга не понимаем
Ты не тот код привел!!!
ты мне скажи как поймать момент, когда шнурок выдернуть!!!!
Тут не СКЛ знать нужно.. а некиеньюансы, коих я не знаю увы....


H5N1

что-то непонял, вы не знаете что такое tpc.org ? в tpc участвуют все крупнейшие производители rdbms, найди оракл хоть один глючек в транзакциях mssql (или наоборот) он бы такой шум поднял. а вот байки в msdn публиковать майкрософту никто не заприщает,


я ни коим образом не ставлю в сомнение tpc.org
просто =
в tpc участвуют все крупнейшие производители rdbms
не напоминает предвыборное "у нас есть план поднятия экономики" ?
Это я так.. к словоблудию
23 мар 06, 17:21    [2482891]     Ответить | Цитировать Сообщить модератору
 Re: Access и FoxPro. Сравнение мощей  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
Justanotherguest
Пьяный Лох

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

Зато это честный "неответ".
Я - не наблюдал, хотя экспериментов проводил туеву хучу. И с отрубанием питания, и с выдиранием сетевых шнурков, и со срубанием процессов, и локально, и по сети, и большие транзакции, и маленькие, и над одной базой транзакции, и распределенные транзакции. У меня - пол-коммита не было. За всех остальных ничего сказать не могу.

Justanotherguest

Commit физически пишет в базу, клиент вырубается. Кто откатывает частично записанные данные, кто не дает их читать параллельно работающим юзерам? Я не совсем понимаю этот механизм

Как я понимаю:

Коммит начался.
Данные начали писаться на сервер (вообще-то они и раньше могли туда потихоньку писаться, не суть).
Частично записанные данные ("грязные") - они рядышком с "основными" лежат.
В случае отвала клиента (до окончания коммита) эти грязные данные не надо откатывать, они просто мусором в базе лежат. При сжатии уберутся. Ну или следующая транзакция это "мусорное" место опять заюзает.
Не давать читать эти "грязные данные" не требуется, на "грязные" страницы ссылок еще нет.
Ссылки на актуальные страницы данных заменяются на ссылки на новые страницы данных. Это действие можно сделать атомарным независимо от количества измененных страниц.
Ну и собственно коммит закончился.

Это в простейшем случае. А вообще надо еще всякие индексы перестраивать и кучу говна выполнять. ИМХО как раз на этой куче говна аксес и рушится до состояния "database is corrupted".

Все написаное - мое видение, которое совсем не факт что является правильным :)
23 мар 06, 17:30    [2482952]     Ответить | Цитировать Сообщить модератору
 Re: Access и FoxPro. Сравнение мощей  [new]
H5N1
Guest
2Aki

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

итак выдернув шнурок у оракла есть 2 варианта или SCN успел записатся или не успел (в REDO). если успел, рекавери процесс из реду запишет измененые транзакцией данные в файлы данных, если неуспел, то посчитает транзакцию неудачной и откатит эту транзакцию (вычистив дата файлы, все что нада для очистки лежит в UNDO)
23 мар 06, 17:37    [2483002]     Ответить | Цитировать Сообщить модератору
 Re: Access и FoxPro. Сравнение мощей  [new]
1024
Member

Откуда: Нижний Новгород
Сообщений: 14267

ты мне скажи как поймать момент, когда шнурок выдернуть!!!!
Тут не СКЛ знать нужно.. а некиеньюансы, коих я не знаю увы....
--------------

а чё тут знать
--------------

create table test (ff int)
begin transaction
declare @i int
set @i=1
while @i<500000
begin
insert into test (ff) values (123)
set @i=@i+1
end
waitfor delay '23:59:00'
----------------------------
-- можно выдёргивать винт --
----------------------------
commit


Posted via ActualForum NNTP Server 1.3

23 мар 06, 17:38    [2483005]     Ответить | Цитировать Сообщить модератору
 Re: Access и FoxPro. Сравнение мощей  [new]
Aki
Guest
1024

ты мне скажи как поймать момент, когда шнурок выдернуть!!!!
Тут не СКЛ знать нужно.. а некиеньюансы, коих я не знаю увы....
--------------

а чё тут знать
--------------

create table test (ff int)
begin transaction
declare @i int
set @i=1
while @i<500000
begin
insert into test (ff) values (123)
set @i=@i+1
end
waitfor delay '23:59:00'
----------------------------
-- можно выдёргивать винт --
----------------------------
commit


Posted via ActualForum NNTP Server 1.3


Пардон - это не ПЛ/СКЛ... пусть меня простит Грипп, но я не буду еще и МС СКЛ себе ставить дабы проверять то, что меня собственно не волнует
23 мар 06, 17:50    [2483085]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 61 62 63 64 65 [66] 67 68 69 70 .. 72   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить