|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Sergey Prach 2:5020/400 25 Dec 2002 17:46:53
To : Pavel V. Pasechnik
Subject : Re: Синхронизация доступа к БД
--------------------------------------------------------------------------------
Hi!
"Pavel V. Pasechnik" <Pavel.V.Pasechnik@f17.n5025.z2.fidonet.org>
сообщил/сообщила в новостях следующее: news:1014404069@mail.relex.ru...
> > А ну ка приведи пример реализации моментального SNAPSHOT-а для БД
> в
> > 10-20Гб, или хотя бё что бы он был более эффективен чем SERIAZABLE.
>
> А причём тут размер БД?
Hу тогда приведи пример реализации уровня SNAPSHOT, который не будет
зависеть от размера БД.
>
> > Тогда вопрос: а где будет хранится в сервере эта дельта, пока
> > конкурирующая транзакция будет удерживать страницу от изменений? А
> если
> > страница не удерживается, тогда где будет хранится первозданная
> страница для
> > конкурирующей транзакции?
>
> Hи с какими дельтами в этих случаях никто конечно не связывается, т.к.
> гораздо проще и быстрее сделать копию страницы. Только никак не пойму,
> какая тебе разница где она будет храниться ;-)
1. Так дельта есть или нет?
2. С каких это пор операции выделения новых страниц (а это прачктически
всегда дисковые операции), стали "проще и быстрее"?
3. Какая разница где она хранится? - да вообще-то никакой. Если она
хранится на диске, то это падение производительности за счет эскалации
дисковых операций. Если в памяти - тогда это тупое проедание операционных
ресурсов сервера, так как БД размером в несколько десятков гектар
встречаются довольно часто, а вот такие ресурсы ОЗУ или того же порядка -
довольно редко.
--
С уважением,
Сергей Прач
=================
Please, send you private mail to: s_pratch@mail.ru
--- ifmail v.2.15dev5
* Origin: LtawaSoft (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
