Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 [6] 7 8 9 10 .. 25   вперед  Ctrl
 Re: Есть ли будущее у файл-сервера?  [new]
Yo!!
Guest
2Alexey Sh
так давайте вы подеретесь с ЛП, а потом у победителя будем выяснять куда делась фея.

ЛП

Yo!!
автор
Т.е. в спец.файл (с расширением .ldb) пишется во-первых информация о том что именно заблокировано, во-вторых в самом этом файле монопольно блокируются отдельные куски (с помощью блокировок файловой системы). Соответственно если клиент отваливается - блокировки файловой системы снимаются, и прописанные блокировки базы данных теряют актуальность.

так что из .ldb прописанные блокировки исчезают магическим путем ? кто в нем зачищает после отвалившегося клиента ??

А они там кому-то мешают? Есть отметка о том, что запись заблокирована. При наличии такой отметки - проверяется ее валидность (обращением к предположительно залоченному средствами файловой системы куску файла). Не валидна - можно и убить ее нафиг. При желании можно убить и все остальные блокировки от отвалившегося клиента, чтобы при следующих обращениях клиенты не утруждали себя лишними проверками. Как именно ведет себя аксес - точно не скажу.


P.S. интересно как они работаеют с ситемой если из доков не понятно даже принципов работы ?
3 май 05, 14:04    [1513295]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Yo!!
P.S. интересно как они работаеют с ситемой если из доков не понятно даже принципов работы ?

Я более чем уверен, что 90% специалистов Access и не знают таких подробностей о работе Jet-движка. Он просто работает и делает, что нужно, когда появляются баги и падения БД, он предоставляет средства для исправления проблемы - по моему в большинстве случае это достаточно для разработки и сопровождения небольших систем. А я видел и большие - БД под 2 гига, 40 активно работающих пользователей и не слабая бизнес-логика сложных расчетов начислений, где несмотря на использование Терминал-Сервера, быстрой сети, источников бесперебойного питания и прочих ухищрений, все равно для администраторов этой системы команды "Восстановить БД", "Сжать БД", "Удалить индекс/Создать индекс" являются почти что штатными постоянными операциями в силу ФС архитектуры Jet.
3 май 05, 15:11    [1513532]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Alexey Sh
SergSuper
Alexey Sh
2 Yo!! :
йоптуть, с ораклом не путай, в ldb блокировки в файл не пишутся,

Extended byte range locks are locks placed outside the physical boundaries of a file — no data is ever physically locked.

Здесь написано что блокировки физически не блокируют данные, а пишутся в другое место, очевидно в ldb


Ещё раз повторяю в аксессе блокировки в файл не пишутся, а реализуются при помощи WindowsAPI LockFileEx


Повторять то Вы можете сколько угодно, но пока Вы не привели ничего подкрепляющее Вашу точку зрения. Даже наоборот - no data is ever physically locked - так что никаких LockFileEx.
Кстати посмотрел хелп по LockFileEx - делает практически тоже что и LockFile

Alexey Sh
Почувствуйте разницу между WriteFile и LockFile .

Это Вы к чему? К тому что не делается LockFile для mdb, а делается WriteFile в ldb? Ну дык и все об этом же. Или о чем то своём?

Кстати а для чего по Вашему тогда создаётся ldb и в чем его important role in the Microsoft Jet multiuser scheme?
3 май 05, 15:50    [1513697]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Alexey Sh
Member

Откуда: SPB
Сообщений: 1930
2 SergSuper : попытаюсь ответить ещё раз. на LDB файл вешаются блокировки при помощи LockFile(Ex).
В сам файл информация о блокировках НЕ пишется
3 май 05, 16:10    [1513778]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Yo!!
Guest
The Microsoft Jet database engine then opens the .ldb file (or creates one if one does not exist) and tries to place a lock at 10000001 hex. If Microsoft Jet is successful in obtaining this lock, it will write the computer and security name to the first 64 bytes of the file. If Microsoft Jet cannot acquire this lock, it will continue moving one byte further until a lock can be successfully obtained. After the user lock is acquired, the Microsoft Jet database engine will then write the computer and security name at the corresponding location in the .ldb file. For example, a user lock at 10000040 hex would write an entry starting at 4096 bytes in the physical part of the .ldb file.

три раза прочитал - нихера не понял.

2Alexey Sh
ты внятно рассказать можешь или нам нужно по 2 слова весь день из тебя вытягивать ?
3 май 05, 16:22    [1513826]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Мимо пробегал....
Guest
автор
Система, рассчитанная на работу с локальным хранилищем данных одного пользователя/приложения на одном компьютере (устройстве), всегда будет делать это эффективнее, чем аналогичная система, но рассчитанная на одновременное обслуживание множества пользователей и приложений. Говоря о будущем, вы забываете, что очень скоро БД появятся во множестве носимых устройств (PDA, Мобильники и пр.).


Ну вот... опять мы путаем БД и хранилище данных. Термин БД (и СУБД) имеет определённую историю и вполне ясный смысл. А хранилище данных - это все что угодно, хотя бы и тот же файл (хотя в последнее время появились что-токак то его втыкают куда не попадя). Ну и будет в карманном покемоне хранилище данных - и хорошо! кстати, они там (в покемонам) определенно были. И версант, как навороченная система управления такими хранилищами очень даже канает.
3 май 05, 16:37    [1513896]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Alexey Sh
2 SergSuper : попытаюсь ответить ещё раз. на LDB файл вешаются блокировки при помощи LockFile(Ex).
В сам файл информация о блокировках НЕ пишется

Ну дык а что же туда пишется то? Судя по цитате от Yo!! именно информация о блокировках
3 май 05, 17:14    [1514042]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Alexey Sh
Member

Откуда: SPB
Сообщений: 1930
SergSuper
Alexey Sh
2 SergSuper : попытаюсь ответить ещё раз. на LDB файл вешаются блокировки при помощи LockFile(Ex).
В сам файл информация о блокировках НЕ пишется

Ну дык а что же туда пишется то? Судя по цитате от Yo!! именно информация о блокировках


в ldb файл пишется 64 байта на каждое подключение (максимум 255)

в эти 64 байта пишется имя компьютера и аксессного пользователя.
Всё. Замки живут в памяти сервера, при закрытии файла - снимаются
3 май 05, 17:20    [1514065]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Yo!!
Guest
2Alexey Sh

гонишь.
3 май 05, 17:22    [1514072]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Alexey Sh
Member

Откуда: SPB
Сообщений: 1930
Yo!!
2Alexey Sh

гонишь.


В приведённой выше ссылке английским по белому всё написано.
3 май 05, 17:30    [1514101]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Yo!!
Guest
2Alexey Sh

гонишь.
3 май 05, 17:34    [1514120]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Alexey Sh
Member

Откуда: SPB
Сообщений: 1930
Yo!!
2Alexey Sh

гонишь.

Из двух спорящих один - дурак, другой - подлец.
3 май 05, 17:51    [1514178]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Yo!!
Guest
в ldb файл клиент пишет свое имя, в зависимости в какой кусок ldb он записал имя, такой range mdb типа "заблокировано". соответственно если клиент отвалился блокировка останется навсегда.
3 май 05, 18:15    [1514239]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Alexey Sh
Member

Откуда: SPB
Сообщений: 1930
Yo!!
в ldb файл клиент пишет свое имя, в зависимости в какой кусок ldb он записал имя, такой range mdb типа "заблокировано". соответственно если клиент отвалился блокировка останется навсегда.


Херня полная.
3 май 05, 19:04    [1514348]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
2 Yo

>>в ldb файл клиент пишет свое имя, в зависимости в какой кусок ldb он записал имя, такой range mdb типа "заблокировано".

Ну вроде так, только Range он пишет за пределы, в некий виртуальный Storage, очевидно потому, что винды позволяют так над файлом издеваться :

"The .ldb file plays an important role in the Microsoft Jet multiuser scheme. This file stores the computer and security names and has extended byte range locks placed on it by Microsoft Jet.....Extended byte range locks are locks placed outside the physical boundaries of a file — no data is ever physically locked. An example of this is placing a lock at 10 million hex for a file that has a physical size of only 64 bytes. In other words, a lock is virtually placed at a location that does not exist on the hard disk. This type of locking is used because extended byte range locks are not limited by the size of the physical file, allowing for locking algorithms that would not otherwise be possible. Also, placing locks inside a data file would prevent other users from reading that data. In the early dBASE days, a user could place a lock on a record located in the data file that prevented everyone from reading that data — when printing a report, for example."

Меня очень радует объяснение в стиле - This type of locking is used because extended byte range locks are not limited by the size of the physical file. Хех.
У Microsoft есть нормальные продукты, но ЭТО явно не из их числа.

Оригинал тутачки - http://www.microsoft.com/accessdev/articles/jetlund.htm

>>соответственно если клиент отвалился блокировка останется навсегда.

С первого взгляда похоже на то :

When a user closes a shared database, the user's entry is not removed from the .ldb file. However, it may be overwritten when another user opens the database. This means that you cannot use the .ldb file alone to determine who is currently using the database.

Непонятно как отличить юзера, который отвалился и чей пул блокировок may be overwritten от юзера который нормально соединён, но наверное статус юзера можно получить каким-нибудь вызовом. Через ldb-низззя.

Оригинал тутачки - http://support.microsoft.com/default.aspx?scid=KB;EN-US;208778

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

2 Alexey Sh
Молодой человек, может всё-таки всё-таки почитать чего, прежде чем делать заявления в стиле "Херня полная" на принципиально верные замечания ?
3 май 05, 19:57    [1514463]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Alexey Sh
Member

Откуда: SPB
Сообщений: 1930
2 Andreww : видите ли Уважаемый, я владею предметом и могу позволить себе назвать то что пишется оппонентами на последних двух страницах - бредом сивой кобылы.

По предмету разговора. Юзер, который отвалился -ЗАКРЫЛ файл , соответственно все его замки СНЯЛИСЬ.

Для поиска свободного слота в ldb и делаются попытки повесить замки в диапазоне 0x10000001-0x100000FF
3 май 05, 20:22    [1514505]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Alexey Sh
Member

Откуда: SPB
Сообщений: 1930
Дополнение : range - длиной в 1 байт
3 май 05, 20:33    [1514520]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
2 Alexey Sh

>>По предмету разговора. Юзер, который отвалился -ЗАКРЫЛ файл , соответственно все его замки СНЯЛИСЬ.

Владеть, владеть и ещё раз владеть. :)

Юзер не собирался ОТВАЛИВАТЬСЯ (hint хто-то задел сетевой кабель, чегой-то у юзера коротнуло, драйвер повис, клиентское приложение выдало Access Voliation etc) и как следствие коррекным вызовом API никто файл НЕ ЗАКРЫВАЛ.

КТО его КОРРЕКТНО закроет И ВЫЧИСТИТ БЛОКИРОВКИ (SMB протокол, файловая система, ядро NT, они разбираются в структуре ldb-ных файлов, правда ?) ведь речь идёт о РАЗДЕЛЯЕМОМ ДОСТУПЕ К ФАЙЛУ и ДОСТУПЕ К ЛЕЖАЩЕМУ РЯДОМ С НИМ ldb и никакого сервера который бы за этим следил нет и в помине (тут ведь каждый клиент сам себе сервер) ?

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

Про это вам Microsoft пишет.

