Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 4 5 6 7 8 [9] 10 11 12 13 14   вперед  Ctrl
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
Dimitry Sibiryakov
Member

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

sphinx_mv
Сравнивать наличие фичи с практически полным её отсутствием - не
спортивно!

Что значит "практически полное отсутствие"? Failover cluster у Firebird из коробки
отсутствует абсолютно совершенно. Как и у MS SQL Express Edition. Впрочем, у Express и
сравнимый mirroring тоже отсутствует.

Posted via ActualForum NNTP Server 1.5

8 мар 15, 15:28    [17358491]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30253
Любитель MSSQL
И как же восстанавливать транзакции, которые изменили страницы в кэше, но не были сброшены на диск в момент аварии?

то, что было только в памяти, и умерло, никто не восстановит, никогда и никак. Кроме того, у IB/FB завершение транзакции - это изменение состояния транзакции в Transaction Inventory Page. В результате, если даже что-то записано на диск, но не имеет состояния committed, будет в дальнейшем вычищено как мусор. "восстанавливать" такие незавершенные транзакции нет никакого смысла ни в какой СУБД.
8 мар 15, 16:43    [17358600]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
Любитель MSSQL
Member

Откуда:
Сообщений: 32
kdv
Любитель MSSQL
И как же восстанавливать транзакции, которые изменили страницы в кэше, но не были сброшены на диск в момент аварии?

то, что было только в памяти, и умерло, никто не восстановит, никогда и никак. Кроме того, у IB/FB завершение транзакции - это изменение состояния транзакции в Transaction Inventory Page. В результате, если даже что-то записано на диск, но не имеет состояния committed, будет в дальнейшем вычищено как мусор. "восстанавливать" такие незавершенные транзакции нет никакого смысла ни в какой СУБД.


А возможно ли такое: изменили страницу в кэше, еще не успели сбросить на диск, но транзакцию зафиксировали (поменял статус в transaction inventory page), случилась авария, как будем восстанавливать?
8 мар 15, 18:02    [17358732]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7000
Любитель MSSQL
А возможно ли такое

невозможно
8 мар 15, 18:09    [17358750]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 11092
Любитель MSSQL,

не может. Потому как действует правило Careful Write. Страницы пишутся только в определённом порядке, чтобы любая прерванная запись не сделала транзакцию случайно подтверждённой. В случае аварии те страницы которые были записаны, но для них не было проставлено подтверждении транзакции в TIP просто окажутся мусором.
8 мар 15, 18:12    [17358758]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
Любитель MSSQL
Member

Откуда:
Сообщений: 32
Симонов Денис
Любитель MSSQL,

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


то есть при фиксации транзакции всегда происходит сброс "грязных страниц" на диск верно?
8 мар 15, 18:51    [17358865]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
чччД
Guest
Любитель MSSQL
...
1. Полное резервное копирование базы раз в неделю
2. Ежедневное дифференциальное копирование
3 Ежеминутное резервное копирование журнала.
...


"Твою же ж мать!" - (с) Эрик Теодор Картман
8 мар 15, 18:53    [17358869]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
Dimitry Sibiryakov
Member

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

Любитель MSSQL
то есть при фиксации транзакции всегда происходит сброс "грязных
страниц" на диск верно?

Вот только не надо опять начинать про головку, которая туда-сюда. Возвращайся, когда
найдёшь оную у SSD.

Posted via ActualForum NNTP Server 1.5

8 мар 15, 19:11    [17358914]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 11092
Любитель MSSQL,
да, а может и раньше. Но фишка в том что и MSSQL они тоже сбрасываются на диск. Только в лог, а потом часть из них ещё и в файл БД.

И вообще ваши рассуждения об удержании MSSQL ем базы в памяти немного смешны. Это может быть только для идеальных случаев когда объём ОЗУ превышает объём БД, а такое бывает далеко не всегда. А когда БД большие, например 1Tb, это далеко не так. И вот тогда страницы из кэша будут вытесняться, а следовательно их надо будет подсасывать с диска. Это может быть сделано из файла БД (если повезёт), а может из лога.
8 мар 15, 19:18    [17358926]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
Dimitry Sibiryakov
Member

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

Симонов Денис
Это может быть сделано из файла БД (если повезёт), а может из лога.

Из лога - не может. Он читается только при восстановлении.

Posted via ActualForum NNTP Server 1.5

8 мар 15, 19:26    [17358937]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Симонов Денис
И вообще ваши рассуждения об удержании MSSQL ем базы в памяти немного смешны. Это может быть только для идеальных случаев когда объём ОЗУ превышает объём БД, а такое бывает далеко не всегда. А когда БД большие, например 1Tb, это далеко не так. И вот тогда страницы из кэша будут вытесняться, а следовательно их надо будет подсасывать с диска. Это может быть сделано из файла БД (если повезёт), а может из лога.


Ничего смешного здесь нет. Соотношение размера БД к размеру физической памяти мало интересно, ибо не все данные БД, как правило, нужны. Одним из критериев производительности MS SQL является Buffer Cache Hit Ratio. В сбалансированной системе он стремится к 100%.
8 мар 15, 19:56    [17358985]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 11092
Dimitry Sibiryakov,

