|
|
|
Что быстрее MS SQL или Interbase?
|
|||
|---|---|---|---|
|
#18+
>Если FB не может делать аналогичный бекап - это проблемы FB. А мужики-то не знают... Какой-такой аналогичный? Бэкап логов FB делать не может по причине отсутствия последних. Горячий бэкап базы FB делать может и делает без проблем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2005, 18:17 |
|
||
|
Что быстрее MS SQL или Interbase?
|
|||
|---|---|---|---|
|
#18+
hvlad andsm hvladНу наконец-то начали думать ;) Если приостанавливать бекап, то он никогда не закончится, если в БД всё время идёт запись Осталось только сообщить SQL Server-у о том что надо останавливать запись в лог во время бекапа лога А то у меня он не знает о том что ему нужно останавливаться На днях как раз в момент бекапа лога нагрузка была 630 транзакций в секунду. Ни одна транзакция не останавилась, максимальное время прохождения транзакции составило 156 мс при среднем времени ~12 мс.Т.е. пауза в 144 мс - это не пауза ? Или, увеличение времени выполнения тр-ции в 13 раз - это пофигу ? Кстати - читающие тр-ции приостанавливать не нужно, только пишушие. Сколько из этих 630 тр\сек пишуших ? andsmПочему во время бекапов лога не нужно приостанавливать писателей, почему в это время можно писать в лог - эти вопросы хорошо описаны в BOL.Админу - не нужно. А что там внутри сервера - давай ссылку, я поучусь andsmЕсли FB не может делать аналогичный бекап - это проблемы FB.Оно так и не поняло, что в FB нет таких логов и таких проблем hvlad явно не умеет читать и понимать написанное. Паузу в 144 мс где-то нашел, еще кучу глупостей написал.. Учись, а пока твой уровень знаний недостаточен для того чтобы что-то с чем-то сравнивать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2005, 18:42 |
|
||
|
Что быстрее MS SQL или Interbase?
|
|||
|---|---|---|---|
|
#18+
Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2005, 18:51 |
|
||
|
Что быстрее MS SQL или Interbase?
|
|||
|---|---|---|---|
|
#18+
andsmhvlad явно не умеет читать и понимать написанное. Паузу в 144 мс где-то нашел, еще кучу глупостей написал.. Учись, а пока твой уровень знаний недостаточен для того чтобы что-то с чем-то сравнивать.Отличный образец, как нужно вести беседу без перехода на личности :) Увеличение среднего времени тр-ции с 12 до 156 мс - это что ? Просто так ? Ладно, вычёркиваю ещё одного ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2005, 18:52 |
|
||
|
Что быстрее MS SQL или Interbase?
|
|||
|---|---|---|---|
|
#18+
dimitr 4321плин. а как тады оно откатывает всю _версию_ при ашипке стейтмента??? два последовательных апдейта в одной транзакции порождают всего одну версию и понятие ее отката достаточно сомнительно. При ошибке стейтмента откат выполняется на основе внутреннего лога, связывающего изменения записей с точками сохранения. Версии тут не причем. 4321что казалось бы проще - _версионнику_ читать записи из "достейтной" версии, а писать в "новую" версию (которую он так и так _отличает_ от _закомиченных_ записей - т.к. откатит при ашипке именно взад) - и никаких ашипок "инсерта + селекта" в таком варьянте не абнаружицца. для этого версия должна хранить не только ID транзакции, но и ID стейтмента или какую-либо временную отметку. Вопрос - нафуя? но думаешь в правильном направлении. Если при чтении записи использовать не только трассировку цепочки версий, но и проверку внутреннего лога отката, то эту проблему решить можно. Над чем разработчики уже размышляют. озадачиваться этой проблемой 20 лет назад никто не собирался, да и сейчас она имеет относительно низкий приоритет. Как спроектировано - так и работает. 1. 2dimitr спасибо за ответ. 2. я, чесна сказатть, "думал" из общих сабражений. Потому и не шипка въезжал в праблему. Потом токо падумалось, что "транзакция" в смысле T-SQL и транзакция в смысле версионников - "нескака разные вещи". Как утверждает простой поиск по форуму, в версионниках "вложенных транзакций" не бывает (если не отвлекаться на сейвпойнты) (кстати - а почему - какие то проблемы с рекрсивным построением "текущего состояния"? по множеству "вложенных" версий?), т.ч. взгляд на "стейтмент" как на "вложенную транзакцию" в случае версионника неверен и сталбыть без рассмотрения унутренней кухни транзакций эти мои "общие сабражения" неверны. Но как то же откатываются версионники на сейвпойнты? Может таки есть у них промежуточные версии... лана Мои извинения горячему парню hvlad ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2005, 19:04 |
|
||
|
Что быстрее MS SQL или Interbase?
|
|||
|---|---|---|---|
|
#18+
43212. я, чесна сказатть, "думал" из общих сабражений. Потому и не шипка въезжал в праблему. Потом токо падумалось, что "транзакция" в смысле T-SQL и транзакция в смысле версионников - "нескака разные вещи". Как утверждает простой поиск по форуму, в версионниках "вложенных транзакций" не бывает (если не отвлекаться на сейвпойнты) (кстати - а почему - какие то проблемы с рекрсивным построением "текущего состояния"? по множеству "вложенных" версий?), т.ч. взгляд на "стейтмент" как на "вложенную транзакцию" в случае версионника неверен и сталбыть без рассмотрения унутренней кухни транзакций эти мои "общие сабражения" неверны. Но как то же откатываются версионники на сейвпойнты? Может таки есть у них промежуточные версии... ланаНе бывает транзакций в смысле блокировочника и в смысле версионника. Есть св-ва ACID, есть уровни изоляций - эти понятия, к счастью, не зависят от реализации (как некоторые другие требования стандарта) Вложенных тр-ций нет ни в FB, ни в MSSQL. То, что MSSQL называет вложенными тр-циями - обыкновенные сейвпойнты. Попробуйте закоммитить такую "вложенными тр-цию" и сделать роллбек основной и всё сразу станет ясно. Даже ярые сторонники MSSQL это признают. Сейвпойнты в FB конечно же есть, и откатиться до них вполне возможно и это даже работает (некоторые здесь наверное удивятся ;) "Промежуточные" состояния записи тоже есть, но только в памяти, т.е. не на диске и версиями, строго говоря, не являются. Но это уже внутренняя кухня. Dimitr говорит о том, что возможно удастся использовать эту инф-цию, дабы избежать неприятных побочных эффектов приведенных выше. 4321Мои извинения горячему парню hvlad Принимается. В нормальном тоне можно и поговорить ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2005, 23:29 |
|
||
|
Что быстрее MS SQL или Interbase?
|
|||
|---|---|---|---|
|
#18+
protectorАнализ лога не решит проблемы RC транзакций. Операторы по прежнему будут видеть данные закомиченные на полпути. Чего-чего ? Незакомиченные данные видит только тот, кто их не закоммитил. Причём тут RC тр-ции ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2005, 23:35 |
|
||
|
Что быстрее MS SQL или Interbase?
|
|||
|---|---|---|---|
|
#18+
protectorАнализ лога не решит проблемы RC транзакций. Операторы по прежнему будут видеть данные закомиченные на полпути. согласен. Для нормальной поддержки RC в версионной логике нашего типа нужно что-то типа временного переключения на снапшот на время выборки промежуточного курсора. Насколько я в курсе, именно так поступает PostgreSQL. И это имеет свою, достаточно заметную, цену. protectorС другой стороны нумерование операторов позволит определить все возможные области видимости записей сделанных операторами и undolog в таком случае станет не нужен. C другой стороны таблица Statement ID будет расти похлеще чем таблица транзакций. Хотя это дело можно оптимизировать, но всё равно с этой стороны нагрузка возрастёт. внесение statement ID в версионное ядро просто убьет всю производительность. Т.е. теоретическое "решение всех проблем" на практике будет полной задницей. Уж лучше Undo Log и гемор с согласованностью операторов :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2005, 00:48 |
|
||
|
Что быстрее MS SQL или Interbase?
|
|||
|---|---|---|---|
|
#18+
Yo!!вообще я ожидал что к 5 прибавив 5 он перезапустит селект и теперь уже к 10 прибавит второй раз :) здесь кто-нибудь говорил о перезапуске селекта? Уж извини, но в данном случае ты совсем не в теме. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2005, 00:52 |
|
||
|
Что быстрее MS SQL или Interbase?
|
|||
|---|---|---|---|
|
#18+
hvlad Попробуйте закоммитить такую "вложенными тр-цию" и сделать роллбек основной и всё сразу станет ясно. "и это правильно" - и именно поэтому они и "_вложенные_" (т.е. "рекурсивные") а не "автономные" (независимые). т.ч. это вопрос трактовки _вложенности_ (а не "изнутри_запускаемости_независимых"). в нашем случае, если не утыкацца в слово "транзакция", вполне пригодились бы (скажем) "промежуточные под-версии" открываемые стейтментами (их будет всегда не больше одной в текущей транзакции - стейтменты в транзакции меж собой не конкурируют, и полную кухню обслуживания транзакций сюда тянуть не надо) так, чтобы курсор бегал по "основной" версии транзакции, а изменения (ежели будут) писались в "подверсию", а "коммитилась" бы "подверсия" в свою "версию" в момент выхода из "стейтмента". (при этом такое поведение можно распространить не только на "активные" стейтменты, но на все - в т.ч. и на селекты - т.к. есть возможность запихать в селект хп, меняющую данные того же набора). Но это естественно вопрос конкретной кухни, и не зная ее мыслить можно всякую хрень, не имеющую отношения к действительности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2005, 10:54 |
|
||
|
Что быстрее MS SQL или Interbase?
|
|||
|---|---|---|---|
|
#18+
dimitr здесь кто-нибудь говорил о перезапуске селекта? Уж извини, но в данном случае ты совсем не в теме. есть возможность запихать в селект хп, меняющую данные того же набора. Что можно ожидать в таком случае? (Зависимости рез-та от порядка записей, попадающих в курсор?). Хотя и понятно, что это извращение (менять записи хранимками, вызываемыми в селекте), но чем черт не шутит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2005, 10:58 |
|
||
|
Что быстрее MS SQL или Interbase?
|
|||
|---|---|---|---|
|
#18+
4321 dimitr здесь кто-нибудь говорил о перезапуске селекта? Уж извини, но в данном случае ты совсем не в теме. есть возможность запихать в селект хп, меняющую данные того же набора. Что можно ожидать в таком случае? (Зависимости рез-та от порядка записей, попадающих в курсор?). Хотя и понятно, что это извращение (менять записи хранимками, вызываемыми в селекте), но чем черт не шутит. Проскакивало у нас такое по ASA - кто то написал UDF, которая по переданому ID удаляла запись из таблицы. Следующий скрипт демонстировал замечательную шутку: Код: plaintext 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2005, 11:24 |
|
||
|
Что быстрее MS SQL или Interbase?
|
|||
|---|---|---|---|
|
#18+
2hvlad удаляем еще одного? это прально! нефиг! Просто чел говорил о среднем и максимальном времени транзакции. т.е. на 1000 скажем транзакций максимальное время составило 156 мс, в общем же эти 1000 выполнились за 1000*12 мс. жаль, конечно, что не приведены показатели в обычное время (не во время бэкапа лога), можно было бы сравнить. Неплохо было бы также получить гистограмму времени выполнения и всё такое.... andsm - сумеете такое сделать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2005, 11:47 |
|
||
|
Что быстрее MS SQL или Interbase?
|
|||
|---|---|---|---|
|
#18+
4321 hvlad Попробуйте закоммитить такую "вложенными тр-цию" и сделать роллбек основной и всё сразу станет ясно. "и это правильно" - и именно поэтому они и "_вложенные_" (т.е. "рекурсивные") а не "автономные" (независимые). т.ч. это вопрос трактовки _вложенности_ (а не "изнутри_запускаемости_независимых").Ок, вопрос трактовки. Чем тогда nested transactions MSSQL отличаются от savepoints в ORACLE или FB ? 4321Но это естественно вопрос конкретной кухни, и не зная ее мыслить можно всякую хрень, не имеющую отношения к действительности.Это точно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2005, 11:58 |
|
||
|
Что быстрее MS SQL или Interbase?
|
|||
|---|---|---|---|
|
#18+
lockyПросто чел говорил о среднем и максимальном времени транзакции. т.е. на 1000 скажем транзакций максимальное время составило 156 мс, в общем же эти 1000 выполнились за 1000*12 мс. жаль, конечно, что не приведены показатели в обычное время (не во время бэкапа лога), можно было бы сравнитьГм, я понял его именно так что в обычное время ср.вр.тр-ции 12 мс, а во время бекапа достигает 156 мс. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2005, 12:02 |
|
||
|
Что быстрее MS SQL или Interbase?
|
|||
|---|---|---|---|
|
#18+
Ок, ставим эксперимент. Дано: MSSQL2K, тестовая БД с recovery model = full Создаём тестовую таблицу, вставляем миллион записей, обрезаем лог: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. Код: plaintext 1. 2. 3. 4. 5. 6. 7. Пишем имитацию нагрузки с замером мин, макс и общего времени выполнения Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. Выполняем 3 раза, результаты: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Бекапим лог: Код: plaintext 1. 2. 3. 4. Выполняем скрипт ещё 3 раза (чтобы было что бекапить). Выполняем 4-ый раз и одновременно запускаем бекап: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 1. Макс. время выполнения увеличилось с 40 до 270 мс. 2. Общее время увеличилось более чем на время выполнения бекапа. 3. Время повторного выполнения бекапа примерно соответствует времени его выполнения при отсутствии фоновых тр-ций. В данном случае в повторный бекап попало на 461 страницу больше и потратил он на 0.6 сек больше. Т.е. можно сказать, что на время бекапа лога жизнь замирает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2005, 13:32 |
|
||
|
Что быстрее MS SQL или Interbase?
|
|||
|---|---|---|---|
|
#18+
locky2hvlad удаляем еще одного? это прально! нефиг! Просто чел говорил о среднем и максимальном времени транзакции. т.е. на 1000 скажем транзакций максимальное время составило 156 мс, в общем же эти 1000 выполнились за 1000*12 мс. жаль, конечно, что не приведены показатели в обычное время (не во время бэкапа лога), можно было бы сравнить. Неплохо было бы также получить гистограмму времени выполнения и всё такое.... andsm - сумеете такое сделать? Там было ~630 транзакций в секунду в течение пары минут (все пишущие, читающие я в это число не включил), но для ровного счета возьмем 1000. 1000*12 - формула расчета времени неправильная. Все эти 1000 транзакций прошли за 1 сек. Транзакции ведь идут из множества соединений, поэтому то что среднее время 12 мс не означает что 1000 транзакций выполнились за 12 сек. Показатели в обычное время (когда не идет бекап лога) и гистограмма распределения никак не отличаются - совпадают один в один. Но вообще-то такой картины на обычной железке не получить, там бекапы хорошо прогружают сервер и замедляют (но не останавливают) пишущие транзакции. У нас используется SAN. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2005, 13:49 |
|
||
|
Что быстрее MS SQL или Interbase?
|
|||
|---|---|---|---|
|
#18+
2hvlad в данном случае - да. а еще можно предположить, что ввод-вывод - узкое место. У меня есть резервный сервер который по пока непонятным причинам почти полностью замирает при восстановлении на нём базы. в то время как на боевом сервере - всё хорошо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2005, 14:16 |
|
||
|
Что быстрее MS SQL или Interbase?
|
|||
|---|---|---|---|
|
#18+
locky2hvlad в данном случае - да. а еще можно предположить, что ввод-вывод - узкое место. У меня есть резервный сервер который по пока непонятным причинам почти полностью замирает при восстановлении на нём базы. в то время как на боевом сервере - всё хорошо.Тест повторялся многократно с одними и теми же результатами. Слишком странное совпадение - увеличение времени батча как раз на время бекапа, не так ли ? Вряд ли в данном тесте ввод-вывод является узким местом, т.к. нагрузка весьма невелика и ничего больше в этот момент на компьютере не присходило. Кто угодно может повторить этот тест ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2005, 14:43 |
|
||
|
Что быстрее MS SQL или Interbase?
|
|||
|---|---|---|---|
|
#18+
hvlad Кто угодно может повторить этот тест а сменить диск бекапа не помогаит? (т.е. не на тот ли вы диск пишете бекап, где и раб. базки?) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2005, 14:47 |
|
||
|
Что быстрее MS SQL или Interbase?
|
|||
|---|---|---|---|
|
#18+
4321 hvlad Кто угодно может повторить этот тест а сменить диск бекапа не помогаит? (т.е. не на тот ли вы диск пишете бекап, где и раб. базки?)А вот вы и попробуйте ;) У меня сейчас нет под рукой незанятого сервера с несколькими дисками. MSSQL славится своим асинхронным IO - не думаю, что это поможет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2005, 15:12 |
|
||
|
Что быстрее MS SQL или Interbase?
|
|||
|---|---|---|---|
|
#18+
2 hvlad Я что то не понимаю, чего вы пытаетесь доказать своими тестами? Была озвучена задача - бекап логов при непрерывных идущих транзакциях. Вы осмелились утверждать, что это невозможно без полной остановки работы с БД ( "хотя бы для переименования файла логов" ). Это во-первых неправда, а во-вторых бред сивой кобылы. То, что вы обнаружили замедление - и что? Может будет замедление, может и нет. Зависит от конфигурации системы и выполняемых задач. Никто не обещал, что все будет с такой же скоростью выполняться. Но и гарантировать замедления тоже нельзя. Слишком странное совпадение - увеличение времени батча как раз на время бекапа, не так ли ? А оно что, уменьшиться что ли должно? За счет чего? Конфигурация у вас какая? Если у вас например однопроцессорная система с одним диском, то две группы операций над логом (а именно запись в лог в результате батча + бекап этого же самого лога), выполняемые параллельно - принципиально не могут отработать быстрее, чем те же две группы операций, но работающие последовательно. Тем более если еще и обрабатываемые данные лежат там же где и лог. Из того, что две операции вместе (возможно) отработают медленее, чем по отдельности - вовсе не следует, что они вообще никогда не смогут отработать, как вы пытались утверждать. Вряд ли в данном тесте ввод-вывод является узким местом, т.к. нагрузка весьма невелика и ничего больше в этот момент на компьютере не присходило. Ввод-вывод не являлся бы узким местом в том случае, если бы узким местом являлось бы что-нить другое. Например если бы вычислительная (процессорная) нагрузка была велика. А так ваши простейшие запросы (на апдейт сотни записей, отобранных по первичному ключу) очевидно дают нагрузку именно на IO и ни на что больше. Потому как ничего кроме ввода-вывода там и нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2005, 15:23 |
|
||
|
Что быстрее MS SQL или Interbase?
|
|||
|---|---|---|---|
|
#18+
hvladКонечно, запись в лог идёт всегда в конец, так что, читая его сначала, можно не заботиться о записи. Но всё равно наступит момент, когда нужно приостановить всех писателей, иначе процесс бекапа будет бесконечным - он никогда за ними не угонится. А Ахилл никогда не догонит черепаху ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2005, 15:44 |
|
||
|
Что быстрее MS SQL или Interbase?
|
|||
|---|---|---|---|
|
#18+
ЛП2 hvlad Я что то не понимаю, чего вы пытаетесь доказать своими тестами? Была озвучена задача - бекап логов при непрерывных идущих транзакциях. Вы осмелились утверждать, что это невозможно без полной остановки работы с БД ( "хотя бы для переименования файла логов" ). Во-первых - не утверждать, а предположить. Во-вторых - там было еще кое-что написано, кроме переименования ЛПЭто во-первых неправда, а во-вторых бред сивой кобылы.Спасибо ЛП Слишком странное совпадение - увеличение времени батча как раз на время бекапа, не так ли ? А оно что, уменьшиться что ли должно? За счет чего? Оно увеличилось не на 10%, не на 50%, даже не на 100%, а более чем на время бекапа лога. И батч, начавшись до бекапа, закончился после него. И время самого бекапа практически не изменилось. Имеющий глаза - увидит. Ок, пусть я жутко не прав. Где ваши весомые агументы ? Тесты, ссылки на документацию, и т.д. - где ? Слюной брызгать каждый может ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2005, 15:45 |
|
||
|
Что быстрее MS SQL или Interbase?
|
|||
|---|---|---|---|
|
#18+
ЛП hvladКонечно, запись в лог идёт всегда в конец, так что, читая его сначала, можно не заботиться о записи. Но всё равно наступит момент, когда нужно приостановить всех писателей, иначе процесс бекапа будет бесконечным - он никогда за ними не угонится. А Ахилл никогда не догонит черепаху Аналогия неверна. Черепаха не мешает Ахиллу бежать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2005, 15:47 |
|
||
|
|

start [/forum/topic.php?fid=35&msg=33140721&tid=1553187]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
41ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
57ms |
get tp. blocked users: |
1ms |
| others: | 233ms |
| total: | 377ms |

| 0 / 0 |
