Привет !
надо было ставить FBDataGuard. Он бы предупредил про отсутствие
места.
Я не в курсе, а эта тулза работает под Linux ? Да и места там было
навалом, там скорее сработало ограничение на размер Temp каталога, этот
злосчастный индекс видимо его превысил. Сейчас это ограничение, естественно
On 29.03.2010 7:21, Dmitry Lendel wrote:
Привет
Прошу прощения за невежество, но что означает слово Гедымин?
Дмитрий
князь такой был белорусский
http://ru.wikipedia.org/wiki/Гедимин
по совместительству рабочее название проекта, которое в итоге стало
официальным названием. как Делфи у
Привет!
И мне показалось, что на
будущее неплохо иметь такую инфу в конце лога. Я же не требую, никого не
обвиняю, и так понял, что сам виноват. Нет так нет - приспособимся Но как
никогда хотелось бы все же услышать начальника транспортного цеха (с)
Влад в приватной беседе посоветовал
Hello, Vsevolod!
Vsevolod wrote:
Хотелось бы послушать начальника транспортного цеха (с)
надо было ставить FBDataGuard. Он бы предупредил про отсутствие
места.
Собственно, по идее, когда происходят ошибки при restore,
то база должна оставаться в состоянии shutdown.
если у тебя все
Dmitry Lendel ...
Привет
Столкнулся с такой проблемой
Есть сеть. В несколько компьютеров.
Есть транзакция с параметром Lock write
Ситуация такая. Одни из пользователей запускает такую транзакцию, другой лезет менять что-то. Обычно выкидывает Lock conflict, а
тут компьютер уходит в ступор.
Vsevolod пишет:
Самое обидное что в конце лог файла рестора все было хорошо, что меня, в
принципе и сбило с толку и я потерял время :
gbak:activating and creating deferred index RDB$FOREIGN101
gbak:committing metadata
gbak:finishing, closing, and going home
Sat Jul 16 05:45:32 EEST 2011
ðÒÉ×ÅÔ!
ÔÁËÏÍ ÓÌÕÞÁÅ ÎÁÄÏ ÐÒÏÓÔÏ ÐÏÓÌÁÔØ Õ×ÅÄÏÍÌÅÎÉÅ ÁÄÍÉÎÕ É ×Ó£. é gbak
ÞÅÓÔÎÏ ×ÏÚ×ÒÁÝÁÅÔ ÎÅÎÕÌÅ×ÏÊ ËÏÄ ÏÛÉÂËÉ ÔÏÍÕ ÐÒÏÃÅÓÓÕ, ËÏÔÏÒÙÊ ÅÇÏ
×ÙÚ×ÁÌ.
gbak ÞÅÓÔÎÏ ×ÏÚ×ÒÁÝÁÅÔ ÎÅÎÕÌÅ×ÏÊ ËÏÄ ÏÛÉÂËÉ ÅÓÌÉ ÅÍÕ îå ÕËÁÚÁÌÉ ÐÁÒÁÍÅÔÒ -v
ÔÏÇÄÁ ÄÅÊÓÔ×ÉÔÅÌØÎÏ %ERRORLEVEL%=1
É × ÌÏÇÅ:
...
gbak:
Khorsun Vlad сообщил(а) в новостях
следующее:j0b59g$r4n$1...@dough.gmane.org...
Dmitry Lendel ...
Привет
Столкнулся с такой проблемой
Есть сеть. В несколько компьютеров.
Есть транзакция с параметром Lock write
Ситуация такая. Одни из пользователей запускает такую транзакцию, другой
лезет
Dmitry Lendel ...
Dmitry Lendel ...
Привет
Столкнулся с такой проблемой
Есть сеть. В несколько компьютеров.
Есть транзакция с параметром Lock write
Ситуация такая. Одни из пользователей запускает такую транзакцию, другой
лезет менять что-то. Обычно выкидывает Lock conflict, а тут компьютер
Привет!
Аааа, так тебе рюшечку хочется? Да, рюшечки иногда нужны, я согласен,
что было бы хорошо иметь подобный визуальный отчёт в конце работы.
Мы, рюшечкофилы, твою позицию поняли :) Хотя я не назвал бы это рюшечкой.
Да, и слабо верится, что ты на все случаи жизни используешь скрипты для
Привет!
В вопросе содержится ответ ;-)
Я так понял моя гипотеза, что я сам дурак, является верной :) Хотя ...
Вывести в конце лога какие-то предупреждения, на мой взгляд, все же не
помешало бы.
Хотелось бы послушать начальника транспортного цеха (с)
Вот уж кому-кому, а линуксоиду грех
Привет!
А зачем? Если есть _хотя бы одна_ ошибка - с базой что-то не то. В
таком случае надо просто послать уведомление админу и всё. И gbak
честно возвращает ненулевой код ошибки тому процессу, который его
вызвал.
Удивлен.
Есть gbak, консоль и админ за консолью, запускающий _штатный_
Хм. Есть общие правила выбора. Писалось (выше или ниже) как посмотреть
Есть прикладная задача (база)
Есть в базе узкие места, которые зависят от логики базы, объема данных и
т.д.
Прежде чем выбирать железо, набиваем базу тестовыми данными и тогда
становиться понятным, что
запрос в триггере
Vsevolod пишет:
В связи с этим у меня вопрос - это так и должно было быть и всегда было и я
сам дурак или все же неплохо было бы выводить какие-то сообщения в конце
лога в случае каких-либо ошибок ?
Присоединяюсь. Хотя бы счетчик ошибок в конце лога.
Привет!
Присоединяюсь. Хотя бы счетчик ошибок в конце лога.
А зачем? Если есть _хотя бы одна_ ошибка - с базой что-то не то. В
таком случае надо просто послать уведомление админу и всё. И gbak
честно возвращает ненулевой код ошибки тому процессу, который его
вызвал.
--
Best regards,
Sergey
Sergey Mereutsa пишет:
Присоединяюсь. Хотя бы счетчик ошибок в конце лога.
А зачем? Если есть _хотя бы одна_ ошибка - с базой что-то не то. В
таком случае надо просто послать уведомление админу и всё. И gbak
честно возвращает ненулевой код ошибки тому процессу, который его
вызвал.
Удивлен.
Привет!
В связи с этим у меня вопрос - это так и должно было быть и всегда было и я
сам дурак или все же неплохо было бы выводить какие-то сообщения в конце
лога в случае каких-либо ошибок ?
В вопросе содержится ответ ;-)
P.S. LI-V6.3.1.17910 Firebird 2.1 Classic, OS Linux Ubuntu 7.1
Dmitri Kuzmenko ...
С IB вообще интереснее в том плане, что если ему кэша не хватает,
то он его увеличивает, это можно отследить, пишет в логи сообщения типа
Это есть и в IB6. Только в лог не пишется.
--
Хорсун Влад
если что, то:
Версия сервера = WI-V6.3.0.26130 Firebird 2.5
Имя компьютера/порт = localhost
IP сервера = 127.0.0.1
Hello, Arioch!
Arioch wrote:
2) а что скажет Perfmon ?
скажет (для меня), как минимум - что происходит с диском. Перфмон я имел
в виду как ОДНО ИЗсредств понимания происходящего на сервере.
Разумеется, нужно и другие средства использовать.
Возможно такие ликбезы нужны не только
Hello, A. Truhin!
A.Truhin wrote:
А о чем тема то была? С начала? О выборе сервера под задачу! И о каком
perfmon говорить если сервера еще нет! Вообще то что я написал, меня на
данный момент не интересует, я прекрасно на опыте (который сын ошибок
трудных) знаю, что нужно мне, под мою задачу.
так они ж не знают, какие у клиента хотелки. Это, вообще-то,
даже не предпродажная консультация. Это реальная консультация
на тему
- текущее состояние, причины тормозов
- перспективы
- резервное копирование
мы этим и занимаемся, кстати. За деньги :-)
Ты опять говоришь о ситуации апгэйда
15.07.2011 14:33, A K пишет:
Полез разбираться дальше и обнаружил следующую интересную вещь --
из таблицы RDB$PROCEDURE_PARAMETERS идет 8 236 710 (!) неиндексированных
чтений.
Вопрос: причем здесь параметры процедур, когда удаляются триггеры и
таблички, и почему такое гигантское количество
15.07.2011 20:12, Dmitri Kuzmenko пишет:
Hello, A. Truhin!
A.Truhin wrote:
А о чем тема то была? С начала? О выборе сервера под задачу! И о каком
perfmon говорить если сервера еще нет! Вообще то что я написал, меня на
данный момент не интересует, я прекрасно на опыте (который сын ошибок
Вместе с таблицами удаляются и домены. А для этого надо убедиться, чтобы
они не использовались в параметрах процедур. А поле RDB$FIELD_SOURCE, по
которому идет поиск, неиндексировано. Попробуй создать по нему индекс и
перепроверить.
по времени не сильно помогло. неиндексированные чтения
Hekkim A.Truhin!
A.Truhin wrote:
Ты опять говоришь о ситуации апгэйда существующего железа. А речь с
начала топика идет о подборе железа под НОВУЮ, БУДУЩУЮ задачу, по
крайней мере, автор ни где не сказал, что у него уже задача работает и
тормозит.
ё-мое. как человеку выбрать компьютер, если
Hello, A.Truhin!
A.Truhin wrote:
Вот тут ключевой момент в том, что Вот, мы знаем как работает ФБ на
машине 1, 2, 3Мы можем экстраполировать, я например тоже знаю
(касаемо моих задач), но вопрос автора, в том и заключается что он не
знает. Не у всех есть возможность сравнить работу FB на
Hello, A.Truhin!
A.Truhin wrote:
Вот тут ключевой момент в том, что Вот, мы знаем как работает ФБ на
машине 1, 2, 3Мы можем экстраполировать, я например тоже знаю
(касаемо моих задач), но вопрос автора, в том и заключается что он не
знает. Не у всех есть возможность сравнить работу FB на
Khorsun Vlad hv...@optima.com.ua
сообщил/сообщила в новостях следующее: news:iuklug$bcf$1...@dough.gmane.org...
Внешние соединения кешироваться будут, но точно не в 2.5.1
В 3.0 будут? Этот вопрос для меня очень животрепещущ.
Hello, Dmitry!
Dmitry Yemanov wrote:
пользы нет, только если ты не упрешься вдруг в нехватку
памяти на 32-битном супере (2гига).
Таких значений, если я правильно помню, достигают люди только
с утечками памяти в udf.
А что, кеш в 4 гига выставить для большой БД никак? Или типа с большими
БД
Hello, Alexey!
Alexey Popov wrote:
С админов толку мало, т.к. они широкого профиля. Тюнить FB всё равно
разработчику. У нас просто пока не было столь высоких нагрузок, но
сейчас стоит вопрос об установке нового сервера.
тюнить ФБ можно мало куда. И я говорю про конфигурации железа для СУБД
Voroshin Dmitry wrote ...
Khorsun Vlad сообщил/сообщила в новостях ...
Внешние соединения кешироваться будут, но точно не в 2.5.1
В 3.0 будут? Этот вопрос для меня очень животрепещущ.
Это есть в todo, но не с самым высоким приоритетом.
--
Хорсун Влад
Vlad Khorsun hv...@optima.com.ua
сообщил/сообщила в новостях следующее: news:ivmbdn$ktc$1...@dough.gmane.org...
Voroshin Dmitry wrote ...
Khorsun Vlad сообщил/сообщила в новостях ...
Внешние соединения кешироваться будут, но точно не в 2.5.1
В 3.0 будут? Этот вопрос для меня очень
Hello, A.Truhin!
A.Truhin wrote:
возникает вопрос:
сколько и каких ресурсов нужно FB, для определенного профиля работы.
у кого этот вопрос возникает - у сферического SQL-программиста?
Например, вопрос выбора классика или супера ФБ разжеван в
достаточно многих местах.
Про память - взял да
Dmitri Kuzmenko wrote:
тюнить ФБ можно мало куда. И я говорю про конфигурации железа для СУБД
вообще. ФБ - одна из множества других СУБД.
Сейчас прибегут из множества других СУБД и будут вещать про
партиционирование и лог транзакций.
Железо для СУБД для среднестатитического админа ни о чём
В письме от Thu, 14 Jul 2011 14:21:15 +0400, Dmitri Kuzmenko
k...@ibase.ru сообщал:
Могу ответить сразу - 300-400 - до 24 ядер. 8-12 ядер - 100
пользователей. Как-то так.
...
Например, почему я должен на сайте держать статью, в которой
объяснялось бы, как использовать PerfMon?
1) можно
14.07.2011 20:21, Dmitri Kuzmenko пишет:
Hello, A.Truhin!
A.Truhin wrote:
возникает вопрос:
сколько и каких ресурсов нужно FB, для определенного профиля работы.
у кого этот вопрос возникает - у сферического SQL-программиста?
Например, вопрос выбора классика или супера ФБ разжеван в
Привет!
Странно, почему никто не указывает варианта Ось+temp на обычный винт(ы),
а под базу - SSD. Вполне себе бюджетный и скоростной вариант.
Потому, что интенсивная работа с SSD означает базу Шрёдингера - рано
или поздно умрёт, но когда именно - узнаешь в неопределённый момент
времени. И
Dmitry Yemanov wrote:
А что, кеш в 4 гига выставить для большой БД никак?
А интересно, кто пробовал такое делать?
Потому, что интенсивная работа с SSD означает базу Шрёдингера - рано
или поздно умрёт, но когда именно - узнаешь в неопределённый момент
времени. И будет очень неприятно, если узнаешь об этом за пару часов
до начала отпуска.
Ну это ещё вопрос, конечно, что умрёт раньше, ssd или винт. Да и
Привет!
А что, кеш в 4 гига выставить для большой БД никак?
А интересно, кто пробовал такое делать?
Я, когда суперклассик ковырял. Работало, но сам суперклассик тогда
сырой был, пришлось ставить классик. Сейчас потестить просто негде -
всё в полёте :)
--
Best regards,
Sergey
Sergey Mereutsa wrote:
А что, кеш в 4 гига выставить для большой БД никак?
А интересно, кто пробовал такое делать?
Я, когда суперклассик ковырял. Работало, но сам суперклассик тогда
сырой был, пришлось ставить классик.
Вопрос то про суперсервер был. Суперклассик это совсем другое.
В письме от Tue, 12 Jul 2011 08:16:40 +0400, Михаил -
sokol...@gmail.com сообщал:
Тест
[+] Passed
:-D
--
Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/
В письме от Tue, 12 Jul 2011 20:15:11 +0400, Dmitri Kuzmenko
k...@ibase.ru сообщал:
уже давно даже для десктопов МС рекомендует
машинки с ДВУМЯ дисками. Один система и софт, другой - работа и данные.
O'RLY ?
а почему тогда \Users до сих пор ставится на c:\ и чёрт с ним с дефолтом -
но
Владимир Аксенов wrote:
Классические рекомендации:
- система - на отдельном винте
- TEMP - на отдельном винте
Темп и систему почему бы не одном в целях экономии? Тем более что
большой нагрузки на темп не будет.
Здравствуйте, Alexey.
Вы писали 12 июля 2011 г., 17:03:33:
Темп и систему почему бы не одном в целях экономии? Тем более что
большой нагрузки на темп не будет.
В целях экономии - можно. Но если цель ускориться - то лучше на разных. В темпе
идет сортировка выборки, если она в память не
Привет!
Классические рекомендации:
- система - на отдельном винте
- TEMP - на отдельном винте
- база - на отдельном винте/рейде
- если на этой машине будут бэкапы/перебэкапы - то для бэкапов
отдельный винт, что бы база и бэкап не лежали на одном винте - кроме
надежности влияет и
на
Sergey Mereutsa wrote:
Рекомендации от экстремалов:
1) Система на SSD, своп нафиг. Взять 2 SSD и на втором держать
отстающую копию системы (как сие сделать на винде - понятия не
имею).
А смысл тут в SSD? На сервере чтение с системого диска не особо часто.
Вот что делать со свопом?
4)
Привет!
1) Система на SSD, своп нафиг. Взять 2 SSD и на втором держать
отстающую копию системы (как сие сделать на винде - понятия не
имею).
А смысл тут в SSD? На сервере чтение с системого диска не особо часто.
Вот что делать со свопом?
Если система ушла в своп - то где бы он не
Hello, Владимир!
Владимир Аксенов wrote:
Классические рекомендации:
- система - на отдельном винте
- TEMP - на отдельном винте
- база - на отдельном винте/рейде
Время идет, рекомендации меняются. :-)
- система - на отдельном винте
- temp, база - можно на одном RAID 5 или 10
- бэкапы - на
Sergey Mereutsa wrote:
Если система ушла в своп - то где бы он не располагался - настаёт она
самая - ж.о.п.а. Поэтому, пусть лучше памяти будет много.
Своп вроде бы всегда используется виндой для своих нужд.
Тогда кэша страниц побольше, 64-битные сборки хорошо память жрать
умеют :0)
Hello, Alexey!
Alexey Popov wrote:
Никогда ещё не занимался комплектованием сервера для FB. Подскажите кое
какие моменты.
Планируется поставить простой зеркальный райд под базу.
ставь.
Вопрос, надо ли ставить отдельный диск для системы, или тупо можно всё
свалить на массив?
да, и
Hello, Sergey!
Sergey Mereutsa wrote:
Рекомендации от экстремалов:
1) Система на SSD, своп нафиг.
Серега, своп нафиг уже давно не смешно. Не нужно его выключать,
от этого один геморрой, и лучше не будет.
Собственно, ОС на SSD это не экстрим, это просто выкидывание
денег на ветер. Для
Hello, Alexey!
Alexey Popov wrote:
Своп вроде бы всегда используется виндой для своих нужд.
не слушай его про без свопа.
Кстати, есть какая польза от 64-битного супера?
Вроде максимальный размер кэша как то лимитирован.
пользы нет, только если ты не упрешься вдруг в нехватку
памяти на
Hello, Alexey!
Alexey Popov wrote:
Никогда ещё не занимался комплектованием сервера для FB. Подскажите кое
какие моменты.
можно я риторический вопрос задам, в пространство?
Поскольку ситуация с выбором железа у людей, работающих с ФБ,
просто ну никуда, не могу понять. Неужели эти люди
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.
12.07.2011 20:22, Dmitri Kuzmenko пишет:
Кстати, есть какая польза от 64-битного супера?
Вроде максимальный размер кэша как то лимитирован.
пользы нет, только если ты не упрешься вдруг в нехватку
памяти на 32-битном супере (2гига).
Таких значений, если я правильно помню, достигают люди только
Привет!
Если система ушла в своп - то где бы он не располагался - настаёт она
самая - ж.о.п.а. Поэтому, пусть лучше памяти будет много.
Своп вроде бы всегда используется виндой для своих нужд.
Это у вас на венде. У Пингвинов немного не так:
serj@auth:~$ free
total used
Привет!
Рекомендации от экстремалов:
1) Система на SSD, своп нафиг.
Серега, своп нафиг уже давно не смешно. Не нужно его выключать,
от этого один геморрой, и лучше не будет.
Собственно, ОС на SSD это не экстрим, это просто выкидывание
денег на ветер. Для ноутбуков - да, побыстрее
13.07.2011 2:28, Dmitri Kuzmenko пишет:
можно я риторический вопрос задам, в пространство?
Поскольку ситуация с выбором железа у людей, работающих с ФБ,
просто ну никуда, не могу понять. Неужели эти люди
никогда не интересовались скоростью работы диска?
Не запускали HDTune? Не читали
Тест
11 июля 2011 г. 20:17 пользователь Dmitri Kuzmenko k...@ibase.ru написал:
Hello!
Voroshin Dmitry wrote:
Что то не фурычит создание сообщений в группе.
очень даже фурычит.
--
Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
--
С Уважением
Соколюк Михаил
Dmitry Lendel ...
Привет
Я совсем запутался. Давно с этим не работал
Нужно посчитать разницу в часах и минутах
select
cast('0:00' as Time)+cast(a.Field1 as time)-+cast(a.Field2 as time)
from xf_invoice a
где Field2 timestamp
Это работает SELECT cast('0:00' AS time)+(cast('18:00' AS
Михаил Викторович wrote ...
Подскажите в IB была такая фигня, если в индексе низкая селективность, то
вставка начинала очень сильно тормозить, получалось что при вставке IB
просматривает все одинаковые значения ключа и только потом делает вставку в
конце, для борьбы с этим делали составные
Михаил Викторович wrote:
Я написал свое мнение о том, что человек прав, придя к идее архива.
Это плохая идея.
Если уж делать ахрив, то создавая копию базы на на какой то момент времени.
В одном из проектов мы использовали архивные таблицы в той же базе. Конечно
время бакапа растет, но пока
Т.е. анализ планов запросов ниасилили?
Ну разве мы могли об этом сами догадаться? Спасибо вы сейчас посеяли в нас
столь исключительную своей оригинальностью мысль. :)
На самом деле есть опредлённые проблемы у оптимизатора когда он выбирает
сливание битовых карт индексов на сверхбольшых
Михаил Викторович wrote:
Т.е. анализ планов запросов ниасилили?
Ну разве мы могли об этом сами догадаться? Спасибо вы сейчас посеяли в нас
столь исключительную своей оригинальностью мысль. :)
Тогда хотелось бы услышать о выявленных узких местах в вашей ситуации.
На самом деле есть
Михаил Викторович wrote:
Кто же их упомнит. Несколько десятков определенных вручную планов.
Ручные ещё не значит хорошие.
Вставка как вставка обычная где то в три-четыре таблицы, что про нее еще
можно сказать я не знаю.
Индексов штук 8-10 в каждой таблице. При активной работе 400-650
Михаил Викторович ...
Тест интересный, но я в нем не нашел теста на вставку большие таблицы когда
уже седаны индексы, падение будет существенным,
Прям предсказатель :-D
по хорошему тоже надо бы
протестировать, будет время займусь. Мой опыт говорит о том что убирая не
нужные индексы можно
Vlad Khorsun wrote:
Да. Но это не связано с размером таблицы. Можно и на маленькой
таблице получить
большие тормоза при вставке - просто создав десятки индексов с длинными
ключами.
Вопрос то в рависимости от размера таблицы. Ведь она в любом случае
должна быть логарифмической.
PS
Так тут дело не во вставке а в общем торможении сервера (ЦПУ, винт,
память) при большой нагрузке.
Это верно.
Если это суперсервер, то естественно большое количество кривых селектов
O да Вы оказывается экстрасенс.
Прям предсказатель :-D
А то :)
Подскажите в IB была такая фигня, если в индексе низкая селективность, то
вставка начинала очень сильно тормозить, получалось что при вставке IB
просматривает все одинаковые значения ключа и только потом делает вставку в
конце, для борьбы с этим делали
06.07.2011 18:59, Михаил Викторович пишет:
Подскажите в IB была такая фигня, если в индексе низкая селективность, то
вставка начинала очень сильно тормозить, получалось что при вставке IB
просматривает все одинаковые значения ключа и только потом делает вставку в
конце, для борьбы с этим
Подскажите в IB была такая фигня, если в индексе низкая селективность,
то
вставка начинала очень сильно тормозить, получалось что при вставке IB
просматривает все одинаковые значения ключа и только потом делает вставку
в
конце, для борьбы с этим делали составные ключи добавляя в них
06.07.2011 19:43, Михаил Викторович пишет:
Можно задать вопрос по другому. Опишу ситуацию есть таблица из 1 записей
в ней есть индекс по полю у которого всего два значения(приход/расход). В IB
было замечания что одинаковые значения ключа сортируются в порядке вставки в
базу для этого IB
A K wrote:
Реальная ситуация. Большая база на большом предприятии. Работает
медленно. Идея: делаем архивную БД и оперативную, в которой держим
последние год-полтора.
Это ничего почти не даст. Если запросы используют только данные за
последнее время, то размер таблиц фактически не влияет за
Может вполне хватит следующих действий и при существующей структуре:
* Более производительное оборудование специально выделенное под работу
СУБД - быстрый дисковый массив, много оперативной памяти, 64битный
Firebird;
если бы мы писали на оракле или на 1С, тогда да, стандартный подход
придти к
а так, имеем таких клиентов, которые элементарно жмутся на технике и
тяжко им что-то втолковать.
Значит остальное попробовать. Был случай когда добавление двух индексов
уменьшило время выполнения операции с 30 минут до 20 секунд. Наличие
долгих снэпшот транзакций может сильно нагружать
.
-Original Message-
From: ru-firebird@googlegroups.com [mailto:ru-firebird@googlegroups.com] On
Behalf Of Евгений Виноградный
Sent: Tuesday, July 05, 2011 9:37 PM
To: ru-firebird@googlegroups.com
Subject: Re: EXECUTE STATEMENT к другой базе в рамках установленного
коннекта
а так, имеем таких клиентов
On 05.07.2011 22:00, Михаил Викторович wrote:
В итоге все равно будет перегрузка по производительности. Решение с
архивом
верное. Теперь когда проектирую новые системы сразу предусматриваю
архивирование.
Тем не менее для более дельных рекомендаций по данному случаю мало
информации:
*
Тем не менее для более дельных рекомендаций ...
А зачем мне Ваши рекомендации? Разве их я спрашивал?
Я написал свое мнение о том, что человек прав, придя к идее архива. На счет
реализации на триггерах и использования передачи в другую базу возможно вам
видней, такой вариант пока не использовал и
On 01.07.2011 23:55, A K wrote:
Транзакций существенно меньше чем CRUD операций как правило.
я понимаю, что в общем случае их будет меньше. Но, например, накопил я
в логе десять изменений в разных таблицах. Идет комит транзакции.
Мне все равно придется выполнить десять EXECUTE STATEMENT к
А вот с синхронной репликацией на уровне триггеров есть реальный шанс
получить большие проблемы (по моему скромному мнению это путь в никуда).
Реальная ситуация. Большая база на большом предприятии. Работает
медленно. Идея: делаем архивную БД и оперативную, в которой держим
последние
A K ...
Реальная ситуация. Большая база на большом предприятии. Работает медленно.
Что именно медленно ? Запросы или обслуживание ?
Идея: делаем архивную БД и оперативную, в которой держим последние год-полтора.
И с чего бы оно стало быстрее ? Кривые запросы, читающие кучу не
нужной
On 04.07.2011 19:48, A K wrote:
Идея: делаем архивную БД и оперативную, в которой держим
последние год-полтора. Изменения в оперативной БД, должны попадать
на архивную.
Возьмите/купите одну из готовых систем репликации под Firebird - будет
дешевле и быстрее, чем изобретать велосипед.
Может
А по моему лучше в триггерах накапливать изменения, а репликацию делать
в отдельном потоке.
A K wrote ...
Добрый день!
Возможность выполнять EXECUTE STATEMENT на другой базе
позволяет легко реализовать надежную схему односторонней
онлайн репликации.
Но, вся засада в том, что коннект к базе открывается
каждый раз при выполнении оператора. Мы собрали у себя тестовый пример.
Изменения
On 01.07.2011 19:47, A K wrote:
Попробуйте выталкивать изменения не по каждому I\U\D а по коммиту
тр-ции.
А что это изменит? Все равно каждый EXECUTE STATEMENT будет
открывать-закрывать подключение к БД. Только что подвисать будет не
каждая операция, а комит транзакции.
Транзакций
Транзакций существенно меньше чем CRUD операций как правило.
я понимаю, что в общем случае их будет меньше. Но, например, накопил я
в логе десять изменений в разных таблицах. Идет комит транзакции.
Мне все равно придется выполнить десять EXECUTE STATEMENT к внешней
базе, причем каждый
Hello, Arioch!
Arioch wrote:
http://web.archive.org/web/20041009184946/http://ibase.ru/v6/conf/conf.htm
Во-первых, они уже никаким образом не относятся к FIDO :-)
Во-вторых, в них чётко прописано, что нужно включать MIME для MS OE :-)
Хоррроший документ :-D
из этого документа, кстати, явно
27.06.2011 21:47, Alexey Popov пишет:
1) Внутрь сервера яву никто не тянет, там лишь интерфейс к ней.
Остальное снаружи в плагинах. Опционально.
Это вопрос технический - где будет работать JVM.
Однако тенденция неприятная.
UDF тоже неприятная тенденция? Если нет, то в чем отличие?
2)
Tonal wrote ...
24.06.2011 13:49, Khorsun Vlad пишет:
EB вполне устраивает.
Он не будет рекурсивным.
Этому есть какие-то причины теоретического плана или технического?
Нет конечно, это мой каприз.
Мне казалось, что ЕБ ничем от сохранёнки не отличаются кроме наличия
имени. Если это
Наверняка. И не обязательно связанные с рекурсией и с CTE. Например, можно
вынести связи в отдельную таблицу и писать туда не только пары
непосредственных
parent\child, но и вообще всех child'ов данного parent'а. Другой подход
описания
дерева с помощью границ множеств есть у Celko (и у DK
Алексей Вишняков ...
Наверняка. И не обязательно связанные с рекурсией и с CTE. Например, можно
вынести связи в отдельную таблицу и писать туда не только пары
непосредственных
parent\child, но и вообще всех child'ов данного parent'а. Другой подход
описания
дерева с помощью границ множеств есть у
Ой, а можно ссылочку на сайт, пожалуйста? Я бы почитал, интересно.
Это шутка такая ? :-D Как можно не знать про www.ibase.ru ?
Я думал, на выделенном каком-то сервере.
Строго говоря, я в последнее время птице изменил, на мс скл ковыряюсь.
Но концепции-то везде одинаковые.
Смотри здесь
В письме от Tue, 28 Jun 2011 09:46:57 +0400, Tonal
to...@promsoft.ru сообщал:
Мне казалось, что ЕБ ничем от сохранёнки не отличаются кроме наличия
имени.
вообще, даже если бы так, это была бы не лямбда, а просто анонимная
функция.
не знаю как в высокой теории, но так на пальцах вроде
Здравствуйте, Arioch.
Вы писали 28 июня 2011 г., 0:10:57:
В письме от Mon, 27 Jun 2011 20:18:58 +0400, Alexey Popov
a...@novgorod.net сообщал:
В больших проектах совсем другое ставиться во главу угла, а не сколько
там синтаксического сахара в языке.
а FB действительно нужны БОЛЬШИЕ
Здравствуйте, Vlad.
Вы писали 28 июня 2011 г., 14:49:22:
У меня к тебе никаких претензий нет, даже наоборот - ты оживил эту
конференцию,
за что и спасибо :) Провокатором неоднократно выступает Yurij и я каждый раз
сожалею
о том, что что-то ему отвечаю. Ибо потом, после чтения его
В письме от Thu, 23 Jun 2011 06:42:24 +0400, Кравченко Алексей
ista...@ngs.ru сообщал:
если бы он перестраивался, наверное, ты бы не жаловался, что альтер
слишком быстро прошел :-)
я полагаю что при наличии индекса и других зависимостей alter просто не
выполнится
не знаю, как насчёт
Результаты 301 - 400 из 30361 matches
Mail list logo
