Re: EXECUTE STATEMENT к другой базе в рамках установленного коннекта
On 06.07.2011 1:39, Михаил Викторович wrote: Тем не менее для более дельных рекомендаций ... А зачем мне Ваши рекомендации? Разве их я спрашивал? Я написал свое мнение о том, что человек прав, придя к идее архива. Вы написали ответ на мой пост. Так что ничего личного. Ответил в той же ветке.
Re: EXECUTE STATEMENT к другой базе в рамках установленного коннекта
On 05.07.2011 22:00, Михаил Викторович wrote: > В итоге все равно будет перегрузка по производительности. Решение с архивом > верное. Теперь когда проектирую новые системы сразу предусматриваю > архивирование. Тем не менее для более дельных рекомендаций по данному случаю мало информации: * Версия Firebird, тип и параметры. * Аппартаные ресурсы; * Продукт тиражируемый или заказной; * И т.п. P.S. И в результате настоятельно советовал бы не использовать синхронное обновление БД в триггерах на IUD операциях. Ну не будет это нормально работать на реальной системе в виду наличия концептуальной проблемы такого решения. А если еще учесть особенности/огрехи в проектировании БД...
Re: EXECUTE STATEMENT к другой базе в рамках установленного коннекта
а так, имеем таких клиентов, которые элементарно жмутся на технике и тяжко им что-то втолковать. Значит остальное попробовать. Был случай когда добавление двух индексов уменьшило время выполнения операции с 30 минут до 20 секунд. Наличие долгих снэпшот транзакций может сильно нагружать сервер и диски. Помогало увеличение оперативной памяти сервера. Увеличить память используемую под кеш страниц. Может вообще отказаться от классического сервера и использовать суперсервер, если так мало памяти. И т.п.
Re: EXECUTE STATEMENT к другой базе в рамках установленного коннекта
On 04.07.2011 19:48, A K wrote: Идея: делаем архивную БД и оперативную, в которой держим последние год-полтора. Изменения в оперативной БД, должны попадать на архивную. Возьмите/купите одну из готовых систем репликации под Firebird - будет дешевле и быстрее, чем изобретать велосипед. Может вполне хватит следующих действий и при существующей структуре: * Более производительное оборудование специально выделенное под работу СУБД - быстрый дисковый массив, много оперативной памяти, 64битный Firebird; * Изучение узких мест - вполне возможно будет достаточным построить пару-тройки дополнительных индексов, оптимизировать ряд SQL запросов, особенно если речь идет об отчетах; * Более частое архиврование БД; * Периодическое обслуживание БД - с проверкой структуры, сборкой мусора, проверка отсутствия множества активных транзакций, бэкап БД с последующим восстановлением и т.п.
Re: EXECUTE STATEMENT к другой базе в рамках установленного коннекта
On 01.07.2011 23:55, A K wrote: Транзакций существенно меньше чем CRUD операций как правило. я понимаю, что в общем случае их будет меньше. Но, например, накопил я в логе десять изменений в разных таблицах. Идет комит транзакции. Мне все равно придется выполнить десять EXECUTE STATEMENT к внешней базе, причем каждый EXECUTE STATEMENT будет открывать-закрывать коннект. так? Можно и в одном соединении это делать. Но реальная причина в другом - в другую(-ие) БД должны попадать только те изменения, которые подтверждены в данной БД. В противном случае при любом откате транзакции базы начнут разбегаться. В отличии от того же MS SQL в Firebird одно удовольствие лог транзакций вести, не полагаясь на всякие там часы и т.п. Причем если текущая транзакция отвалится, то из записей в журнале не будет (а можно использовать и временные таблицы). Да и такую модель можно развить в асинхронную оффлайн репликацию если понадобиться. А вот с синхронной репликацией на уровне триггеров есть реальный шанс получить большие проблемы (по моему скромному мнению это путь в никуда). Т.к. стабильные соединения бывают только в "сферическом вакууме". И порой достаточно одного сбоя на миллион операций, чтобы случилась "непоправимая" разбежка и лавинообразное возрастание количества ошибок.
Re: EXECUTE STATEMENT к другой базе в рамках установленного коннекта
On 01.07.2011 19:47, A K wrote: Попробуйте выталкивать изменения не по каждому I\U\D а по коммиту тр-ции. А что это изменит? Все равно каждый EXECUTE STATEMENT будет открывать-закрывать подключение к БД. Только что "подвисать" будет не каждая операция, а комит транзакции. Транзакций существенно меньше чем CRUD операций как правило. Собственно именно так и нужно делать - применять изменения в удаленную БД на коммите транзакции. Потому что при откате транзакции изменения в другую базу не попадут, что как правило и нужно. В любом случае без журнала транзакций, в который пишутся изменения, не обойтись. Требуемые триггеры для записи в журнал транзакции пишутся автогенерацией через тот же EXECUTE STATEMENT на основе данных системных таблиц. Как пример можно посмотреть этот проект http://fibre.sourceforge.net/. Там более сложный вариант реализован - инкрементальной оффлайн репликации на базе журнала транзаций.
Представление GUID в Fb и .Net
Доброго времени суток! Может не совсем по теме пишу. Но есть следующая проблема, касающаяся стыковки Firebird и .Net. Кратко ее суть - строковое представление одних и тех же данных полученное через встроенную функцию Firebird - UUID_TO_CHAR() отличается от представления возвращаемого экземпляром класса .Net framework Guid.ToString(). Естественно я имею в виду экземпляр класса полученный от .Net Data Provider из поля БД. Т.е. в результате выходит, что данные полученные посредством .Net Data Provider и UUID_TO_CHAR() из отдних и тех же данных визульно (в виде строк) будут отличаться. Подробности здесь - http://tracker.firebirdsql.org/browse/DNET-376 . Бага закрыта как не воспроизводимая, хотя тест показывает суть проблемы. С уважением, Евгений Виноградный aka ssdi.
Re: Господа, презабавнейшая идея
On 16.03.2011 17:38, Dmitry Sinchilin wrote: ну и делай для разных баз подключение по разным портам, а разные порты мапирую на шлюзе на разные компы. Так можно скрыть масштабирование системы. А из плюсов получить централизованную секьюрную базу (если конечно это будет работать в таком режиме). А из минусов на серверах редиректов будут жить ее кусочки. С уважением, Евгений Виноградный.
Re: Кто-то портит GDS32
On 02.02.2011 18:22, Konstantin R. Beliaev wrote: Никто не сталкивался с такой ситуацией: сервер лежит в каталоге C:\FB25, fbclient.dll скопирован в gds32.dll Прописываю в IBE работать через библиотеку C:\FB25\bin\gds32.dll - все работает, копирую в system32 и правлю путь в IBE - не работает, пишет: Client Library is missing or invalid. копирую из SYSTEM32 в C:\---\gds32.dll и опять правлю путь в IBE - не работает с тем же сообщением :(( Не Vista/7 случаем? Клиента с повышенными правами под админом копировали в system32? С уважением, Евгений Виноградный.
Re: Конструкция INSERT ... RETU RNING в запросах EXECUTE STATEMENT
On 23.12.2010 17:31, Victor Reshetnyak wrote: sql_1 = 'INSERT INTO RS_TEMPL_REP(NAME) VALUES(:NAME)' ||'RETURNING ID INTO :NEW_ID'; sql_1 должно быть DSQL выражением (а не PSQL). Либо нужно обернуть в EXECUTE BLOCK. С уважением, Евгений Виноградный.
Re: Переход 2.1 -> 2.5
Ovchinnikov Vasily пишет: -FIX_FSS_METADATA Тогда такой вопрос. В каких случаях нужно делать restore с таким ключом? Только если используется кодировка UNICODE_FSS? А если только UTF8 нужно ли?
Re: Толерантность к о брывам связи
On 02.11.2010 12:22, Andrei wrote: Чего сильно не хватает FB -- это устойчивости к обрывам связи. Устойчивость к обрывам связей повышают другими способами. Резервированием каналов например на аппаратном уровне. Описанный выше способ повысит только вероятность возникновения блокировок и количество "зависших" соединений. Пользователи приложений с синхронным доступом к БД вряд ли захотят ждать несколько часов реакции на свои действия, а тупо перезапустят приложение жестким способом.
Re: Вопросы ДЕ и Влад у
On 28.10.2010 0:51, Vadim Mescheryakov wrote: Я наверно плохо о людях думаю, но что то мне кажется что вменяемых разработчиков (вменяемых и при этом свободных) все меньше и меньше. Да не меньше их - их просто нужно больше. Посмотрите вокруг, сколько было компов на работающую душу 10 лет назад и сейчас, а это все ПО, которое нужно кому то писать, развивать, обрабатывать напильником и сопровождать. Раньше можно было найти профи работающего(подрабатывающего) за интерес и терпимую ЗП, сейчас все хотят денег, а зачастую неадекватных квалификации. Говорю не голословно - часто приходится проводить собеседования. А по поводу технологий - как ни крути 150 строчек кода в день никто не отменял. Вот только писать эти строчки можно на разных уровнях. Зачастую абстракции и технологии позволяют решать задачи на более высоких уровнях и более эффективно, но к сожалению требуют большей квалификации для грамотного применения. Те же управляемые языки (JAVA, .NET и т.п.) снимают кучу головной боли наличием сборки мусора в простых задачах, но и добавляют ее в сложных :))) ORM-ы снимают проблему маппинга данных в/из БД, что помогает при решении рутинных задач, но тем не менее не избавляют от написания nantive-SQL запросов. Та же дельфи - неплохая среда была, но если вспоминать, сколько нужно было писать для решения рутинных задач работы со словарями списками и прочим. Обратная совместимость и рожденные монструозные конструкции языка Delphi. Но технологии развиваются и позволяют решать более сложные задачи на более высоком уровне.
Re: Вопросы ДЕ и Влад у
On 27.10.2010 23:20, sasha wrote: А я про пользователей и не говорил. Мало причин при начале нового проекта не использовать EntityFramework, а задействовать датасеты. Если программист его не знает, то это не проблема EntityFramework, а личная проблема программиста. Если мы рассматриваем технологии доступа к данным в реляционных БД, то повторюсь EntityFramework - весьма своеобразная технология и применимо для определенных задач определенного масштаба. Тот же NHibernate для сложных корпоративных проектов гораздо перспективнее и удобнее. LINQToSQL MS сама похоронила, да и работает она только с MsSQL. А по поводу "задействовать датасеты" - в ADO.NET зачастую достаточно доступа на уровне команд и ридеров. При решении ряда задач ORM(EntityFramework) нужен как зайцу пятая нога. Можно микроскопом и гвозди забивать, а потом удивляться...
Re: Вопросы ДЕ и Влад у
On 27.10.2010 20:49, sasha wrote: Поддержка ADO для .NET вполне качественная А вы что, не знаете что основным средством доступа к данным у MS на данный момент является Entity Framework? Сейчас использовать ADO.NET - это всё равно что WinAPI для разработки Windows. Вообще странные утверждения. WinAPI никто не отменял пока есть вынь это единственный способ получить максимальную производительность. Entity Framework - вообще странная технология, которая пытается пройти все те грабли, которые давно прошли другие ORM. К тому же она не всегда работоспособна в полной мере с FB. По кр. мере в свое время когда выбирали ORM - пытались использовать и Entity Framework, но провайдера с поддержкой еще не было, были только аноносы. По поводу проблем использования Entity Framework и FB можно поискать отдельно. В сложных проектах, зачастую приходится использовать несколько технологий доступа к данным одновременно (ADO, ORM и бла бла). Saha Вы случаем не на дельфи пишете?
Re: OFF VS 2008 standart
Можно ли при помощи Visual Studio Standart 2008 разрабатывать приложения для мобильных устройств? Заранее спасибо Дмитрий Полноценная поддержка идет в версиях от Professional. Подробное сравнение возможностей можно скачать здесь - http://www.microsoft.com/downloads/en/details.aspx?familyid=727BCFB0-B575-47AB-9FD8-4EE067BB3A37&displaylang=en Или здесь - http://www.microsoft.com/visualstudio/en-us/products/2008-editions С уважением, Евгений Виноградный.
Re: superclassic win x64
On 29.07.2010 13:40, Andrei wrote: http://www.sinatica.com/blog/en/index.php/articles/firebird-superserver-classicserver-or-superclassic Спасибо за ссылку.
Re: superclassic win x64
On 28.07.2010 23:16, Дмитрий Еманов пишет: Случайность или 64-битный супер-классик не отработан ? Отработан. Более того, он только на 64-битах и имеет смысл :-) А можно ссылочку где почитать про основные отличия и "смысл" :) ? --- Евгений Виноградный
Re: Скорость инсертов
On 07.07.2010 10:39, Tonal wrote: Наткнулся на странную вещь: при массовой загрузки данных в базу скорость последовательности инсертов уменьшается на 1/6 если все они в одной транзакции. Память сервера тоже растёт, но это как бы ожидаемо... Я что-то не так делаю? Да, и на предыдущих версиях (1.5 - 2.1) где то после 150-200 INSERT в одной транзакции удельная скорость вставки понижалась, причем существенно. Возможно, это какие то особенности реализации сервера проявляются. С уважением, Евгений Виноградный.
Re: Windows7 Ultimate 64 and Firebird 2.5 64
On 25.06.2010 17:46, Khorsun Vlad wrote: С какой стати ? Никаких чудес. Ну, вот и хорошо, вот и прекрасно!