а вот тогда интересный вопрос возникает. Если чекпойнт ещё не произошёл, а кеш весь вытеснен, откуда данные брать?
8 мар 15, 19:56    [17358986]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Симонов Денис
Если чекпойнт ещё не произошёл, а кеш весь вытеснен, откуда данные брать?


Невозможно вытеснить грязные страницы, т.е. перед вытеснением они должны быть записаны. Вытеснение всего кэша это чрезвычайная ситуация, ведущая к деградации производительности, ибо серверу приходится прибегать к физическому чтению, вместо логического.
8 мар 15, 20:07    [17359010]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
Dimitry Sibiryakov
Member

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

pkarklin
Одним из критериев производительности MS SQL является Buffer Cache Hit
Ratio.

А как он считается? Уж не отношение ли это количества логических чтений к сумме логических
и физических чтений?..

Posted via ActualForum NNTP Server 1.5

8 мар 15, 20:10    [17359016]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Dimitry Sibiryakov
А как он считается? Уж не отношение ли это количества логических чтений к сумме логических
и физических чтений?..


Отношение кол-ва страниц , полученных из буферного кэша, к общему кол-ву страниц для операции.
8 мар 15, 20:14    [17359026]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 11092
pkarklin
Невозможно вытеснить грязные страницы, т.е. перед вытеснением они должны быть записаны. Вытеснение всего кэша это чрезвычайная ситуация, ведущая к деградации производительности, ибо серверу приходится прибегать к физическому чтению, вместо логического.


вот. А это значит что серверу так или иначе придётся сбрасывать грязные страницы на диск, иначе со временем все они станут грязными. Так что при определённых условиях всё же можно достичь такой ситуации при которой чекпойнты могут стать узким местом. Хотя согласен при грамотной настройке и достаточных характеристиках железа такого быть не должно.
8 мар 15, 20:19    [17359041]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Симонов Денис
Хотя согласен при грамотной настройке и достаточных характеристиках железа такого быть не должно.


Здесь больше влияние оказывает качество проектирования\кода, чем настройки\железо.
8 мар 15, 20:23    [17359051]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 11092
pkarklin,

согласен. Но вообще в СУБД достаточно умная подсистема IO. Например при сканировании здоровенной таблицы всё идёт "мимо" кэша так чтобы он не вытеснялся. Хотя в ряде случаев этого не избежать.
8 мар 15, 20:28    [17359061]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
Dimitry Sibiryakov
Member

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

Симонов Денис
вот.

Согласно этому документу при чтении новых
страниц, грязные сбрасываются в общем порядке LRU. Чекпоинты тут ни при чём.

Posted via ActualForum NNTP Server 1.5

8 мар 15, 20:30    [17359066]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
Sergey Orlov
Member

Откуда: СПб
Сообщений: 4508
Любитель MSSQL
Симонов Денис
Любитель MSSQL,
не может. Потому как действует правило Careful Write. Страницы пишутся только в определённом порядке, чтобы любая прерванная запись не сделала транзакцию случайно подтверждённой. В случае аварии те страницы которые были записаны, но для них не было проставлено подтверждении транзакции в TIP просто окажутся мусором.

то есть при фиксации транзакции всегда происходит сброс "грязных страниц" на диск верно?

А они при этом уже не "грязные"...
8 мар 15, 21:52    [17359204]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
Зимаргл
Guest
Кстати, напомнили.

В SQL server используется собственное кэширование диска, более заточенное под свои задачи.
Кроме того, это убирает дублирование кэша СУБДой и ОСью.

Я не замечал, чтобы это как то влияло на производительность, но память должно экономить - факт.
9 мар 15, 03:36    [17359788]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
Dimitry Sibiryakov
Member

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

Зимаргл
В SQL server используется собственное кэширование диска, более заточенное
под свои задачи.

И чем же оно отличается от обычного LRU?

Posted via ActualForum NNTP Server 1.5

9 мар 15, 12:40    [17360172]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 11092
Dimitry Sibiryakov,

у MS SQL кэша как минимум есть преимущество в упреждающем чтении и мультиблочном чтении. В FB собственный кэш этого пока не умеет.
9 мар 15, 12:47    [17360186]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
Dimitry Sibiryakov
Member

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

Симонов Денис
у MS SQL кэша как минимум есть преимущество в упреждающем чтении и
мультиблочном чтении.

Кэш ОСи сам делает упреждающее чтение, так что в этом нет преимущества.

Posted via ActualForum NNTP Server 1.5

9 мар 15, 13:04    [17360217]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 11092
Dimitry Sibiryakov,

да но кешу ОСи абсолютно до лампочки чего он там упреждающе читает, т.е. могут попасться как нужные так и не нужные в данный момент страницы. Я думаю не зря Влад работает над этой темой.
9 мар 15, 13:20    [17360266]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 4 5 6 7 8 [9] 10 11 12 13 14   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить