Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 [6] 7 8   вперед  Ctrl      все
 Re: Что быстрее MS SQL или Interbase?  [new]
Юрий Носов
Member

Откуда: Умучен украми
Сообщений: 27901
>Если FB не может делать аналогичный бекап - это проблемы FB.
А мужики-то не знают...
Какой-такой аналогичный? Бэкап логов FB делать не может по причине отсутствия последних. Горячий бэкап базы FB делать может и делает без проблем.
28 июн 05, 18:17    [1657001]     Ответить | Цитировать Сообщить модератору
 Re: Что быстрее MS SQL или Interbase?  [new]
andsm
Member

Откуда: Москва
Сообщений: 1320
Блог
hvlad
andsm
hvlad
Ну наконец-то начали думать ;)
Если приостанавливать бекап, то он никогда не закончится, если в БД всё время идёт запись

Осталось только сообщить SQL Server-у о том что надо останавливать запись в лог во время бекапа лога А то у меня он не знает о том что ему нужно останавливаться На днях как раз в момент бекапа лога нагрузка была 630 транзакций в секунду. Ни одна транзакция не останавилась, максимальное время прохождения транзакции составило 156 мс при среднем времени ~12 мс.
Т.е. пауза в 144 мс - это не пауза ?
Или, увеличение времени выполнения тр-ции в 13 раз - это пофигу ?
Кстати - читающие тр-ции приостанавливать не нужно, только пишушие. Сколько из этих 630 тр\сек пишуших ?

andsm
Почему во время бекапов лога не нужно приостанавливать писателей, почему в это время можно писать в лог - эти вопросы хорошо описаны в BOL.
Админу - не нужно. А что там внутри сервера - давай ссылку, я поучусь

andsm
Если FB не может делать аналогичный бекап - это проблемы FB.
Оно так и не поняло, что в FB нет таких логов и таких проблем

hvlad явно не умеет читать и понимать написанное. Паузу в 144 мс где-то нашел, еще кучу глупостей написал.. Учись, а пока твой уровень знаний недостаточен для того чтобы что-то с чем-то сравнивать.
28 июн 05, 18:42    [1657061]     Ответить | Цитировать Сообщить модератору
 Re: Что быстрее MS SQL или Interbase?  [new]
Юрий Носов
Member

Откуда: Умучен украми
Сообщений: 27901
hvlad явно не умеет читать и понимать написанное. Паузу в 144 мс где-то нашел, еще кучу глупостей написал.. Учись, а пока твой уровень знаний недостаточен для того чтобы что-то с чем-то сравнивать
Так его, неуча! Аффтар, пеши исчо!
28 июн 05, 18:51    [1657079]     Ответить | Цитировать Сообщить модератору
 Re: Что быстрее MS SQL или Interbase?  [new]
hvlad
Guest
andsm
hvlad явно не умеет читать и понимать написанное. Паузу в 144 мс где-то нашел, еще кучу глупостей написал.. Учись, а пока твой уровень знаний недостаточен для того чтобы что-то с чем-то сравнивать.
Отличный образец, как нужно вести беседу без перехода на личности :)

Увеличение среднего времени тр-ции с 12 до 156 мс - это что ? Просто так ?

Ладно, вычёркиваю ещё одного
28 июн 05, 18:52    [1657080]     Ответить | Цитировать Сообщить модератору
 Re: Что быстрее MS SQL или Interbase?  [new]
4321
Member [заблокирован]

Откуда:
Сообщений: 3573
dimitr
4321
плин. а как тады оно откатывает всю _версию_ при ашипке стейтмента???


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

4321
что казалось бы проще - _версионнику_ читать записи из "достейтной" версии, а писать в "новую" версию (которую он так и так _отличает_ от _закомиченных_ записей - т.к. откатит при ашипке именно взад) - и никаких ашипок "инсерта + селекта" в таком варьянте не абнаружицца.


для этого версия должна хранить не только ID транзакции, но и ID стейтмента или какую-либо временную отметку. Вопрос - нафуя?

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

озадачиваться этой проблемой 20 лет назад никто не собирался, да и сейчас она имеет относительно низкий приоритет. Как спроектировано - так и работает.

1. 2dimitr спасибо за ответ.


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


Мои извинения горячему парню hvlad
28 июн 05, 19:04    [1657101]     Ответить | Цитировать Сообщить модератору
 Re: Что быстрее MS SQL или Interbase?  [new]
hvlad
Guest
4321
2. я, чесна сказатть, "думал" из общих сабражений. Потому и не шипка въезжал в праблему. Потом токо падумалось, что "транзакция" в смысле T-SQL и транзакция в смысле версионников - "нескака разные вещи". Как утверждает простой поиск по форуму, в версионниках "вложенных транзакций" не бывает (если не отвлекаться на сейвпойнты) (кстати - а почему - какие то проблемы с рекрсивным построением "текущего состояния"? по множеству "вложенных" версий?), т.ч. взгляд на "стейтмент" как на "вложенную транзакцию" в случае версионника неверен и сталбыть без рассмотрения унутренней кухни транзакций эти мои "общие сабражения" неверны. Но как то же откатываются версионники на сейвпойнты? Может таки есть у них промежуточные версии... лана
Не бывает транзакций в смысле блокировочника и в смысле версионника. Есть св-ва ACID, есть уровни изоляций - эти понятия, к счастью, не зависят от реализации (как некоторые другие требования стандарта)

Вложенных тр-ций нет ни в FB, ни в MSSQL. То, что MSSQL называет вложенными тр-циями - обыкновенные сейвпойнты. Попробуйте закоммитить такую "вложенными тр-цию" и сделать роллбек основной и всё сразу станет ясно.
Даже ярые сторонники MSSQL это признают.

Сейвпойнты в FB конечно же есть, и откатиться до них вполне возможно и это даже работает (некоторые здесь наверное удивятся ;) "Промежуточные" состояния записи тоже есть, но только в памяти, т.е. не на диске и версиями, строго говоря, не являются. Но это уже внутренняя кухня. Dimitr говорит о том, что возможно удастся использовать эту инф-цию, дабы избежать неприятных побочных эффектов приведенных выше.

4321
Мои извинения горячему парню hvlad
Принимается.
В нормальном тоне можно и поговорить
28 июн 05, 23:29    [1657336]     Ответить | Цитировать Сообщить модератору
 Re: Что быстрее MS SQL или Interbase?  [new]
hvlad
Guest
protector
Анализ лога не решит проблемы RC транзакций. Операторы по прежнему будут видеть данные закомиченные на полпути.
Чего-чего ? Незакомиченные данные видит только тот, кто их не закоммитил. Причём тут RC тр-ции ?
28 июн 05, 23:35    [1657342]     Ответить | Цитировать Сообщить модератору
 Re: Что быстрее MS SQL или Interbase?  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7000
protector
Анализ лога не решит проблемы RC транзакций. Операторы по прежнему будут видеть данные закомиченные на полпути.


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

protector
С другой стороны нумерование операторов позволит определить все возможные области видимости записей сделанных операторами и undolog в таком случае станет не нужен. C другой стороны таблица Statement ID будет расти похлеще чем таблица транзакций. Хотя это дело можно оптимизировать, но всё равно с этой стороны нагрузка возрастёт.


внесение statement ID в версионное ядро просто убьет всю производительность. Т.е. теоретическое "решение всех проблем" на практике будет полной задницей. Уж лучше Undo Log и гемор с согласованностью операторов :-)
29 июн 05, 00:48    [1657391]     Ответить | Цитировать Сообщить модератору
 Re: Что быстрее MS SQL или Interbase?  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7000
Yo!!
вообще я ожидал что к 5 прибавив 5 он перезапустит селект и теперь уже к 10 прибавит второй раз :)


здесь кто-нибудь говорил о перезапуске селекта? Уж извини, но в данном случае ты совсем не в теме.
29 июн 05, 00:52    [1657392]     Ответить | Цитировать Сообщить модератору
 Re: Что быстрее MS SQL или Interbase?  [new]
4321
Member [заблокирован]

Откуда:
Сообщений: 3573
hvlad
Попробуйте закоммитить такую "вложенными тр-цию" и сделать роллбек основной и всё сразу станет ясно.

"и это правильно" - и именно поэтому они и "_вложенные_" (т.е. "рекурсивные") а не "автономные" (независимые). т.ч. это вопрос трактовки _вложенности_ (а не "изнутри_запускаемости_независимых").


в нашем случае, если не утыкацца в слово "транзакция", вполне пригодились бы (скажем) "промежуточные под-версии" открываемые стейтментами (их будет всегда не больше одной в текущей транзакции - стейтменты в транзакции меж собой не конкурируют, и полную кухню обслуживания транзакций сюда тянуть не надо) так, чтобы курсор бегал по "основной" версии транзакции, а изменения (ежели будут) писались в "подверсию", а "коммитилась" бы "подверсия" в свою "версию" в момент выхода из "стейтмента". (при этом такое поведение можно распространить не только на "активные" стейтменты, но на все - в т.ч. и на селекты - т.к. есть возможность запихать в селект хп, меняющую данные того же набора).
Но это естественно вопрос конкретной кухни, и не зная ее мыслить можно всякую хрень, не имеющую отношения к действительности.
29 июн 05, 10:54    [1657963]     Ответить | Цитировать Сообщить модератору
 Re: Что быстрее MS SQL или Interbase?  [new]
4321
Member [заблокирован]

Откуда:
Сообщений: 3573
dimitr
здесь кто-нибудь говорил о перезапуске селекта? Уж извини, но в данном случае ты совсем не в теме.

есть возможность запихать в селект хп, меняющую данные того же набора. Что можно ожидать в таком случае? (Зависимости рез-та от порядка записей, попадающих в курсор?).
Хотя и понятно, что это извращение (менять записи хранимками, вызываемыми в селекте), но чем черт не шутит.
29 июн 05, 10:58    [1657986]     Ответить | Цитировать Сообщить модератору
 Re: Что быстрее MS SQL или Interbase?  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
4321
dimitr
здесь кто-нибудь говорил о перезапуске селекта? Уж извини, но в данном случае ты совсем не в теме.

есть возможность запихать в селект хп, меняющую данные того же набора. Что можно ожидать в таком случае? (Зависимости рез-та от порядка записей, попадающих в курсор?).
Хотя и понятно, что это извращение (менять записи хранимками, вызываемыми в селекте), но чем черт не шутит.

Проскакивало у нас такое по ASA - кто то написал UDF, которая по переданому ID удаляла запись из таблицы. Следующий скрипт демонстировал замечательную шутку:
SELECT *, Func_Delete( id )
FROM Table;
На выходе благодарный пользователь видел данные, подготовленные к удалению, оставалось только сказать COMMIT или ROLLBACK :) "Стабильность курсора" в ASA поддерживается, так что на удивление данная "технология" просто замечательно отрабатывает, благо что в большинстве народ предпочитает все таки более стандартные подходы :)
29 июн 05, 11:24    [1658128]     Ответить | Цитировать Сообщить модератору
 Re: Что быстрее MS SQL или Interbase?  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
2hvlad
удаляем еще одного? это прально! нефиг!
Просто чел говорил о среднем и максимальном времени транзакции.
т.е. на 1000 скажем транзакций максимальное время составило 156 мс, в общем же эти 1000 выполнились за 1000*12 мс.
жаль, конечно, что не приведены показатели в обычное время (не во время бэкапа лога), можно было бы сравнить.
Неплохо было бы также получить гистограмму времени выполнения и всё такое....
andsm - сумеете такое сделать?
29 июн 05, 11:47    [1658253]     Ответить | Цитировать Сообщить модератору
 Re: Что быстрее MS SQL или Interbase?  [new]
hvlad
Guest
4321
hvlad
Попробуйте закоммитить такую "вложенными тр-цию" и сделать роллбек основной и всё сразу станет ясно.

"и это правильно" - и именно поэтому они и "_вложенные_" (т.е. "рекурсивные") а не "автономные" (независимые). т.ч. это вопрос трактовки _вложенности_ (а не "изнутри_запускаемости_независимых").
Ок, вопрос трактовки. Чем тогда nested transactions MSSQL отличаются от savepoints в ORACLE или FB ?

4321
Но это естественно вопрос конкретной кухни, и не зная ее мыслить можно всякую хрень, не имеющую отношения к действительности.
Это точно
29 июн 05, 11:58    [1658309]     Ответить | Цитировать Сообщить модератору
 Re: Что быстрее MS SQL или Interbase?  [new]
hvlad
Guest
locky
Просто чел говорил о среднем и максимальном времени транзакции.
т.е. на 1000 скажем транзакций максимальное время составило 156 мс, в общем же эти 1000 выполнились за 1000*12 мс.
жаль, конечно, что не приведены показатели в обычное время (не во время бэкапа лога), можно было бы сравнить
Гм, я понял его именно так что в обычное время ср.вр.тр-ции 12 мс, а во время бекапа достигает 156 мс.
29 июн 05, 12:02    [1658330]     Ответить | Цитировать Сообщить модератору
 Re: Что быстрее MS SQL или Interbase?  [new]
hvlad
Guest
Ок, ставим эксперимент. Дано: MSSQL2K, тестовая БД с recovery model = full

Создаём тестовую таблицу, вставляем миллион записей, обрезаем лог:

SELECT @@VERSION

CREATE TABLE test (id int not null identity primary key, value varchar(255))

SET NOCOUNT ON

DECLARE @i int
SET @i = 0
WHILE @i < 1000000
BEGIN
  INSERT INTO test (value) VALUES ('mssqlisaveryverygoodsqlserver')
  SET @i = @i + 1
END

SELECT COUNT(*) FROM test

BACKUP LOG Test WITH TRUNCATE_ONLY

Microsoft SQL Server  2000 - 8.00.760 (Intel X86) 
	Dec 17 2002 14:22:05 
	Copyright (c) 1988-2003 Microsoft Corporation
	Standard Edition on Windows NT 5.0 (Build 2195: Service Pack 3)


----------- 
    1000000 

Пишем имитацию нагрузки с замером мин, макс и общего времени выполнения
SET NOCOUNT ON

DECLARE @i int, @t_min int, @t_max int, @t_all int

SET @i = 1000
WHILE @i > 0
BEGIN
  DECLARE @t datetime, @duration int, @id int
  SET @t = getdate()

  SET @id = ROUND(RAND() * 1000000, -3)

  UPDATE Test SET value = SUBSTRING(value, 2, 255) + SUBSTRING(value, 1, 1) 
   WHERE id BETWEEN @id AND @id + 99

  SET @duration = datediff(ms, @t, getdate())

  IF @t_min IS NULL 
  BEGIN
    SET @t_min = @duration
    SET @t_max = @duration
    SET @t_all = @duration
  END
  ELSE BEGIN
   IF @duration < @t_min
      SET @t_min = @duration

   IF @duration > @t_max
      SET @t_max = @duration

   SET @t_all = @t_all + @duration
  END
  
  SET @i = @i - 1
END

SELECT 'min' = @t_min, 'max' = @t_max, 'all' = @t_all

Выполняем 3 раза, результаты:
min         max         all         
----------- ----------- ----------- 
          0          20        1090 

min         max         all         
----------- ----------- ----------- 
          0          40        1170 

min         max         all         
----------- ----------- ----------- 
          0          20        1100 

Бекапим лог:

BACKUP LOG Test TO DISK = 'D:\MSSQL2K\MSSQL\BACKUP\test.bak' 
  WITH FORMAT

Processed 5014 pages for database 'Test', file 'Test_Log' on file 1.
BACKUP LOG successfully processed 5014 pages in 3.037 seconds (13.523 MB/sec).

Выполняем скрипт ещё 3 раза (чтобы было что бекапить).
Выполняем 4-ый раз и одновременно запускаем бекап:

время скрипта
min         max         all         
----------- ----------- ----------- 
          0         270        5439 

время бекапа
Processed 5475 pages for database 'Test', file 'Test_Log' on file 1.
BACKUP LOG successfully processed 5475 pages in 3.661 seconds (12.250 MB/sec).
Что мы видим ?
1. Макс. время выполнения увеличилось с 40 до 270 мс.
2. Общее время увеличилось более чем на время выполнения бекапа.
3. Время повторного выполнения бекапа примерно соответствует времени его выполнения при отсутствии фоновых тр-ций. В данном случае в повторный бекап попало на 461 страницу больше и потратил он на 0.6 сек больше.

Т.е. можно сказать, что на время бекапа лога жизнь замирает.
29 июн 05, 13:32    [1658834]     Ответить | Цитировать Сообщить модератору
 Re: Что быстрее MS SQL или Interbase?  [new]
andsm
Member

Откуда: Москва
Сообщений: 1320
Блог
locky
2hvlad
удаляем еще одного? это прально! нефиг!
Просто чел говорил о среднем и максимальном времени транзакции.
т.е. на 1000 скажем транзакций максимальное время составило 156 мс, в общем же эти 1000 выполнились за 1000*12 мс.
жаль, конечно, что не приведены показатели в обычное время (не во время бэкапа лога), можно было бы сравнить.
Неплохо было бы также получить гистограмму времени выполнения и всё такое....
andsm - сумеете такое сделать?

Там было ~630 транзакций в секунду в течение пары минут (все пишущие, читающие я в это число не включил), но для ровного счета возьмем 1000. 1000*12 - формула расчета времени неправильная. Все эти 1000 транзакций прошли за 1 сек. Транзакции ведь идут из множества соединений, поэтому то что среднее время 12 мс не означает что 1000 транзакций выполнились за 12 сек.
Показатели в обычное время (когда не идет бекап лога) и гистограмма распределения никак не отличаются - совпадают один в один. Но вообще-то такой картины на обычной железке не получить, там бекапы хорошо прогружают сервер и замедляют (но не останавливают) пишущие транзакции. У нас используется SAN.
29 июн 05, 13:49    [1658944]     Ответить | Цитировать Сообщить модератору
 Re: Что быстрее MS SQL или Interbase?  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
2hvlad
в данном случае - да.
а еще можно предположить, что ввод-вывод - узкое место.
У меня есть резервный сервер который по пока непонятным причинам почти полностью замирает при восстановлении на нём базы. в то время как на боевом сервере - всё хорошо.
29 июн 05, 14:16    [1659129]     Ответить | Цитировать Сообщить модератору
 Re: Что быстрее MS SQL или Interbase?  [new]
hvlad
Guest
locky
2hvlad
в данном случае - да.
а еще можно предположить, что ввод-вывод - узкое место.
У меня есть резервный сервер который по пока непонятным причинам почти полностью замирает при восстановлении на нём базы. в то время как на боевом сервере - всё хорошо.
Тест повторялся многократно с одними и теми же результатами.
Слишком странное совпадение - увеличение времени батча как раз на время бекапа, не так ли ?
Вряд ли в данном тесте ввод-вывод является узким местом, т.к. нагрузка весьма невелика и ничего больше в этот момент на компьютере не присходило.

Кто угодно может повторить этот тест
29 июн 05, 14:43    [1659323]     Ответить | Цитировать Сообщить модератору
 Re: Что быстрее MS SQL или Interbase?  [new]
4321
Member [заблокирован]

Откуда:
Сообщений: 3573
hvlad
Кто угодно может повторить этот тест

а сменить диск бекапа не помогаит? (т.е. не на тот ли вы диск пишете бекап, где и раб. базки?)
29 июн 05, 14:47    [1659341]     Ответить | Цитировать Сообщить модератору
 Re: Что быстрее MS SQL или Interbase?  [new]
hvlad
Guest
4321
hvlad
Кто угодно может повторить этот тест

а сменить диск бекапа не помогаит? (т.е. не на тот ли вы диск пишете бекап, где и раб. базки?)
А вот вы и попробуйте ;)
У меня сейчас нет под рукой незанятого сервера с несколькими дисками.
MSSQL славится своим асинхронным IO - не думаю, что это поможет
29 июн 05, 15:12    [1659482]     Ответить | Цитировать Сообщить модератору
 Re: Что быстрее MS SQL или Interbase?  [new]
ЛП
Guest
2 hvlad
Я что то не понимаю, чего вы пытаетесь доказать своими тестами?
Была озвучена задача - бекап логов при непрерывных идущих транзакциях. Вы осмелились утверждать, что это невозможно без полной остановки работы с БД ("хотя бы для переименования файла логов"). Это во-первых неправда, а во-вторых бред сивой кобылы.

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

Слишком странное совпадение - увеличение времени батча как раз на время бекапа, не так ли ?

А оно что, уменьшиться что ли должно? За счет чего?

Конфигурация у вас какая?
Если у вас например однопроцессорная система с одним диском, то две группы операций над логом (а именно запись в лог в результате батча + бекап этого же самого лога), выполняемые параллельно - принципиально не могут отработать быстрее, чем те же две группы операций, но работающие последовательно. Тем более если еще и обрабатываемые данные лежат там же где и лог.

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

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

Ввод-вывод не являлся бы узким местом в том случае, если бы узким местом являлось бы что-нить другое. Например если бы вычислительная (процессорная) нагрузка была велика.
А так ваши простейшие запросы (на апдейт сотни записей, отобранных по первичному ключу) очевидно дают нагрузку именно на IO и ни на что больше. Потому как ничего кроме ввода-вывода там и нет.
29 июн 05, 15:23    [1659552]     Ответить | Цитировать Сообщить модератору
 Re: Что быстрее MS SQL или Interbase?  [new]
ЛП
Guest
hvlad
Конечно, запись в лог идёт всегда в конец, так что, читая его сначала, можно не заботиться о записи. Но всё равно наступит момент, когда нужно приостановить всех писателей, иначе процесс бекапа будет бесконечным - он никогда за ними не угонится.

А Ахилл никогда не догонит черепаху
29 июн 05, 15:44    [1659674]     Ответить | Цитировать Сообщить модератору
 Re: Что быстрее MS SQL или Interbase?  [new]
hvlad
Guest
ЛП
2 hvlad
Я что то не понимаю, чего вы пытаетесь доказать своими тестами?
Была озвучена задача - бекап логов при непрерывных идущих транзакциях. Вы осмелились утверждать, что это невозможно без полной остановки работы с БД ("хотя бы для переименования файла логов").
Во-первых - не утверждать, а предположить. Во-вторых - там было еще кое-что написано, кроме переименования

ЛП
Это во-первых неправда, а во-вторых бред сивой кобылы.
Спасибо

ЛП
Слишком странное совпадение - увеличение времени батча как раз на время бекапа, не так ли ?

А оно что, уменьшиться что ли должно? За счет чего?
Оно увеличилось не на 10%, не на 50%, даже не на 100%, а более чем на время бекапа лога.
И батч, начавшись до бекапа, закончился после него. И время самого бекапа практически не изменилось.
Имеющий глаза - увидит.

Ок, пусть я жутко не прав. Где ваши весомые агументы ? Тесты, ссылки на документацию, и т.д. - где ?
Слюной брызгать каждый может ;)
29 июн 05, 15:45    [1659688]     Ответить | Цитировать Сообщить модератору
 Re: Что быстрее MS SQL или Interbase?  [new]
hvlad
Guest
ЛП
hvlad
Конечно, запись в лог идёт всегда в конец, так что, читая его сначала, можно не заботиться о записи. Но всё равно наступит момент, когда нужно приостановить всех писателей, иначе процесс бекапа будет бесконечным - он никогда за ними не угонится.

А Ахилл никогда не догонит черепаху
Аналогия неверна.
Черепаха не мешает Ахиллу бежать.
29 июн 05, 15:47    [1659701]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 [6] 7 8   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить