SASGIS - SAS.Планета
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0001874SAS.Планета[All Projects] Хотелкаpublic03-04-2013 16:2721-02-2014 21:08
ReporterParasite 
Assigned Tozed 
PrioritynormalSeveritytweakReproducibilityN/A
StatusresolvedResolutionfixed 
PlatformWindowsOSServerOS Version2003
Product Version121010 
Target Version131111Fixed in Version131111 
Summary0001874: Berkeley cache: READ-ONLY
DescriptionДостала порча кэша при малейшем глюке САСа\системы и аварийном выходе по трем кнопкам, и последующие многодневные(!) проверки куч оного кэша при восстановлении. Любой зависон САСа и выход по трем кнопкам - извольте каждый раз восстановиться по всему активному на момент выхода кэшу. Это в моем случае занимает около недели причесывания кэша зедовой восстановлялкой - уж больно большой кэш...

Делать же его жестко рид-онли со стороны системы - чревато глюками уже в самом САСе.

Вот если бы сделать так, чтобы САС его мог открывать свой Беркли-кэш только на чтение...Никакая авария не страшна была бы.
Steps To Reproduce
Additional InformationПроблему разумлю в том, что кэш САСом всегда открывается как R\W - и при малейшей аварии извольте получить результаты в виде незавершенных сессий\транзакций и проч., даже если изменения кэша по факту даже и не планировалось.
TagsBerkeleyDB, ini, read only, БД, авария, краш, настройки, стабильность, только чтение
Relationships
Attached Files? StorageConfig.ini (129) 14-06-2013 12:13
https://bugtracker.sasgis.org/file_download.php?file_id=1384&type=bug
Issue History
Date ModifiedUsernameFieldChange
03-04-2013 16:27ParasiteNew Issue
03-04-2013 16:27ParasiteStatusnew => assigned
03-04-2013 16:27ParasiteAssigned To => zed
07-04-2013 10:05vdemidovProduct Version => 121010
07-04-2013 10:05vdemidovTarget Version => 24xxxx
08-04-2013 17:21zedNote Added: 0011044
08-04-2013 17:55vasketsovNote Added: 0011045
08-04-2013 18:01zedNote Added: 0011046
08-04-2013 18:20vasketsovNote Added: 0011047
08-04-2013 18:51vdemidovNote Added: 0011050
08-04-2013 18:55zedNote Added: 0011051
13-04-2013 18:09xromeoNote Added: 0011072
14-06-2013 12:12zedNote Added: 0011662
14-06-2013 12:13zedFile Added: StorageConfig.ini
14-06-2013 12:18zedNote Added: 0011663
15-06-2013 15:55zedStatusassigned => resolved
15-06-2013 15:55zedFixed in Version => 131111
15-06-2013 15:55zedResolutionopen => fixed
20-06-2013 06:58vdemidovTarget Version24xxxx => 131111
07-08-2013 16:36zedTag Attached: BerkeleyDB
07-08-2013 16:36zedTag Attached: ini
07-08-2013 16:36zedTag Attached: БД
07-08-2013 16:36zedTag Attached: настройки
07-08-2013 21:41cyclerTag Attached: авария
07-08-2013 21:41cyclerTag Attached: краш
07-08-2013 21:41cyclerTag Attached: стабильность
07-08-2013 21:44cyclerTag Attached: read only
07-08-2013 21:44cyclerTag Attached: только чтение
22-10-2013 14:12ParasiteNote Added: 0013115
22-10-2013 17:12zedNote Added: 0013116
21-02-2014 19:35zedNote Added: 0013837
21-02-2014 21:08vdemidovNote Added: 0013839

Notes
(0011044)
zed   
08-04-2013 17:21   
Вопрос, как это лучше сделать. Причём, нужно что-то универсальное, чтобы работало на любом кэше, а не только в Беркли.

Лучшее, что приходит на ум - создавать в папке с кэшем (cache\sat\) файлик abilities.ini и хранить там пользовательские настройки доступа к кэшу.

Вариант хранить эти настройки где-либо ещё (в zmp, к примеру) не прокатывает из-за возможности доступа к одному и тому же кэшу как из разных карт, так и из разных САСов, у которых могут быть абсолютно независимые настройки, и единственное, что их может объединять это папка с кэшем.

У кого какие мысли?
(0011045)
vasketsov   
08-04-2013 17:55   
>создавать в папке с кэшем ... файлик .. и хранить там ... настройки доступа к кэшу
Абсолютно верное решение.
Несомненным плюсом будет автоподхватывание при использовании всяких вторичных точек разбора (типа линков и сетевых шар), а также эти настройки будут копироваться при миграции кэша или бэкапировании простым копированием файлов батником. Да и при работе менеджера кэша (который плевать хотел на zmp) тоже будут использоваться эти настройки.
Что-то смущает?
(0011046)
zed   
08-04-2013 18:01   
Смущает то, что из САСа нельзя будет редактировать этот файлик. Т.е. менять настройки на лету. Иначе, придётся как-то изворачиваться с системой оповещения об изменениях (если такая вообще возможна). А хотелось бы управлять этим режимом прямо из настроек.

Плюс, надо как-то блокировать доступ на редактирование этого файлика, пока запущен хоть один экземпляр программы.
(0011047)
vasketsov   
08-04-2013 18:20   
Так наоборот всё логично получается. Кэш как единая сущность - только для чтения. Эта настройка никакого отношения к конкретному сасу в принципе не может иметь. И на лету править это нелогично. Если запущены несколько сасов - надо пройти и во всех включить доступ, или как? А если между сасами доступа нет, и никак извещение не послать?

>хотелось бы управлять этим режимом прямо из настроек
Ну и будет что-то типа старых флагов в zmp )))

>что-то универсальное, чтобы работало на любом кэше
Зачем? Все файловые вроде как нормально реагируют на то, что права на запись оборваны (разве что неуместный вызов ForceDirectories может нагадить, но это отдельный вопрос). У СУБД свои настройки прав. Для SQLite есть возможность родной настройки работы без доступа на запись. Для GE и GC в принципе неприменимо, они без записи. Только беркли и остаётся. Так что имеет смысл что-нибудь именно для беркли придумать, не обязательно только readonly, там наверняка есть ещё специфичные настройки, например тот же размер страницы. Ну а появится BigData или LocalDB или Tokyo/Kyoto или ещё какая муть - там опять же будут _свои_ специфичные настройки. Заодно не будет проблем, если в одной папке хранить кэши разного типа и переключаться между ними (например один только для чтения, второй - нет).
(0011050)
vdemidov   
08-04-2013 18:51   
Кстати, я давно хочу писать в папочку кэша информацию о проекции и типе данных, что бы оно выдавало предупреждение.
(0011051)
zed   
08-04-2013 18:55   
Ну, если там начать сохранять content-type, то менеджеру кэша сильно полегчает - не нужно будет вручную прописывать расширение для каждого хранилища.
(0011072)
xromeo   
13-04-2013 18:09   
А я вот сейчас озадачен вариантом "Делать же его жестко рид-онли со стороны системы - чревато глюками уже в самом САСе." - вот хотелось бы, чтобы как раз в этом случае глюков в САСе не было. Актуально в случае расшаривания кэша с правами доступа "Только чтение" для использования на многих других компах в локальной сети. Сейчас кэш хранится тайловый, и проблем нет, но хотелось бы перегнать в Berkeley и чтобы эта схема по-прежнему работала.
(0011662)
zed   
14-06-2013 12:12   
Итак, чтобы включить Read-Only режим для кэша Беркли, нужно:
- закрыть SAS
- создать файлик \cache_db\%имя_папки_с_кэшем%\StorageConfig.ini
- записать в тот файлик пару строк:
[BerkeleyDB]
IsReadOnly=1

Всё - при следующем запуске, кэш откроется только для чтения.
(0011663)
zed   
14-06-2013 12:18   
Приложил файлик StorageConfig.ini со всеми дефолтными параметрами. Можно пробовать изменять. Единственное, рекомендую не трогать параметр DatabasePageSize на живом кэше.
(0013115)
Parasite   
22-10-2013 14:12   
Реально ли это делать по-зумно? Например, один зум качаем - а остальные (уже укачанные, у той же карты) как-то сделать R/O?
(0013116)
zed   
22-10-2013 17:12   
Там каждый файл БД можно открывать в RO по-отдельности, но практического смысла это не имеет - SAS не открывает файлы БД до тех пор, пока ему действительно в них чего-то там не понадобится. Поэтому ты можешь открыть SAS на z1, загрузить область выделения, запустить закачку и ничего больше не трогать - у тебя будут открываться только те sdb, в которые реально нужно что-то записать и которые попадают в твою выделенную область. Ничего другого SAS открывать не станет. Поэтому реально ты рискуешь толь z1, а если и за него стрёмно - включи другую карту в гуе в RO (или RW), для осмотреться и стартануть закачку. Так что тут ничего выдумывать не нужно.
(0013837)
zed   
21-02-2014 19:35   
Обращаю внимание, что первоначальная идея RO кэша сломана: 0002014:0013835 т.е. теперь эта настройка внезапно переместилась в zmp, что по моему мнению не есть хорошо.
(0013839)
vdemidov   
21-02-2014 21:08   
Не совсем так. RO можно задать в zmp, в Maps.ini, а сейчас в StorageConfig.ini (поменялось только имя секции, раньше оно было в секции [BerkeleyDB], а сейчас будет в [Common]