А вы всё чем-то владете :(
3 май 05, 20:57    [1514541]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Alexey Sh
Member

Откуда: SPB
Сообщений: 1930
Да нах системе структура ldb файла.

Что происходит с открытыми файлами при закрытии (в т ч аварийном)приложения? Остаются открытыми до второго пришествия?


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

какжется и я это говорил - про набор соглашений, используемый JET
3 май 05, 22:29    [1514627]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
f_w_p
Member

Откуда:
Сообщений: 1603
ASCRUS
А я видел и большие - БД под 2 гига, 40 активно работающих пользователей и не слабая бизнес-логика сложных расчетов начислений, где несмотря на использование Терминал-Сервера, быстрой сети, источников бесперебойного питания и прочих ухищрений, все равно для администраторов этой системы команды "Восстановить БД", "Сжать БД", "Удалить индекс/Создать индекс" являются почти что штатными постоянными операциями в силу ФС архитектуры Jet.

Добавлю еще, что все эти операции над БД надо делать в exclusive режиме. А штатных средств разогнать юзеров нет. Вот и приходится извращаться.
4 май 05, 07:53    [1514809]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Сварог
Guest
Как человек поработавший и так и сяк скажу, что КС лучче - разработчику проще ;).
Хотя на одном и том же железе ФС работает быстрее для небольшого числа юзверей.

Кстати, мне пришлось разработать отказоустойчивую схему ФС для клиппера ;)
- это было рабочее место в кассе - непрерывный поток клиентов, а ДОС иногда вис (данные на новеле были) - ничего кассир перезагружался - и все работало - все изменения вразных файлах были согласованы и усе работало шустро ;).
Чем не транзакции. :)
4 май 05, 08:02    [1514815]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
люблю ФС
Guest
ASCRUS

Однако пользовательский ввод данных - наиболее примитивный пример использования транзакций, если бы все программы состояли из "Ввел документ/Сохранил документ", то было бы нам в этой жизни счастье :) Я так понимаю, раз Вы ничего не знаете о КС, то спрашивать Вас об уровнях изоляций в VFP наверное даже и не стоит ?


да, конечно не стОит :-)
Однако Вы ведете себя ИМХО несколько некорректно...
перефразирую вас: "поскольку Вы ничего не знаете о полетах в космос, думаю спрашивать вас о понятии временого континуума в КС не стоит?"

Может это и примитивный пример, но опать-таки - несколькими страницами выше некто утверждал "Вы получите "нераспознаваемый формат файла"", когда же я доказал, что если писать пальцами рук, а не ног - такого не будет... теперь Вы начинаете толкать некие Вам известные, но мне, к сожалению неизвестные термины.. намекая на что-то... однако ответа на прямо поставленный вопрос дать не хотите....
отсыда вывод: КС значительно лучше ФС, более того... он стоит на 5 голов выше, и, минимум 3 из этих голов основаны на простых заключениях: "ФС старье потому и КС лучше...."
Очень жаль, что конкретики нету...
4 май 05, 09:05    [1514877]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
люблю ФС
Guest
Сварог

Кстати, мне пришлось разработать отказоустойчивую схему ФС для клиппера ;)
- это было рабочее место в кассе - непрерывный поток клиентов, а ДОС иногда вис (данные на новеле были) - ничего кассир перезагружался - и все работало - все изменения вразных файлах были согласованы и усе работало шустро ;).
Чем не транзакции. :)


Кстати моя жена работает на сопровождении клипперовской программы... заметил, что там часто при падении сети появляется мессага "откат незавершенных транзакций"
Клиппер тот самый Саммер 85 версия (если не ошибаюсь)
Разве там были транзакции? или же это разработчики просто так назвали некий процесс?
4 май 05, 09:10    [1514886]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Alexey Sh
Member

Откуда: SPB
Сообщений: 1930
2 люблю ФС : Summer 87 :)
4 май 05, 09:46    [1514969]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Сварог
Guest
люблю ФС

Кстати моя жена работает на сопровождении клипперовской программы... заметил, что там часто при падении сети появляется мессага "откат незавершенных транзакций"
Клиппер тот самый Саммер 85 версия (если не ошибаюсь)
Разве там были транзакции? или же это разработчики просто так назвали некий процесс?

Нет нету там транзакций, это все хитрости разработчиков. :)
Моя реализация таких сообщений не требовала. :) хехе.

Их даже небыло в 5.1 версии :) Но саммер 85 я не знаю. Вроде был саммер 87.
4 май 05, 10:11    [1515062]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 [6] 7 8 9 10 .. 25   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить