Эта клонность закончилась на Ib6. Дальше разработка ведется параллельно.
Ну дык и на ИБ6 небуло полной совместимости, тожа нужно было переносить из одной версии в другую. И на ФБ разных версий нету полной совместимости.
gnick пишет:
Но согласен и с AlexD, версионная архитектура накладывает свои ограничения, например сервак явно не предназначен к регулярным масовым операциям удалениям.
Ну тагды уж и массовой вставки записей тожа. Единствено при массовом удалении размер базы остается прежним. Ну дык ежли постаянно массово добовлять и удалять записи, то размер то тады практичеки не менятца. А так оно мона нормолизовать базу да и усе.
gnick пишет:
И отсутствие стабильности курсора, что идет в явный разрес со стандартом SQL.
Дык ето не страшно, я вообче не видю смысла его стабилизировать, зато есть UDF и ХП.
Ну дык и на ИБ6 небуло полной совместимости, тожа нужно было переносить из одной версии в другую. И на ФБ разных версий нету полной совместимости.
Не правда. Бэкап/рестор, конечно, предписывался для перехода с одного сервака на другой, но вполне можно было обойтись и обычным копированием файла базы при отключенной службе сервера. между разными версиями fb нет совместимости если меняется on disk structure. Конечно fb 1.5 не сможет работать с fb 2.0. А вот двойка с 1.5 работать будет.
Quote:
Ну дык ежли постаянно массово добовлять и удалять записи, то размер то тады практичеки не менятца.
Эт почему? Если одни и те же, то еще может быть за счет кооперативной сборки мусора, но тогда время выполнения этих запросов будет никаким.
Quote:
А так оно мона нормолизовать базу да и усе.
Опять не понял. База и так считаем что нормализована.
Quote:
Дык ето не страшно, я вообче не видю смысла его стабилизировать, зато есть UDF и ХП.
Это не есть гуд! И это нужно исправлять.
Тема обсуждается например тут http://rsdn.ru/forum/message/573511.aspx и внимание стоит обратить на ответ dimitr- ведущего разработчика firebird
А насчет udf и хп, это отлично что они есть, но... это... того.. если бы их не было (особенно хп) то что это был бы за сервер?
ЗЫ. Это говорю совершенно не для того, чтобы наехать на фб, т.к. сам являюсь его поклонником, но нужно объективно оценивать действительность и стремиться к ликвидацию недостатков.
Не правда. Бэкап/рестор, конечно, предписывался для перехода с одного сервака на другой
Ну если на то пошло тады и фокспро совместим с фб. взял забакапил поправил код и востановил. ведь gbk ето же по сути sql скрипт. а так я конечно согласный мона было перенести базу иб6 на фб и оно работало, но не всяка база. И даже у IB4 база не всегда работала на сервере IB6.
gnick пишет:
Эт почему? Если одни и те же, то еще может быть за счет кооперативной сборки мусора, но тогда время выполнения этих запросов будет никаким.
Я имел ввиду если удалять и добавлять данные не одновременными транзакциями, а если одновременными, то какая серверу разница одинаковые записи или разные.
gnick пишет:
Опять не понял. База и так считаем что нормализована.
Но ведь когда мы добавляем и удаляем записи размер базы разрастается, всмысле она принимает размер когда в ней было наибольшее количество записей. Индексы переплетаются и усе страницы перепутываются. Ну и тогда база начинает тормозить. Чтобы оптимизировать лучше всего пробэкапить и востоновить, и размер кстати дико уменьшиться.
gnick пишет:
Это не есть гуд! И это нужно исправлять.
Согласен, но зато пока они исправят или хотя бы приведут к общему стандарту SQL можно даработать сервак по своему образу и подобию:-)
Но ведь когда мы добавляем и удаляем записи размер базы разрастается, всмысле она принимает размер когда в ней было наибольшее количество записей. Индексы переплетаются и усе страницы перепутываются. Ну и тогда база начинает тормозить. Чтобы оптимизировать лучше всего пробэкапить и востоновить, и размер кстати дико уменьшиться.
Объясните темному, при чем тут нормализация?
Разумеется, бэкап/рестор при надлежащем задании ключа выполнит сборку мусора и как следствие уменьшит базу и що с того?
Quote:
Я имел ввиду если удалять и добавлять данные не одновременными транзакциями, а если одновременными, то какая серверу разница одинаковые записи или разные.
Что Вы подразумеваете под одновременными транзакциями в данном контексте?
:eek:
Итак на пальцах:
транзакция 1 стартует (далее тр1)
тр 1 выполняет процедуру вставки 10000 строк с id (pk) от 110000 до 120000
-- в таблице появляется 10000 версий новых записей
тр 1 коммит
тр2 старт
тр2 delete from table where id>=1 and id=20000 and id<=30000
-- новые 10000 версий записей
тр4 коммит
и т.д.
Размер таблицы постоянно растет, т.к. добавляем одни строки а удаляем други, т.е и в том и в другом случае генерим новые версии.
Или я не понял Вашу мысль, поясните.
Размер таблицы постоянно растет, т.к. добавляем одни строки а удаляем други, т.е и в том и в другом случае генерим новые версии.
Какой УЖАС!!!
Как тогды с базами работать.
Согласен что в базе создаются новые версии, но только при удалении записи удаляются и усе ранее созданные версии етой записи т.е. "мусор". Интересно зачем создавать версию записи которая будет удалена из базы, мене кажется ето немного странно, оставить версию и тем более создать, а вдруг кто нето поредакирует удаленную запись перед смертью.
Согласен что в базе создаются новые версии, но только при удалении записи удаляются и усе ранее созданные версии етой записи т.е. "мусор"
Ничего подобного! При удалении создается ВЕРСИЯ ЗАПИСИ, помеченная как удаленная, она будет собрана как мусор только при попытке чтения этой записи, при бэкап/рестор и т.п. Удаление записи ничем не отличается в этом плане от апдейта.
Quote:
Интересно зачем создавать версию записи которая будет удалена из базы, мене кажется ето немного странно, оставить версию и тем более создать, а вдруг кто нето поредакирует удаленную запись перед смертью.
Редактировать удаленную запись не удастся. Как Вы это себе представляете? Если транзакция, удаляющая запись еще находится в состоянии active, то другая при попытке ее изменить получит dedlock. Если же транзакция находится в состоянии commit, то другая транзакция по просту уже не увидит этой записи и, значит, ничего не изменит. Зато другие транзакции смогут ЧИТАТЬ видные им версии.
Пример.
tr1 snapshot starts
tr1 select * from table where id=100 // видит строку таблицы с ид=100
tr2 read_committed starts
tr2 delete from table where id=100
tr1 select * from table where id=100 // видит ту же строку
tr2 commit
tr1 select * from table where id=100 // видит ту же строку
tr1 commit
tr3 starts
tr3 select * from table where id=100 // вот здесь уже нет видимой версии
tr3 commit
tr1
Ничего подобного! При удалении создается ВЕРСИЯ ЗАПИСИ, помеченная как удаленная, она будет собрана как мусор только при попытке чтения этой записи,
Довольно сложно прочитать удаленную запись.
В примере первая транзакция делает снимок, и все остальные версии ей по барабану, а не вторая создает новую версию.
В примере первая транзакция делает снимок, и все остальные версии ей по барабану, а не вторая создает новую версию.
Снимок чего, позвольте спросить? Базы данных?
Она делает снимок TIP- transaction invetory page (страницы номеров активных, закоммиченных и отроллбаченных транзакций) и по барабану ей не остальные версии, а остальные (в смысле стартовавшие после нее) транзакции и, как следствие этого, версии записей ими созданные.
Насчет чтения удаленной записи. Я же написал, при попытке!
Пусть мы удалили строку с ид=100, и закоммитили транзакцию.
Стартуем другую и просим select *from table where id=100. В этот момент эта транзакция обнаруживает, что все версии этой записи- мусор и удаляет их.
А вообще, читаем "классиков" на тему сию, в частности http://ibase.ru/devinfo/garbage.htm, обращая особое внимание на абзац
"То же самое относится к удаляемым данным. Если мы удалили данные за "вчера", и сервер не прочтет эти страницы данных, на самом деле данные не удалятся, т.к. удаление - это создание новой версии записи с пометкой, что все версии этой записи должны быть удалены при сборке мусора (кооперативной или sweep)."
Добавлено: : 19 Июля 2007 Да, еще в догонку. Вполне вероятно, что чтения этих записей и не произойдет. Поэтому база будет распухать до автоматического запуска sweep или бэкап/рестора. Почему я и говорю, что для ФБ/ИБ массовые операции удаления суть зло ибо чтение их куда менее вероятно, как вы разумно подметили.
Она делает снимок TIP- transaction invetory page (страницы номеров активных, закоммиченных и отроллбаченных транзакций) и по барабану ей не остальные версии, а остальные (в смысле стартовавшие после нее) транзакции и, как следствие этого, версии записей ими созданные.
Позвольте спросить зачем транзакции SNAPSHOT делать снимок страницы учета транзакций, она вроде бы с данными работает и делает снимок данных как мне ето представляется. И почему только стартовавших после нее, что ли стартовавшие ранее как то на нее влияют.
Позвольте спросить зачем транзакции SNAPSHOT делать снимок страницы учета транзакций, она вроде бы с данными работает и делает снимок данных как мне ето представляется. И почему только стартовавших после нее, что ли стартовавшие ранее как то на нее влияют.
Подробный ответ Вы легко найдете в статьях на ibase.ru или в книгах посвященных серверу, например даже такой как Мир Интербэйз Вострикова с Ковязиным, не говоря уже о книге Хелен Борри. А в общих чертах вот зачем. Каждая транзакция имеет номер, номера естественно присваиваются последовательно. Кроме того транзакции имеют состояние (active, committed, rolled back, in limbo). Эта информация о транзакциях и хранится в TIP. Когда snapshot транзакция стартует она делает локальную копию TIP и работает дальше с ней. Транзакции же read committed работают с одной общей глобальной TIP. Видимость версии конкретной транзакции определяется следующим образом. Считывается самая верхняя версия записи из базы данных. Версия кроме собственно данных содержит номер создавшей ее транзакции. Далее происходит проверка состояния этой транзакции по TIP, если номер такой транзакции есть в TIP и эта транзакция имеет состояние committed то транзакция может видеть эту версию. Иначе происходит чтение back-версии и снова проверка с TIP.
Поскольку снапшот делает этот снимок, транзакции, которые стартовали после нее для нее не существуют, в копии TIP о них никакой информации нет и, поэтому, версии созданные этими транзакциями для нее не видны.
Далее транзакция пытается удалить мусор (версии записей, которые уже не нужны ни одной транзакции)
ЗЫ. А вариант с копированием данных заслуживает внимания :laugh:
Представим себе 100 одновременных снапшотов и каждая делает полный снимок миллионов записей
Ну дык и на ИБ6 небуло полной совместимости, тожа нужно было переносить из одной версии в другую. И на ФБ разных версий нету полной совместимости.
Ну тагды уж и массовой вставки записей тожа. Единствено при массовом удалении размер базы остается прежним. Ну дык ежли постаянно массово добовлять и удалять записи, то размер то тады практичеки не менятца. А так оно мона нормолизовать базу да и усе.
Дык ето не страшно, я вообче не видю смысла его стабилизировать, зато есть UDF и ХП.
Не правда. Бэкап/рестор, конечно, предписывался для перехода с одного сервака на другой, но вполне можно было обойтись и обычным копированием файла базы при отключенной службе сервера. между разными версиями fb нет совместимости если меняется on disk structure. Конечно fb 1.5 не сможет работать с fb 2.0. А вот двойка с 1.5 работать будет.
Эт почему? Если одни и те же, то еще может быть за счет кооперативной сборки мусора, но тогда время выполнения этих запросов будет никаким.
Опять не понял. База и так считаем что нормализована.
Это не есть гуд! И это нужно исправлять.
Тема обсуждается например тут http://rsdn.ru/forum/message/573511.aspx и внимание стоит обратить на ответ dimitr- ведущего разработчика firebird
А насчет udf и хп, это отлично что они есть, но... это... того.. если бы их не было (особенно хп) то что это был бы за сервер?
ЗЫ. Это говорю совершенно не для того, чтобы наехать на фб, т.к. сам являюсь его поклонником, но нужно объективно оценивать действительность и стремиться к ликвидацию недостатков.
Ну если на то пошло тады и фокспро совместим с фб. взял забакапил поправил код и востановил. ведь gbk ето же по сути sql скрипт. а так я конечно согласный мона было перенести базу иб6 на фб и оно работало, но не всяка база. И даже у IB4 база не всегда работала на сервере IB6.
Я имел ввиду если удалять и добавлять данные не одновременными транзакциями, а если одновременными, то какая серверу разница одинаковые записи или разные.
Но ведь когда мы добавляем и удаляем записи размер базы разрастается, всмысле она принимает размер когда в ней было наибольшее количество записей. Индексы переплетаются и усе страницы перепутываются. Ну и тогда база начинает тормозить. Чтобы оптимизировать лучше всего пробэкапить и востоновить, и размер кстати дико уменьшиться.
Согласен, но зато пока они исправят или хотя бы приведут к общему стандарту SQL можно даработать сервак по своему образу и подобию:-)
Объясните темному, при чем тут нормализация?
Разумеется, бэкап/рестор при надлежащем задании ключа выполнит сборку мусора и как следствие уменьшит базу и що с того?
Что Вы подразумеваете под одновременными транзакциями в данном контексте?
:eek:
Итак на пальцах:
транзакция 1 стартует (далее тр1)
тр 1 выполняет процедуру вставки 10000 строк с id (pk) от 110000 до 120000
-- в таблице появляется 10000 версий новых записей
тр 1 коммит
тр2 старт
тр2 delete from table where id>=1 and id=20000 and id<=30000
-- новые 10000 версий записей
тр4 коммит
и т.д.
Размер таблицы постоянно растет, т.к. добавляем одни строки а удаляем други, т.е и в том и в другом случае генерим новые версии.
Или я не понял Вашу мысль, поясните.
Какой УЖАС!!!
Как тогды с базами работать.
Согласен что в базе создаются новые версии, но только при удалении записи удаляются и усе ранее созданные версии етой записи т.е. "мусор". Интересно зачем создавать версию записи которая будет удалена из базы, мене кажется ето немного странно, оставить версию и тем более создать, а вдруг кто нето поредакирует удаленную запись перед смертью.
Ничего подобного! При удалении создается ВЕРСИЯ ЗАПИСИ, помеченная как удаленная, она будет собрана как мусор только при попытке чтения этой записи, при бэкап/рестор и т.п. Удаление записи ничем не отличается в этом плане от апдейта.
Редактировать удаленную запись не удастся. Как Вы это себе представляете? Если транзакция, удаляющая запись еще находится в состоянии active, то другая при попытке ее изменить получит dedlock. Если же транзакция находится в состоянии commit, то другая транзакция по просту уже не увидит этой записи и, значит, ничего не изменит. Зато другие транзакции смогут ЧИТАТЬ видные им версии.
Пример.
tr1 snapshot starts
tr1 select * from table where id=100 // видит строку таблицы с ид=100
tr2 read_committed starts
tr2 delete from table where id=100
tr1 select * from table where id=100 // видит ту же строку
tr2 commit
tr1 select * from table where id=100 // видит ту же строку
tr1 commit
tr3 starts
tr3 select * from table where id=100 // вот здесь уже нет видимой версии
tr3 commit
tr1
Довольно сложно прочитать удаленную запись.
В примере первая транзакция делает снимок, и все остальные версии ей по барабану, а не вторая создает новую версию.
Снимок чего, позвольте спросить? Базы данных?
Она делает снимок TIP- transaction invetory page (страницы номеров активных, закоммиченных и отроллбаченных транзакций) и по барабану ей не остальные версии, а остальные (в смысле стартовавшие после нее) транзакции и, как следствие этого, версии записей ими созданные.
Насчет чтения удаленной записи. Я же написал, при попытке!
Пусть мы удалили строку с ид=100, и закоммитили транзакцию.
Стартуем другую и просим select *from table where id=100. В этот момент эта транзакция обнаруживает, что все версии этой записи- мусор и удаляет их.
А вообще, читаем "классиков" на тему сию, в частности
http://ibase.ru/devinfo/garbage.htm, обращая особое внимание на абзац
"То же самое относится к удаляемым данным. Если мы удалили данные за "вчера", и сервер не прочтет эти страницы данных, на самом деле данные не удалятся, т.к. удаление - это создание новой версии записи с пометкой, что все версии этой записи должны быть удалены при сборке мусора (кооперативной или sweep)."
Добавлено: : 19 Июля 2007 Да, еще в догонку. Вполне вероятно, что чтения этих записей и не произойдет. Поэтому база будет распухать до автоматического запуска sweep или бэкап/рестора. Почему я и говорю, что для ФБ/ИБ массовые операции удаления суть зло ибо чтение их куда менее вероятно, как вы разумно подметили.
Позвольте спросить зачем транзакции SNAPSHOT делать снимок страницы учета транзакций, она вроде бы с данными работает и делает снимок данных как мне ето представляется. И почему только стартовавших после нее, что ли стартовавшие ранее как то на нее влияют.
Подробный ответ Вы легко найдете в статьях на ibase.ru или в книгах посвященных серверу, например даже такой как Мир Интербэйз Вострикова с Ковязиным, не говоря уже о книге Хелен Борри. А в общих чертах вот зачем. Каждая транзакция имеет номер, номера естественно присваиваются последовательно. Кроме того транзакции имеют состояние (active, committed, rolled back, in limbo). Эта информация о транзакциях и хранится в TIP. Когда snapshot транзакция стартует она делает локальную копию TIP и работает дальше с ней. Транзакции же read committed работают с одной общей глобальной TIP. Видимость версии конкретной транзакции определяется следующим образом. Считывается самая верхняя версия записи из базы данных. Версия кроме собственно данных содержит номер создавшей ее транзакции. Далее происходит проверка состояния этой транзакции по TIP, если номер такой транзакции есть в TIP и эта транзакция имеет состояние committed то транзакция может видеть эту версию. Иначе происходит чтение back-версии и снова проверка с TIP.
Поскольку снапшот делает этот снимок, транзакции, которые стартовали после нее для нее не существуют, в копии TIP о них никакой информации нет и, поэтому, версии созданные этими транзакциями для нее не видны.
Далее транзакция пытается удалить мусор (версии записей, которые уже не нужны ни одной транзакции)
ЗЫ. А вариант с копированием данных заслуживает внимания :laugh:
Представим себе 100 одновременных снапшотов и каждая делает полный снимок миллионов записей
Страницы