Kirill Temnenkov wrote:
@echo off
set reg_path=HKEY_LOCAL_MACHINE\SOFTWARE\Firebird Project\Firebird
Server\Instances
set reg_param=DefaultInstance
for /f tokens=1,2,* %%a in ('reg query %reg_path% /v
%reg_param%') do if %%a==%reg_param% set reg_value=%%c
echo %reg_value%
pause
Спасибо.
Может кто уже решал подобную задачу? Нужно сделать bat файл, который бы
интенсивно использовал утилиты fb из каталога bin. Причём без участия
узера. Проблема в том, что пути нет в PATH и ничего не работает. Если
способ извлечь в батник пусть из реестра?
Ещё вопросик. Есть ли способ вызывать
Ovchinnikov Vasily wrote:
Кури утилиту REG
C:\reg QUERY HKLM\SOFTWARE\Firebird Project\Firebird Server\Instances /v
DefaultInstance
HKEY_LOCAL_MACHINE\SOFTWARE\Firebird Project\Firebird Server\Instances
DefaultInstanceREG_SZC:\Program Files\Firebird\Firebird_1_5\
Результат ее
Пока возникло серьёзное подозрение на слубжу восстановление системы. Она
включена и в файле filelist.xml было расширение gdb. Вероятно эта слубжа
раз в сутки блокировала файл БД для создания точки восстановления...
Может какие службы у винды есть типа дефрагметатора/индексатора?
Кстати, расширение файла gdb. Может оно влияет?
Vlad Khorsun wrote:
У винды есть perfmon, который ты конечно же настроил и изучаешь логи
в моменты торможения...
Пока не могу, т.к. управляю этим сервером по эл. почте.
Нужно составить текстовую инструкцию админу широкого профиля по
настройке этого перфмона...
Alexey Popov wrote:
Как вижно разница скоро достигнет 2 и сработает sweep. Почему
транзацкции застревают - это отдельный вопрос, ранее такого не было.
Может быть rollback виноват???
Получается что после sweep разница обнуляется продолжается сразу расти
вновь? Что это может значить?
Khorsun Vlad wrote:
Виноват оказался sweep.
Откуда это видно ?
Сорри, тут я ступил, посмотрел на next
OIT застревает или от роллбека, или от лимбо. Это азы.
Но в данном случае я не вижу застрявшего OIT, ибо OAT = OIT + 1, т.е.
есть долгоиграющая тр-ция с номером 67773711. С ней и
Khorsun Vlad wrote:
Памяти 2Гб, диск один SATA2. Но и база то мелкая, зато реалтайм.
Если ты хочешь кешировать БД целиком, то по памяти ты на грани. Добавить
её не помешает. Если реалтайм, то почему авто-свип не запрещён ? Далее.
Кэшировать всю особо не нужно, т.к. интенсивно юзается
Arioch wrote:
какое-нибудь обновление антивируса/файрвола, которое на 20 секунд
блокирует TCP/IP ?
Период чуть больше 24 часов. Инета там нет.
Alexey Popov wrote:
Есть FB2.0 SS и служба работающая на этом же компе. Служба подписывается
на события и слушает их. Всё это работает много дней. В какой то момент
перестают доходить события до службы. Для проверки этой гипотезы сделано
тестовое событие, которые регулярно по таймеру
Ранее я писал:
Есть БД под FB2.0.3 SS. С ней постоянно работают несколько служебных
программ и периодически пользователи. В служебных программах
происходят только простейшие select/insert, которые выполняются
обычно мгновенно. Там так же сделана сигнализация (вывод в лог) если
какой то запрос
Vlad Khorsun wrote:
В логе клиента, скорее всего, будет сообщение об обрыве коннекта.
Не проверял.
1. А что клиент пишет что то в лог?
2. Если он просто лежит в system, то куда уйдёт лог?
Arioch wrote:
1) даже в этом случае, чем дальше, тем больше вероятность, что уже
случилось
2) запусти, действительно, регулярно повторяющийся ивент. При каком-то
постоянно происходящем запросе, чтобы раз в несколько минут посылался.
Перестал посылаться - значит пора переподключаться.
Oleg Matveyev wrote:
Есть такая проблема, причем и на 2.0.6
Аналогично - висит служба, которая до получения события не делает ничего.
Но очень желательно не пропускать ни одного события, потому что при
получении - надо сделать вычисления и положить в БД результат.
Правда, у меня в качестве
Oleg Matveyev wrote:
Клиент и база у тебя на одном компе?
Теперь на одном.
И всёравно события отваливаются ?
Oleg Matveyev wrote:
После переноса сервиса на сервер БД конфиг (приложения) остался прежним,
и строка коннекта была в виде 192.168.x.x:base
При отключении питания коммутатора - такой коннект отваливался.
Ого, спасибо, ценная информация! У меня тоже IP используется внешний!
Но у меня БД-шный
Есть FB2.0 SS и служба работающая на этом же компе. Служба подписывается
на события и слушает их. Всё это работает много дней. В какой то момент
перестают доходить события до службы. Для проверки этой гипотезы сделано
тестовое событие, которые регулярно по таймеру генерируется самой
службой и
Khorsun Vlad wrote:
Есть FB2.0
Нет такой версии
А вот и есть! 2.0.3.12981
Arioch wrote:
а тупо раз в сутки переподключаться? ;-)
Если это накапливающаяся проблема.
Если же это происходит случайно, то не поможет.
запусть какой-нибудь дампер и посмотреть
1) какие есть соедuнения между службой и сервером
2) что по ним проходит, насколько помню для событий зaводили
Khorsun Vlad wrote:
Такая есть. Но есть и 2.0.6, в которой что-то могло быть исправлено.
Есть релизноты и трекер для поиска этого чего-то.
На круглосуточной боевой базе стрёмно как то обновление делать.
Проблема наблюдается на одном инстансе из многих.
Khorsun Vlad wrote:
Тогда чего же ты хочешь ? Чтобы оно само прошло ? :-D
Может косяк ещё где... Может даже и в клиенте.
PS Ты багу-то хоть в трекере нашёл ? А искал ?
Нотах смотрел - похожего ничего нет.
PPS Я не искал. Но с ивентами многое исправлялось.
Так может лучше на 2.1
Khorsun Vlad wrote:
Я бы начал с настройки PerfMon'а и сопоставления его логов.
Свип можно отследить, мониторя OIT и OAT.
Кто бы написал тулзу, которая отображает разницу между OIT и OAT в
perfmon :).
Я просто вот думаю: sweep конечно тозмозит всех, но не настолько же.
Есть конечно
Есть БД под FB2.0 SS. С ней постоянно работают несколько служебных
программ и периодически пользователи.
В служебных программах происходят только простейшие select/insert,
которые выполняются обычно мгновенно. Там так же сделана сигнализация
(вывод в лог) если какой то запрос будет выполняться
Vlad Khorsun wrote:
Потому что ты ещё и хочешь потоковый анализ показаний делать,
насколько я
понял. Т.е. кто-то должен держать в памяти последние N показаний, и
*быстро*
реагировать на резкие их изменения.
Быстро не значит мгновенно. Есть критерии, логика которых затрагивает
измерения
Khorsun Vlad wrote:
Если тебе нужно отражать показания сотен датчиков *немедленно*, то
никакая
СУБД тебе не подойдёт.
Это ещё почему? Вполне быстро можно выбрать 100 последных записей по
индексу. Минимальный уровень латентности не реалтаймовский, но и 10сек
это много. Все показания
Vlad Khorsun wrote:
Не, экономить номера транзакций тут нет никакого желания.
Если ты собрался каждое показание сохранять в отдельной тр-ции, то я
такое не лечу,
это в другое учреждение :)
А зачем оприори делать через жопу? Если датчик допустим даёт показания
раз в 10 сек (или даже
Yurij wrote:
Если не писать напрямую с датчика в базу - все равно нужны будут
какие-то пляски с бубном насчет получить отчет по данным, которые
еще в базу не попали.
Не просто отчёты, а поиск в реальном времени нештатных и особых ситуаций.
Впрочем, я скидываю такие данные в базу одной
Khorsun Vlad wrote:
Во-первых *а*приори. Во-вторых - писать из датчика напрямую в БД
это и есть через жопу. Впрочем я выше написал что такое не лечу :)
Буфер есть, но только для нештатных ситуаций.
Я так и не понял, как ты предлагаешь вставлять записи, идущие от датчика
например раз в 1
Yurij wrote:
Такое чувство что не взлетит на FB.
На весьма хорошем железе взлетит и на FB, имхо.
Вопрос не только в железе. Больше к алгоритмам работы FB которые мало
оптимизированы на такие объёмы. Предел номера транзакции, скорость
prepare, размер TIP и PIP, глубина индексов, не 100%
Vlad Khorsun wrote:
Предел номера транзакции,
Причём тут такие объёмы ???
Предел в 2 миллиарда транзакций непреодолим.
Остальные утверждения были больше вопросами
не 100% заполнение страниц данными,
Это к dbf\csv\txt - там 100%.
Если в базу делается только insert и select, то
Vlad Khorsun wrote:
Предел в 2 миллиарда транзакций непреодолим.
Ну так не надо в него стучаться лбом - это больно и не нужно :)
Не, экономить номера транзакций тут нет никакого желания.
В 3-ке сделаем 4млрд. Потом посмотрим на возможность дальнейшего
расширения этого лимита.
Это уже
Yurij wrote:
Там есть печаль с такими данными, связанная с
равномерным приходом данных по времени и индексам.
Если выбирать данные по одному датчику по индексу,
то оно читает примерно так одна запись из таблицы -
одно чтение страницы данных. Потому что на этой странице
все остальные записи -
Есть такая задача. Нужно хранить N лет, показания M датчиков на K
объектах с дискретностью P секунд. Оценки показывают что надо хранить
порядка 10 миллиардов показаний (FLOAT).
Таблица измерений (без PK)
Время, ID датчика, значение
Индекс по времени desc.
Полезен ли будет индекс по датчику
Dmitri Kuzmenko wrote:
тюнить ФБ можно мало куда. И я говорю про конфигурации железа для СУБД
вообще. ФБ - одна из множества других СУБД.
Сейчас прибегут из множества других СУБД и будут вещать про
партиционирование и лог транзакций.
Железо для СУБД для среднестатитического админа ни о чём
Dmitry Yemanov wrote:
А что, кеш в 4 гига выставить для большой БД никак?
А интересно, кто пробовал такое делать?
Sergey Mereutsa wrote:
А что, кеш в 4 гига выставить для большой БД никак?
А интересно, кто пробовал такое делать?
Я, когда суперклассик ковырял. Работало, но сам суперклассик тогда
сырой был, пришлось ставить классик.
Вопрос то про суперсервер был. Суперклассик это совсем другое.
Никогда ещё не занимался комплектованием сервера для FB. Подскажите
кое какие моменты.
Планируется поставить простой зеркальный райд под базу.
Вопрос, надо ли ставить отдельный диск для системы, или тупо можно всё
свалить на массив? Других на нагрузок кроме FB не будет.
Если памяти в
Владимир Аксенов wrote:
Классические рекомендации:
- система - на отдельном винте
- TEMP - на отдельном винте
Темп и систему почему бы не одном в целях экономии? Тем более что
большой нагрузки на темп не будет.
Sergey Mereutsa wrote:
Рекомендации от экстремалов:
1) Система на SSD, своп нафиг. Взять 2 SSD и на втором держать
отстающую копию системы (как сие сделать на винде - понятия не
имею).
А смысл тут в SSD? На сервере чтение с системого диска не особо часто.
Вот что делать со свопом?
4)
Sergey Mereutsa wrote:
Если система ушла в своп - то где бы он не располагался - настаёт она
самая - ж.о.п.а. Поэтому, пусть лучше памяти будет много.
Своп вроде бы всегда используется виндой для своих нужд.
Тогда кэша страниц побольше, 64-битные сборки хорошо память жрать
умеют :0)
Dmitri Kuzmenko wrote:
можно я риторический вопрос задам, в пространство?
Поскольку ситуация с выбором железа у людей, работающих с ФБ,
просто ну никуда, не могу понять. Неужели эти люди
никогда не интересовались скоростью работы диска?
Не запускали HDTune? Не читали никаких обзоров про
Dmitri Kuzmenko wrote:
Время идет, рекомендации меняются. :-)
- система - на отдельном винте
- temp, база - можно на одном RAID 5 или 10
- бэкапы - на отдельном винте
В целях экономии можно бэкап наверное делать на системный винт, а оттуда
уже сливать по сети в надёжное место.
Dmitri Kuzmenko wrote:
Можно ли FW отключать или лучше оставить?
отключать можно, если это ФБ 2.1 и выше (см. firebird.conf)
Костыль однако. Но тем не менее...
или если
стоит raid с батарейкой. Но на raid с батарейкой может оказаться все
равно, Fw=on или off. зависит от крутизны raid.
Михаил Викторович wrote:
Я написал свое мнение о том, что человек прав, придя к идее архива.
Это плохая идея.
Если уж делать ахрив, то создавая копию базы на на какой то момент времени.
В одном из проектов мы использовали архивные таблицы в той же базе. Конечно
время бакапа растет, но пока
Михаил Викторович wrote:
Т.е. анализ планов запросов ниасилили?
Ну разве мы могли об этом сами догадаться? Спасибо вы сейчас посеяли в нас
столь исключительную своей оригинальностью мысль. :)
Тогда хотелось бы услышать о выявленных узких местах в вашей ситуации.
На самом деле есть
Михаил Викторович wrote:
Кто же их упомнит. Несколько десятков определенных вручную планов.
Ручные ещё не значит хорошие.
Вставка как вставка обычная где то в три-четыре таблицы, что про нее еще
можно сказать я не знаю.
Индексов штук 8-10 в каждой таблице. При активной работе 400-650
Vlad Khorsun wrote:
Да. Но это не связано с размером таблицы. Можно и на маленькой
таблице получить
большие тормоза при вставке - просто создав десятки индексов с длинными
ключами.
Вопрос то в рависимости от размера таблицы. Ведь она в любом случае
должна быть логарифмической.
PS
A K wrote:
Реальная ситуация. Большая база на большом предприятии. Работает
медленно. Идея: делаем архивную БД и оперативную, в которой держим
последние год-полтора.
Это ничего почти не даст. Если запросы используют только данные за
последнее время, то размер таблиц фактически не влияет за
Yurij wrote:
А как вы относитесь к функциональному программированию и около него
вообще?
Функциональное это слишком широкий термин. Функционально можно и на
голом C писать.
Если смотреть на SQL, то это типичный DSL. Но неплохо бы добавить
возможность определять локальные иммутабельные
Arioch wrote:
ну в высоконагруженных сильнопараллельных программах оно существует уже
не год-три,
Там рулят в основном C++, фортран и кобол. Увы.
Erlang и написанные под его влиянием библиотеки.
Erlang это прежде всего узкоспециализированный RTL, язык там дело десятое.
Vlad Khorsun wrote:
Я не собираюсь продолжать эту беседу ибо она была спровоцированна с
единственной целью - поржать в ЖЖ над частично процитированным и оторванным
от контекста моим частным мнением. Выставляя косным идиотом не только
меня (на
это мне наплевать), но и Firebird вместе со
Dmitry Yemanov wrote:
1) Внутрь сервера яву никто не тянет, там лишь интерфейс к ней.
Остальное снаружи в плагинах. Опционально.
Это вопрос технический - где будет работать JVM.
Однако тенденция неприятная.
2) Нормальный суперсервер есть в той же версии, что и ненавистная тебе
ява. Если ты
Dmitry Yemanov wrote:
Если смотреть на SQL, то это типичный DSL. Но неплохо бы добавить
возможность определять локальные иммутабельные переменные-множества типа:
x=select * from table
select * from x;
Это существенно упростит декомпозицию многоэтажных запросов и улучшит
читабельность.
Ну и
Dmitry Lendel wrote:
Я прошу прощения за бестолковость. Я не могу никак понять разницу между
суперклассик и супер.
Можно мне объяснить на пальцах?
Разница простая - нормальный полноценный суперсервер неасилили и
получился уродец - суперклассик, который почти как настоящий суперсервер
но
Dmitry Lendel wrote:
Разница простая - нормальный полноценный суперсервер неасилили и
Что ты имеешь ввиду под полноценным супером?
SMP софт с общим кэшем и минимальными издержками на взаимоблокировки.
Кстати у IB вроде сделан был такой.
получился уродец - суперклассик, который почти как
PEAKTOP wrote:
Допустим есть комп в инете со статическим IP. Мы подключаемся, все
нормально, РСУБД (распределенная СУБД) прекрасно работает.
Проходит время и филиал эволюционирует в укрупненное подразделение
(типа, становиться сержантом и у него уже свои подчиненные филиалы).
Ставим
Андрей Кручинин wrote:
В данном случае интересует какое-то значение которое является уникальным
для базы в глобальном смысле :-) Понимаю что стеб может быть, но тем не
менее интересно что можно попользовать для задачи регистрации клиента по
удаленке. Клиенты ставят программу сами, интересует
База ещё из под FB1.0, ODS 10.0
При попытке работы с ней под FB2.1, при попытке выполнить простой insert
получается странная ошибка
invalid request BLR at offset 11
column is not defined in table
после перевода на ODS 11.0 работает нормально.
Есть ли какой способ обойти проблему
Нужно узнать изменилось ли блоб-поле в триггере. Если написать
if(new.blob_field != old.blob_field) then ...
То что будет реально сравниваться? blob_id или побайтно содержимое?
В ib помню что сравнивались id.
Если побайтно, то значит тормоза на больших блобах?
Dmitry Yemanov wrote:
Сначала ID, если не равны, то содержимое (кусками по 1КБ, выход по
первому неравенству).
Логично. Только предварительно можно размер ещё сравнить, если он
легкодоступен.
В принципе тормоза будут только если обновлять тождественным значением,
что маловероятно.
ЗЫ.
Nikolay Ponomarenko wrote:
Лечится тем, что скрипт создания базы разбавляется реконнектами - после
каждой версии вставляется
Это давняя болезнь. У меня подобная обновлялка ещё со времём fb1.0 тупо
реконнект делает после каждого оператора и проверяет единственность
подключения к базе. Долго,
Dmitri Kuzmenko wrote:
Hello, Alexey!
Alexey Popov wrote:
Одного fbclient.dll недостаточно. Ему надо ещё firebird.msg и ещё какая
то левая dll, плюс рантайм от VC.
Просто кинуть fbclient.dll в system32 нельзя ибо он не найдёт свои файлы
без ключа в реестре. Да и MS уже не рекомендует
Dmitry Lendel wrote:
Стандартный инсталятор при указании установки только клиента делает всё
аналогично инсталяции сервера, только не все файлы ставит.
В смысле? Чего он не ставит?
Файлы сервера.
Просто кинуть fbclient.dll в system32 нельзя ибо он не найдёт свои файлы
без ключа в реестре.
По старинке софт юзает gds32.dll из каталога system32 винды.
Вроде бы этот метод устаревает.
Православный способ -грузить fbclient.dll из Firebird\bin.
Но обычно этого пути нет PATH, да и не нужен он там.
Поэтому софт должен делать LoadLibrary(fbclient.dll) с точным путём.
(Статическая линковка
Dmitry Beloshistov wrote:
Православный способ -грузить fbclient.dll из Firebird\bin.
У пользователей установлен сервер? А нафига, если в минимальном
случае достаточно fbclient.dll?
Стандартный инсталятор при указании установки только клиента делает всё
аналогично инсталяции сервера, только
Пока отбой тревоги. Добавил логов, оказывается параметр запроса почему
то внезапно стал чрезмено большим. Глюк в где то в другом месте.
Михаил Викторович wrote:
А
бизнес аналитиков их просто нет!
+1 Грамотный аналитик обеспечит себя работой на всю жизнь не обременяя
себя ковырянием в коде.
Dmitry Yemanov wrote:
У операционки кончились ресурсы в тот момент, когда сервер откатывал
операцию или транзакцию.
Интересно тогда зачем TIP нужен?
Kochmin Alexandr wrote:
кому то надо было проектировать ПО нормально. и учитывать нестабильный
канал.
Протокол TCP плохо себя ведёт на плохих каналах. Плюс его толком не
подкрутить. Кастомные протоколы позволили бы легко решать такие задачи.
Andrei wrote:
2) на стороне клиента (fbclient.dll). Предусмотреть функцию настройки
с тремя параметрами:
-- время ожидания восстановления соедиенения
-- период попыток повторного подключения
-- call back функция
Это всё слишком узко. Кардинальное решение - это возможность подсовывать
sasha wrote:
Интересно, насколько Delphi популярен ещё?
На BCB5 проекты живут у нас. Портировать на высшие версии уже поздно.
Ну я это всё к чему. К тому, что не достаточно иметь хороший сервер.
Нужны также и качественные библиотеки доступа к этому хорошему серверу.
Недавно был флуд на
Sergey Mereutsa wrote:
Так вот. Асинхронность, скажу я вам, штука зело вкусная, ежели её
применять правильно. Особенно, когда у тебя работа с девайсом, у
которого на борту 4 войсовых процессора и 30 войсовых каналов, которые
ты в цикле опрашиваешь и вся работа с которыми - это работа с
Khorsun Vlad wrote:
Ну написать клиента на какую либо платформу.
Каких платформ тебе не хватает ? Где *масса* применений ?
Как ты думаешь, почему ява и нет клиенты не хотят использовать gds32.dll
и ходят напрямую по сокетам? Почему? Зачем им этот секс?
Сейчас эти клиенты на птичьих
Игорь Горбонос wrote:
И чесно говоря я не понимаю, почему нельзя сделать для себя модуль,
который будет асинхронно выполняить запросы к БД, если есть такая
необходимость?
И как будет выглядеть этот модуль? Который должен быть универсальным.
Он не может вернуть курсор в другой поток, т.
Khorsun Vlad wrote:
Я же вижу ситуацию так - *он хочет* непонятно чего и зачем,
Применений масса. Я уже давно плачу что необходимо асинхронное
взаимодействие с сервером. Чтобы поток не тупо ждал ответа сервера в
блокирующем режиме, а мог в это время заниматься другими делами.
Допиливать
Khorsun Vlad wrote:
Применений масса.
Да ну ? Где ?
Ну написать клиента на какую либо платформу.
Я уже давно плачу что необходимо асинхронное взаимодействие с сервером.
Кому нужно ? Почему ты один об этом плачешь ?
Меня можно считать за десятерых :)
Не надо идти на поводу у
Khorsun Vlad wrote:
И где тут свой транспорт ???
Про транспорт это другая, более далёкая, хотелка.
Это годится только для приложения вроде hello firebird.
Это только пример, реализовав который можно постепенно доработать
функционал до желаемого уровня.
Описание всех пакетов
Khorsun Vlad wrote:
Про транспорт это другая, более далёкая, хотелка.
Так ты же с неё начал ?
В изначальном сообщении я высказал две мысли:
1) Доступ к серверу по сокетам.
2) Возможность указывать свой транспорт для gds32.dll
Нельзя ли в одной теме обсуждать ОДНУ вещь ?
Ну уж если
Dmitri Kuzmenko wrote:
возьми исходники клиента .Net или JayBird и посмотри.
Дык первого я и смотрел. Не в о том речь. Речь о написании клиентов на
всяких экзотических платформах коих сейчас расплодилось немерянно.
Ковырять левые сорцы юзающие недокументированные фичи - это не
Yurij wrote:
Имхо, проще рядом с FB поставить веб-сервис и завернуть всю бизнес-
логику в него, уж по HTTP с экзотических платформ ходить намного
проще, нежели реализовывать stateful протокол на всех мыслимых и
немыслимых вариациях железа и ОС.
3х звенку городить может быть не проще. Особенно
Khorsun Vlad wrote:
Диалог не получился... или ты меня не слышишь, или я тебя не понимаю.
Попробуем разжевать ещё раз. Предположим у нас есть некая
гипотетическая платформа, которая имеет доступ в сеть по TCP. На другом
компе крутится FB и слушает порт 3050. Надо сделать следующие вещи:
Dmitry Lendel wrote:
Про спонсора. Я, примером, не потяну по деньгам такую разработку, но
могу внести лепту в общий котел в размере 1000 USD налом и раза в три
больше безналом с НДС в грн. В девиз давайте скинемся я не верю. Тут
нужно находить заинтересованных. Один есть . :-))
Тут всего то
Khorsun Vlad wrote:
Тут всего то надо нормально специфицировать транспортный протокол на
уровне сокета.
Протокол - и всё ? Ты или оптимист, или бла-бла-бол :)
Давай конкретнее. Например, net клиент юзает напрямую сокет. При этом он
придерживается некоторого протокола. Так?
Что ещё надо
Khorsun Vlad wrote:
Почитай src/remote/interface.cpp и src/jrd/why.cpp. На пальцах - клиент
поддерживает свои списки аттачей\тр-ций\запросов\курсоров\блобов, кеширует
результаты выборки, поддерживает представление XSQLDA\XSQLVAR и т.п.
Дык и что? Ясное дело что имеем сильно stateful
Taras Kucher wrote:
http://www.ibase.ru/dataguard.html
http://www.slideshare.net/ibsurgeon/fbdataguard-1-2901922
http://www.slideshare.net/ibsurgeon/firebird-dataguard-in-russian-2735788
Ничего не понятно :(
Можно ссылку где конкретно написано что она конкрентно умеет делать и какой
алгоритм её работы.
Dmitri Kuzmenko wrote:
пусть лежит. Зато мы не даем гранату в руки неопытным пользователям.
как раз убрали после нескольких поломок баз вот таким образом.
Ну если у кого хватило ума ковырять живую базу без резевной копии?
Остальные то тут причём?
Поэтому без понимания этих структур
Dmitri Kuzmenko wrote:
и еще хочу добавить, что нефиг базы лечить :-)
надо их защищать FBDataGuard-ом.
Т.е. пора перестать бороться со следствием, и начать бороться с причиной.
Скрытая реклама detected!
Базы ломаются по причинам: сбоев питания, глюков ОС, рукоблудство юзеров и
т. п.
Dmitri Kuzmenko wrote:
Большинство баз лечится изменением пары байт в нужном месте.
да-да, конечно. Что-то я таких повреждений баз и не припомню.
Имеется ввиду чтобы FB начал читать её без ошибок. А потом конечно ручками
допиливать пока b/r не пройдёт.
Чаще всего бывают у меня wrong
Была удобная утилита IBSurgeon Viewer. Последняя найденная версия 1.0.2
На офф. сайте её вообще нет.
Больше не развивается?
Dmitri Kuzmenko wrote:
Была удобная утилита IBSurgeon Viewer. Последняя найденная версия 1.0.2
На офф. сайте её вообще нет.
давно убрали.
А зачем? Теперь она лежит на куче левых сайтов.
Утилита удобна для ручного лечения битых баз.
Больше не развивается?
нет, ибо без надобности. А
Игорь Горбонос wrote:
Спасибо, но по моему я имел в виду похожую статью, в которой акцент
делался на описание приемов навигации, т.е. тривиальные моменты:
- фетчь не всего набора, а только записей для грида + небольшой запас;
- при кардинальных перемещениях из начала в конец - не фетчить все
Dmitri Kuzmenko wrote:
?
- по умолчанию write
- для ro надо явно указывать read
Да, я же забыл что тут всё через жо.
Флаг isc_tpb_write по сути не нужен.
Вообщем с явным параметром read тоже самое.
To unsubscribe from this group, send email to ru-firebird+unsubscribegooglegroups.com or
Khorsun Vlad wrote:
И ты хочешь, чтобы тебя тут не пинали ? Выбирай слова и помни, что твоё
мнение не обязательно правильное мнение.
Хочешь об этом поговорить? Давай. Я считаю, что так проектировать нельзя.
Надо было:
1) либо сделать единственный флаг isc_tpb_read_only
2) либо обязательно
Vlad Khorsun wrote:
2. Настояшая мораль (в данном примере) - пользовать одну общую RO тр-цию
Дык понятно, посто при модульном и объектном построении софта не всегда
есть возможность договориться о кооперации в использовании единой транзакции.
А для явно RO транзакции надеюсь точно ничего
Vlad Khorsun wrote:
Вот именно это мы обсуждали в fb-architect. Есть идея как это можно
улучшить, просто нужно этим заняться. На пальцах - позволить нескольким
последовательно стартовавшим RO тр-циям использовать один и тот же
transation id. В этом случае только первая тр-ция будет что-то
Vlad Khorsun wrote:
Никакого не давать нельзя. Видимость записей определяется исходя из
номера читающей тр-ции и номера тр-ции, изменившей запись. Хотя... см. ниже
Тут нужно подумать. Может быть действительно можно будет RO RC тр-циям
тупо давать номер 1 :) Для не RC тр-ций это точно
Vlad Khorsun wrote:
Можно ли при коммите легко определить меняла ли транзакция чего или нет?
Да
Если нет, то и не вызывать flush.
См. выше :)
Проверил. Сделал в цикле 1 раз
StartTransaction
Commit
Транзакция
nowait
rec_version
read_committed
Сервер FB2.0.3, FW=On.
Сильно
Vlad Khorsun wrote:
Сервер FB2.0.3, FW=On.
SS или CS ?
SS.
Вопрос ещё в том, что происходит со грязными страницами после, если не по
коммит не делается flush.
To unsubscribe from this group, send email to ru-firebird+unsubscribegooglegroups.com or
reply to this email with the
Результаты 1 - 100 из 561 matches
Mail list logo
