Нью-Йоркская фондовая биржа переходит на Linux

Раздроби себе голову кувалдой, если читать не умеешь. Речь шла о говномускуле, которому место на свалке - это говно за 3 мажорных версии даже SP не научилось поддерживать. Постгре стоит убить только за кривую систему бекапов как в мускуле, в остальном он хорош.

Разбей себе или научись читать сам: я говорил о Postgre, см. первый пост.

>Постгре стоит убить только за кривую систему бекапов как в мускуле, в остальном он хорош.

Кривая система у MS - ни разу не было, чтобы без проблем прошёл: перевести в SQL без потерь для него похоже вообще нереально. Приходится всякими идиотскими утилитами пользоваться типа SQL Compare или SQL Delta, но и те на 100% синхронизировать не могут.

Сравни с этими двумя элегантными строчками из PostgreSQL:

$ pg_dump dbname | gzip > filename.gz # backup

$ createdb dbname ; gunzip -c filename.gz # restore

А MS так не умеет в принципе.

Так и запишем: "ниасилил enterprise manager с бинарными бекапами и database maintenance wizard, прикручивает костыли с дампом в текст и последующей упаковкой".

А если нужно забекапить только изменения? А только логи транзакций? Написать десяток скриптов и ждать пока они прожуют базу на 300Гб?

PS. За год+ аптайма mssql ниразу небыло чтоб бекапы криво записались/развернулись.

> Раздроби себе голову кувалдой, если читать не умеешь

Я гляжу, большой спец, раз так выражаешься. Жена не дает?

>Так и запишем: "ниасилил enterprise manager с бинарными бекапами и database maintenance wizard, прикручивает костыли с дампом в текст и последующей упаковкой".

А если нужно забекапить только изменения? А только логи транзакций? Написать десяток скриптов и ждать пока они прожуют базу на 300Гб?

PS. За год+ аптайма mssql ниразу небыло чтоб бекапы криво записались/развернулись.

anonymous (*) (18.05.2007 19:56:05)

За полгода юзанья этого гм...СУБД(M$$QL) падал несколько раз.Потом сдох рэйд, а базу я восстанавливать не стал.И вообще, когда операция чтения болкирует ячейку-ну это, извините....ни в какие ворота

И вообще, когда операция чтения болкирует ячейку-ну это, извините....ни в какие ворота. ячейку? или всю страницу? WITH(NOLOCK) пробовал?

>ниасилил enterprise manager с бинарными бекапами

В задницу себе _бинарный_ бэкап базы засунь, ламо ;-)

>За полгода юзанья этого гм...СУБД(M$$QL) падал несколько раз.Потом сдох рэйд, а базу я восстанавливать не стал.И вообще, когда операция чтения болкирует ячейку-ну это, извините....ни в какие ворота

Ну MS всегда была блокирующей, многоверсионность появилась только в 2005-й версии, включается через ж..., при запросе нужно использовать опцию WITH(NOLOCK)

>Ну MS всегда была блокирующей, многоверсионность появилась только в 2005-й версии, включается через ж..., при запросе нужно использовать опцию WITH(NOLOCK)

И при этом читать грязные данные? Тогда либо у Вас MSSQL всегда работает в однопользовательском режиме, либо вы его вообще не использовали в промышленной эксплуатации :)

> И при этом читать грязные данные?

Есть другие предложения? Или мультиверсионность работает по другому?! Если чтение из базы в несколько раз превышает запись - отчёты, и это основное её предназначение, тогда какая есть альтернатива NOLOCK с точки зрения производительности?!

>в промышленной эксплуатации :)

По поводу эксплуатации см. выше.

>Есть другие предложения? Или мультиверсионность работает по другому?!

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

>Если чтение из базы в несколько раз превышает запись - отчёты, и это основное её предназначение, тогда какая есть альтернатива NOLOCK с точки зрения производительности?!

Альтернатива - не использовать MSSQL :) А вообще даже при таком использовании вам наверное просто до сих пор везло, что в отчет ни разу не попадались данные из транзакции, которую потом откатили...

А в MSSQL целостность транзакций отсутствует, чтоли?

>За полгода юзанья этого гм...СУБД(M$$QL) падал несколько раз.Потом сдох рэйд, а базу я восстанавливать не стал.И вообще, когда операция чтения болкирует ячейку-ну это, извините....ни в какие ворота

А что тут такого? Семантика типичного блокировочника. У версионников своих граблей хватает, чего только стоят всякие "FOR UPDATE".

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

Ну и, разве в МС другая мультиверсионность? К чему тогда термин "грязные"?

>Альтернатива - не использовать MSSQL :)

Согласен :) Сейчас работу поменяю и не буду больше... впрочем, видимо, равно как и любые другие СУБД ;)

>А вообще даже при таком использовании вам наверное просто до сих пор везло, что в отчет ни разу не попадались данные из транзакции, которую потом откатили...

А ничего страшного не произойдёт: неправильные циферки в отчёте - только то и всего. Кто об этом знает?! ;) Перезапустил отчётик и порядок :)

>Ну и, разве в МС другая мультиверсионность? К чему тогда термин "грязные"?

Подождите, Вы же сами только что советовали использовать NOLOCK? Идем на MSDN и читаем: NOLOCK Is equivalent to READUNCOMMITTED. READUNCOMMITTED Specifies that dirty reads are allowed

и как еще можно назвать чтение незавершенных транзакций, как не грязное?

>А ничего страшного не произойдёт: неправильные циферки в отчёте - только то и всего. Кто об этом знает?! ;) Перезапустил отчётик и порядок :)

Хм, а откуда Вы знаете, что циферки неправильные? Особенно если база большая :) Так и запишем, MSSQL не предназначен для mission-critical задач :)

>Согласен :) Сейчас работу поменяю и не буду больше... впрочем, видимо, равно как и любые другие СУБД ;)

И правильно, я с именно так и поступил, за ораклы с цисками больше платят :)

в предидущем сообщении забыл подписаться

>И правильно, я с именно так и поступил, за ораклы с цисками больше платят :)

А удалённо если? :)

>А удалённо если? :)

Удаленно ораклы или удаленно MS? Удаленно MS не хочется, я с ними уже натерпелся, у них и кроме NOLOCK проблемы имеются, взять хотя-бы отсутствие функции получения первого дня квартала (по крайней мере в 2000 ее не было), а удаленно оракл... а я и так с ним удаленно работаю, просто на новом месте, и с MS-ом никто не пристает :)

Я имел в виду зарплату и удалённую работу... из дома, например ;)

>Я имел в виду зарплату и удалённую работу... из дома, например ;)

Не получится, я слишком ленивый, поэтому если не заставлять себя ходить на работу, то скоро уже с места подняться не смогу :)

>А ничего страшного не произойдёт: неправильные циферки в отчёте - только то и всего. Кто об этом знает?! ;) Перезапустил отчётик и порядок :)

если это биржа или банк - то очень даже произойдёт особенно если отчёт после cut of day

> Ну MS всегда была блокирующей, многоверсионность появилась только в 2005-й версии, включается через ж..., при запросе нужно использовать опцию WITH(NOLOCK)

Понятно почему 1Совцы при перезде на PostgreSQL так много блокировок напихали - видимо привыкли :)

>Есть другие предложения? Или мультиверсионность работает по другому?! Если чтение из базы в несколько раз превышает запись - отчёты, и это основное её предназначение, тогда какая есть альтернатива NOLOCK с точки зрения производительности?!

Для отчетов как раз версионники и рулят (по идее :). Никаких блокировок в принципе.

Кстати, MS SQL тоже версионником умеет работать (начиная с 2005). Включаешь ALLOW_SNAPSHOT_ISOLATION для БД ("ALTER DATABASE <database name> SET ALLOW_SNAPSHOT_ISOLATION ON"), и запускаешь отчет с уровнем изоляции SNAPSHOT ("SET TRANSACTION ISOLATION LEVEL SNAPSHOT").

>Кстати, MS SQL тоже версионником умеет работать (начиная с 2005). Включаешь ...

Это мы знаем ;)

> Понятно почему 1Совцы при перезде на PostgreSQL так много блокировок напихали - видимо привыкли :)

Так и есть, собственно.

В 1С взаимодействие с СУБД слишком явно и непосредственно доступно пользователям (т.е. программистам на 1С). Изолировать пользователей от специфики СУБД не получается кроме как напихиванием блокировок, а не изолировать нельзя.