Re: IP пользователя

[Dmitry Yemanov]

Alexander A. Venikov wrote:


PY> Запрос, приведенный ниже, возвращает какое-то 4-ех значное число.
PY> В чем я не прав?
PY> select rdb$get_context('SYSTEM', 'CLIENT_ADDRESS') from rdb$database
PY> Версия FB 2.0.2, classic

>

Локальный коннект?


Адназначна :-) В этом случае PID возвращается.


--
Дмитрий Еманов

Re: IP пользователя

[Alexander A. Venikov]

Hello, Plotnikov!
You wrote  on Thu, 24 May 2007 12:31:34 +0600:

PY> Запрос, приведенный ниже, возвращает какое-то 4-ех значное число.
PY> В чем я не прав?
PY> select rdb$get_context('SYSTEM', 'CLIENT_ADDRESS') from rdb$database
PY> Версия FB 2.0.2, classic
Локальный коннект?

--
Удач
Alexander A. Venikov, Tobolsk, Russia 

Проблема с уникодом так и не решилась

[Андрій Жук]

Вобщем, если создать наново базу, то все нормально.
А вот если перенести базу с 2.0 на 2.1, бекап на 2.0,
рестор на 2.1, то в процедурах с кириллицей вообще получим

(Blob read error:
can't format message 13:686 -- message system code -4.
Cannot transliterate character between character sets.
)

Если не делать бекап/рестор, то процедуры показываются нормально,
но после перекомпиляции получаем кракозябры

Отакоеот.

IP пользователя

[Plotnikov Y]

Привет всем (надеюсь я щас не промахнусь конфой)!

просили перепостить:

Запрос, приведенный ниже, возвращает какое-то 4-ех значное число.
В чем я не прав?
select rdb$get_context('SYSTEM', 'CLIENT_ADDRESS') from rdb$database
Версия FB 2.0.2, classic

-
ЗЫ: у меня самого все прекрасно работает. А у него почему то так.

Re: Резервныи сервер

[Oleg Matveyev]

Очень сочное обсуждение проблемы...

Я вот себе еще представил, как было бы здорово обновлять
метаданные на "зеркальных" серверах...
освободил от юзеров один сервер - обновил, никого не напрягая.
Запустил синхронизацию со вторым сервером
и на этом мысль остановливается :-)

Re: Резервныи сервер

[Сергей]

Janex:
> > Тоже думал на эту тему :)
> > Покупаем SATA салазки с горячей заменой для основного и резервного
> > серверов - 2x$10.
> > Покупаем шутрый винт, например WD Raptor 1rpm - $120.
> > Вставляем в основной сервер и делаем shadow базы на него.
> > В случае выхода из строя  - переносим Raptor на резервный сервер и запускаем
> > базу.
> > По идее операция должна занимать минут 5 от момента определения смерти
> > сервера.
> Не выход в моём случае - ночю и по выходным некому его заменить :)
> Ну вот такои вариант чему плох - соединяем оба сервяка оптикои, на
> главном шарим диск с резервного, както обманываем птицу чтоб
> позволяла класть тень на шаре.
>
> Или тож самое - оптика + шара и какоито софтwарныи однасторонныи "RAID"
> котории на шару делает копию бази ... если есть токие софти в природе
> вообше ...
>
> Regards
> Janex
iSCSI?

Re: глючок

[Gene Feudorov]

Hello, Alexandr Kochmin!
You wrote to Alexandr Kochmin on Wed, 23 May 2007 23:56:36 +0700:


 AK> попробовал еще раз сейчас.
 AK> Хм... пишет ошибку.
 AK> Что это было? Вопрос риторический.

ночью спать надо, а не бэкапы делать...
меньше вопросов будет риторических :-)

Фёдоров Евгений.
ЗАО "Трест-М". Екатеринбург.

Re: Текстовая индексация

[Kovalenko Dmitry]

> > Интересно как этот intersect будет работать с множествами c сотнями
> > тысяч записей. Формально, конечно, побыстрее чем join записей.
>
> Если твоя система умная, то она такие лексемы сначала проигнорирует, а
> потом подумает, что быстрее - каждый документ просмотреть или же
> все-таки пересечение с очень большим списком делать (или вообще нафиг ее
> выбросить).

Она то умная. Это у меня мозгов на все сразу не хватает :)

Тут есть одна мысль. И очень хочется что бы она оказалась в тему.

О результатах отпишусь :)

Коваленко Дмитрий.

Re: Домены в параметрах процедур

[Dmitry Yemanov]

sasha wrote:


Что ему передать?


Что мы исправим :-)


--
Дмитрий Еманов

Re: ��������� �����

[Vadim Mescheryakov]

> óÁÄÁÞÁ ÓÌÅÄÕÀÛÁÑ - ÚÁËÁÚÛÉË ÈÏÞÅÔ ÇÁÒÁÎÔÉÉ ÎÁ 100% ÞÔÏ ÂÁÚÁ ÂÕÄÅÔ ÄÏÓÔÕÐÎÁ 
> ÎÁ ×ÓÅ 24/7 ÄÁÖÅ ÅÓÌÉ ÓÅÒ×ÅÒ ÎÁÔÕÒÁÌØÎÏ ÓÇÏÒÉÔ ÓÉÎÅÍ ÐÌÁÍÅÎÅÍ :)

÷ ÜÔÏÊ ËÏÎÆÅÅÎÃÉÉ ÎÅÄÁ×ÎÏ ÕÐÏÍÉÎÁÌÓÑ High Availability ËÌÁÓÔÅÒ ÎÁ Linux ÉÚ 
Ä×ÕÈ ÓÅÒ×ÅÒÏ×, ËÏÔÏÒÙÊ ÎÅ ÄÁÅÔ ÒÏÓÔÁ ÐÒÏÉÚ×ÏÄÉÔÅÌØÎÏÓÔÉ ÎÏ ÎÕÖÅÎ ÉÍÅÎÎÏ ÄÌÑ 
ÔÏÊ ÃÅÌÉ.
åÓÌÉ ÏÄÉÎ ÓÅÒ×ÅÒ ÚÁÄÙÍÉÔÓÑ ×ÔÏÒÏÊ ÏÓÔÁÎÅÔÓÑ × ÓÔÒÏÀ.


-- 
ó Õ×ÁÖÅÎÉÅÍ, íÅÝÅÒÑËÏ× ÷ÁÄÉÍ
ÄÉÒÅËÔÏÒ ïïï ëÏÍÐÌÅËÓÎÙÅ óÉÓÔÅÍÙ.

454021 Ç. þÅÌÑÂÉÎÓË ÕÌ. 40 ÌÅÔ ðÏÂÅÄÙ 31, 77
ôÅÌ: +7 (351) 2807917
Web: www.del-fin.ru

Re: ��������� �����

[Vladimir A.Bakhvaloff]

Hello, Sergey!
You wrote  on Wed, 23 May 2007 22:01:39 +0400:

 ??>> Не выход в моём случае - ночю и по выходным некому его заменить :)
 ST> Система 24х7 без дежурного администратора?! :))
 ST> Тоесть Ваш заказчик готов платить за резервные сервера, оптоволокно,
 ST> внешние массивы, Вашу работу по созданию системы восстановления от
 ST> сбоев с элементами искуственного интелекта... и не готов платить
 ST> $500/месяц студенту за сидение в офисе по выходным?? ну-ну :))

А что?.. Вот мне тут такая "халтурка" светит по соседству с домом... :)
Людям действительно стрёмно заплатить не то что $500, а $200-250 за один 
месяц отсутствия основного админа... А те же самые деньги за РАЗОВЫЙ визит 
сменщика - легко... %)

With best regards, Vladimir A.Bakhvaloff.  E-mail: [EMAIL PROTECTED]

Re: interbase.ibexpert.ru - ����?

[������� ����������]

Hello, Alexandr!
You wrote to Кузнецов Евгений on Mon, 21 May 2007 11:13:08 +0700:

 КЕ>> Subject - мне почему-то со среды не достучаться.
 КЕ>> Это у меня проблема?
 AK> жива, но она да, то потухнет, то погаснет.
 AK> Но иногда работает нормально.

Есть подозрение, что ip у них меняется частенько - сброс
кеша dns в последний раз помог.

--
-=Черепаховый суп - суп из черепа и чего-тот там еще.=-
With best regards,  Nikolay Ponomarenko

Re: ��������� �����

[Sergey Tulaev]

> îÅ ×ÙÈÏÄ × ÍÏ£Í ÓÌÕÞÁÅ - ÎÏÞÀ É ÐÏ ×ÙÈÏÄÎÙÍ ÎÅËÏÍÕ ÅÇÏ ÚÁÍÅÎÉÔØ :)
óÉÓÔÅÍÁ 24È7 ÂÅÚ ÄÅÖÕÒÎÏÇÏ ÁÄÍÉÎÉÓÔÒÁÔÏÒÁ?! :))
ôÏÅÓÔØ ÷ÁÛ ÚÁËÁÚÞÉË ÇÏÔÏ× ÐÌÁÔÉÔØ ÚÁ ÒÅÚÅÒ×ÎÙÅ ÓÅÒ×ÅÒÁ, ÏÐÔÏ×ÏÌÏËÎÏ, ×ÎÅÛÎÉÅ
ÍÁÓÓÉ×Ù, ÷ÁÛÕ ÒÁÂÏÔÕ ÐÏ ÓÏÚÄÁÎÉÀ ÓÉÓÔÅÍÙ ×ÏÓÓÔÁÎÏ×ÌÅÎÉÑ ÏÔ ÓÂÏÅ× Ó
ÜÌÅÍÅÎÔÁÍÉ ÉÓËÕÓÔ×ÅÎÎÏÇÏ ÉÎÔÅÌÅËÔÁ... É ÎÅ ÇÏÔÏ× ÐÌÁÔÉÔØ $500/ÍÅÓÑà ÓÔÕÄÅÎÔÕ
ÚÁ ÓÉÄÅÎÉÅ × ÏÆÉÓÅ ÐÏ ×ÙÈÏÄÎÙÍ?? ÎÕ-ÎÕ :))


--
Good luck!
Sergey Tulaev

Re: Резервныи сервер

[Janex]

Тоже думал на эту тему :)
Покупаем SATA салазки с горячей заменой для основного и резервного
серверов - 2x$10.
Покупаем шутрый винт, например WD Raptor 1rpm - $120.
Вставляем в основной сервер и делаем shadow базы на него.
В случае выхода из строя  - переносим Raptor на резервный сервер и запускаем
базу.
По идее операция должна занимать минут 5 от момента определения смерти
сервера.

Не выход в моём случае - ночю и по выходным некому его заменить :)
Ну вот такои вариант чему плох - соединяем оба сервяка оптикои, на 
главном шарим диск с резервного, както обманываем птицу чтоб

позволяла класть тень на шаре.

Или тож самое - оптика + шара и какоито софтwарныи однасторонныи "RAID" 
котории на шару делает копию бази ... если есть токие софти в природе

вообше ...

Regards
Janex

Re: ��������� �����

[Sergey Tulaev]

>
>  ST> ðÏ ÉÄÅÅ ÏÐÅÒÁÃÉÑ ÄÏÌÖÎÁ ÚÁÎÉÍÁÔØ ÍÉÎÕÔ 5 ÏÔ ÍÏÍÅÎÔÁ ÏÐÒÅÄÅÌÅÎÉÑ
ÓÍÅÒÔÉ
>  ST> ÓÅÒ×ÅÒÁ.
>
> ÅÓÌÉ ÓÅÒ×ÅÒ × ÐÒÅÄÓÍÅÒÔÎÏÍ ÕÇÁÒÅ ÎÅ ÚÁÐÏÒÉÔ ÂÁÚÕ ×ÍÅÓÔÅ Ó ËÏÐÉÅÊ.
> ÷ÅÒÏÑÔÎÏÓÔØ ÜÔÏ ÄÁÌÅËÏ ÎÅ ÎÕÌÅ×ÁÑ.
>
>
ôÁË ÍÙ ÇÏ×ÏÒÉÍ ÎÅ Ï ×ÅÒÏÑÔÎÏÓÔÑÈ, Á Ï ÂÙÓÔÒÏÍ ×ÏÓÓÔÁÎÏ×ÌÅÎÉÉ ÒÁÂÏÔÙ ÓÉÓÔÅÍÙ
ÐÒÉ ÓÂÏÅ. ôÁËÁÑ ÓÈÅÍÁ ÎÅ ÏÔÍÅÎÑÅÔ ÎÁÌÉÞÉÅ ÎÁ ÓÅÒ×ÅÒ RAID, Á ÔÁËÖÅ ÅÖÅÄÎÅ×ÎÙÈ
backup. ðÒÏÂÌÅÍÙ ÓÔÏÉÔ ÒÅÛÁÔØ ÐÏ ÍÅÒÅ ÉÈ ÐÏÓÔÕÐÌÅÎÉÑ:
1.÷ÙÛÅÌ ÉÚ ÓÔÒÏÑ ×ÉÎÔ - ÅÓÔØ RAID, ×ÒÅÍÑ ÐÒÏÓÔÏÑ 0.
2.óÇÏÒÅÌ ÐÒÏÃ\ÍÁÔÅÒÉÎËÁ\âð ÓÅÒ×ÅÒÁ - ÐÅÒÅÓÔÁ×ÉÌÉ ×ÉÎÔ Ó sadow ÎÁ ÒÅÚÅÒ×ÎÙÊ
ÓÅÒ×ÅÒ, ×ÒÅÍÑ ÐÒÏÓÔÏÑ 5-10ÍÉÎ.
3.óÅÒ×ÅÒ(ÉÌÉ ÍÏÅ ðï ;) ÚÁÐÏÒÏÌÏ ÂÁÚÕ - ÅÓÔØ ÂÜËÁÐ, ×ÒÅÍÑ ÐÒÏÓÔÏÑ ÏÔ 30 ÍÉÎ.
É Ô Ð


--
Good luck!
Sergey Tulaev

Re: Резервныи сервер

[Alexandr Kochmin]

ST> По идее операция должна занимать минут 5 от момента определения смерти
ST> сервера.

если сервер в предсмертном угаре не запорит базу вместе с копией.
Вероятность это далеко не нулевая.

--
С уважением
Кочмин Александр
Firebird Foundation associate member #257 

Re: ��������� �����

[Sergey Tulaev]

> îÕ Á ×ÏÔ ÚÒÑ ÎÅÓÄÅÌÁÌÉ, ÞÔÏ ÔÅÎß ÍÏÖÅÔ ÎÁ ÛÁÒÅÎÏÍ ÄÉÓËÅ ÌÅÖÁÔØ :(
> çÉÇÁÂÉÔÎÉÅ ËÁÒÔÉ ÓÔÁ×ÉÍ É ÂÁÚÁ ÐÁÒÁÌÅÌØÎÏ ÎÁ Ä×ÕÈ ÖÅÌÅÚÁÈ ÌÅÖÉÔ, ÉÌÉ
> ÞÔÏÔÏ ÐÏÄÏÂÎÏÅ ... ÉÌÉ ËÁËÔÏ ÍÕÄÒÏ ÏÂÍÁÎÉÔØ ÐÔÉÃÕ ÞÔÏ ÐÏ×ÅÒÉÌÁ ÞÔÏ
> ÛÁÒÁ ÅÔÏ ÍÅÓÔÎÏÅ ÖÅÌÅÚÏ :) :) :)
>
ôÏÖÅ ÄÕÍÁÌ ÎÁ ÜÔÕ ÔÅÍÕ :)
ðÏËÕÐÁÅÍ SATA ÓÁÌÁÚËÉ Ó ÇÏÒÑÞÅÊ ÚÁÍÅÎÏÊ ÄÌÑ ÏÓÎÏ×ÎÏÇÏ É ÒÅÚÅÒ×ÎÏÇÏ
ÓÅÒ×ÅÒÏ× - 2x$10.
ðÏËÕÐÁÅÍ ÛÕÔÒÙÊ ×ÉÎÔ, ÎÁÐÒÉÍÅÒ WD Raptor 1rpm - $120.
÷ÓÔÁ×ÌÑÅÍ × ÏÓÎÏ×ÎÏÊ ÓÅÒ×ÅÒ É ÄÅÌÁÅÍ shadow ÂÁÚÙ ÎÁ ÎÅÇÏ.
÷ ÓÌÕÞÁÅ ×ÙÈÏÄÁ ÉÚ ÓÔÒÏÑ  - ÐÅÒÅÎÏÓÉÍ Raptor ÎÁ ÒÅÚÅÒ×ÎÙÊ ÓÅÒ×ÅÒ É ÚÁÐÕÓËÁÅÍ
ÂÁÚÕ.
ðÏ ÉÄÅÅ ÏÐÅÒÁÃÉÑ ÄÏÌÖÎÁ ÚÁÎÉÍÁÔØ ÍÉÎÕÔ 5 ÏÔ ÍÏÍÅÎÔÁ ÏÐÒÅÄÅÌÅÎÉÑ ÓÍÅÒÔÉ
ÓÅÒ×ÅÒÁ.


--
Good luck!
Sergey Tulaev

Re: глючок

[Alexandr Kochmin]

AK> Все бы ничего, но мож лучше сразу послать, а не заставлять думать о
AK> смысле жизни. ;)

попробовал еще раз сейчас.
Хм... пишет ошибку.
Что это было? Вопрос риторический.

--
С уважением
Кочмин Александр
Firebird Foundation associate member #257 

Re: посоветуйте самую умную книжку по проектированию РБД

[Dmitri Kuzmenko]

Hello, Алексей!

Кравченко Алексей wrote:


плз, очень хочу прочитать умную книжку где со всех сторон описано как нужно
строить разнообразные сложные (в т.ч. рил-тайм) БД.


это вряд ли.


подробнее о способах репликации, резервирования и вообще как строить базы с
надежностью стемящейся к 100%, в идеале безотносительно к какойлибо СУБД,
где понемножку обо всех


ну у тебя и запросы.


желательно на русском языке и доступную для скачивания.
бумажные книжки часто неоправдывают вложенных 2000р


вот тут точно обломись.

--
Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34

Re: Резервныи сервер

[Dmitri Kuzmenko]

Hello, Alexandr!

Alexandr Kochmin wrote:


OL> Там уже и так всё сделано для работы с двухфазными вещами :-)

хм. но не прозрачно. А вроде как можно доделать до прозрачности


imho в IB/FB двухфазный коммит и так прозрачнее некуда.
сравни с чем угодно, прозрачнее не будет.

--
Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34

глючок

[Alexandr Kochmin]

fb2
делал через сервисы (ibexpert) рестор на линуксовый комп
а путь где брать бэкап указал не тот, а свой, с того компа где запускаю.
Ну как для обычного gbak.
И рестор не выругался, а тихонечно сказал
"начали бэкап" а через секунду
"закончили бэкап успешно"

Задумался. На всякий случай проверил - нет, база не создалась.
Подумал еще. Еще пару раз попробовал. Думаю мистика какая-то.
Потом понял в чем дело :)
Все бы ничего, но мож лучше сразу послать, а не заставлять думать о смысле 
жизни. ;)

--
С уважением
Кочмин Александр
Firebird Foundation associate member #257 

Re[2]: Резервныи сервер

[Sergey Mereutsa]

Привет!

> А как там дела с етими масивами дисков ? Соовсем не специалисть в етои
> области, но можбить возможно сделать систему из двух сервяков с кокими
> то обшими дисками ... или я несу тут полную чуш :) ?

Можно, не чушь. Сам такую хрень видел на терабайт. Стоит от 150К
зелени, два сервака подрубаются к ней по оптике. Шустро. Но для
банков. Но шустро. :)


-- 
Best regards,
 Sergeymailto:[EMAIL PROTECTED]

Re: Резервныи сервер

[Roman Rokytskyy]

хм. но не прозрачно. А вроде как можно доделать до прозрачности


что-то мне все-таки не понятно почему оно должно работать в общем случае...

ведь, если не ошибаюсь, гарантировано оно работает только в случае, если 
поведение обоих серверов одинаковое для _каждого_ запроса который 
приходит на сервер (независимо от последовательности исполнения 
различных запросов). В случае одного приложения оно, конечно, 
тривиально. А в случае двух приложений с concurrency или read committed 
изоляцией распределенный deadlock или livelock очень даже возможен. 
Возможно, что через timeout обе транзакции получат отлуп - здесь надо 
аккуратно проанализировать, где и когда оно случится.


В случае no wait транзакций мне кажется что вполне даже возможно, что на 
одном сервере операция пройдет успешно, на другом - получит отлуп. Что 
тогда возвращать клиенту? Ошибку? А как откатить изменения в той базе, 
где запрос отработал?


То-есть нутром чуствую, что класс задач, где такое работает, довольно 
узкий и надо четко указать ограничения, когда оно будет корректно 
работать... Может я не прав, тогда аргументируйте...


Роман

Re: Резервныи сервер

[Alexandr Kochmin]

OL> "Alexandr Kochmin" <[EMAIL PROTECTED]>
OL> wrote in message news:[EMAIL PROTECTED]
OL>> а, хм. а можно же и в fbclient такое сделать вроде, да?
OL>> А так то да, наверное. Но надо немножко опыта чтоб знать что где там
OL>> искать.
OL>
OL> Там уже и так всё сделано для работы с двухфазными вещами :-)

хм. но не прозрачно. А вроде как можно доделать до прозрачности

--
С уважением
Кочмин Александр
Firebird Foundation associate member #257 

Re: Резервныи сервер

[Janex]

Alexandr Kochmin wrote:


J> Тогда делаем как можно чаше бекап и кладём
J> на другои сервер и там автоматически ресторим.

Да, примерно так и надо. Но бэкап будет несколько тормозить рабочий 
сервер. да и опять же малая часть данных может потерятсья - та что между 
бэкапами получилась.
Ну если 4 ядра у проца и классик, так вроде можно бекап на одно ядро 
посадить, а юзверов на остальные, или ошибаюс ?


Ну а вот зря несделали, что тенъ может на шареном диске лежать :( 
Гигабитние карти ставим и база паралельно на двух железах лежит, или 
чтото подобное ... или както мудро обманить птицу чтоб поверила что

шара ето местное железо :) :) :)

Если бы так можно было, то как один сервяк упал - идём к другому, 
подкоректироваем что надо и работаем до понедельника ...
А как там дела с етими масивами дисков ? Соовсем не специалисть в етои 
области, но можбить возможно сделать систему из двух сервяков с кокими 
то обшими дисками ... или я несу тут полную чуш :) ?


Regards
Janex

Re: Домены в параметрах поцедур

[Alexandr Kochmin]

s> Что ему передать?
s>

передай ему большое спасибо за то что починил русские буквы в SP и прочее 
связанное с блобами в fb2.1
а по теме, ссылку ему передай на эту ветку, как я. Он сам почитает.

--
С уважением
Кочмин Александр
Firebird Foundation associate member #257 

Re: Резервныи сервер

[Alexandr Kochmin]

AC> Как после "временного" сбоя на одном из серверов,
AC> задачи _других_ юзеров смогут определить,
AC> какой из них содержит валидные данные?

так вроде речь шла про синее пламя.
Я думаю визуально определят. ;)


--
С уважением
Кочмин Александр
Firebird Foundation associate member #257 

Re: Резервныи сервер

[Alexandr Kochmin]

OL> "Alexandr Kochmin" <[EMAIL PROTECTED]>
OL> wrote in message news:[EMAIL PROTECTED]
OL>>
OL>> Вот бы кто еще этот небольшой кусок низкоуровневого кода переписал для
OL>> прозрачной имплементации сей возможности.  ;)
OL>
OL> Вообще-то ничего сложного. Я такое ради эксперемента делал за один
OL> вечер, подопытный  - IBX.

а, хм. а можно же и в fbclient такое сделать вроде, да?
А так то да, наверное. Но надо немножко опыта чтоб знать что где там искать.

--
С уважением
Кочмин Александр
Firebird Foundation associate member #257 

Re: Резервныи сервер

[Oleg LOA]

"Alexandr Kochmin" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]
> 
> Вот бы кто еще этот небольшой кусок низкоуровневого кода переписал для 
> прозрачной имплементации сей возможности.  ;)

Вообще-то ничего сложного. Я такое ради эксперемента делал за один вечер, 
подопытный  - IBX.

Re: Резервныи сервер

[Alex Cherednichenko]

Привет, Oleg!
Вы пишешь  23 мая 2007:

 OL> Если это какое-то готовое ПО, то как вариант, именно как вариант возможна 
правка библиотек доступа к серверу на предмет
 OL> параллельной работы с двумя серверами одновременно и автоматическом 
переключении на оставший 
 OL> сервер с случае сбоя работы с одним из серверов.  Плюс такого подхода в 
том что правится небольшой кусок низкоуровневого кода. 
 OL> Минусы - все минусы двухфазных транзакций, плюс потеря данных в транзакции 
на момент которой произшёл сбой в одном из серверов.

Как после "временного" сбоя на одном из серверов,
задачи _других_ юзеров смогут определить, 
какой из них содержит валидные данные?
Что делать с сервером после такого сбоя? Даунить?

Вопрос, конечно, праздный - наворотить можно
несколько вариантов решения, но откровенно говоря, 
ну его нах такие заботы...  ;о)

-- 
With best regards, Alex Cherednichenko.

Re: Резервныи сервер

[Alexandr Kochmin]

OL> Если это какое-то готовое ПО, то как вариант, именно как вариант
OL> возможна правка библиотек доступа к серверу на предмет параллельной
OL> работы с двумя серверами одновременно и автоматическом переключении на
OL> оставший сервер с случае сбоя работы с одним из серверов.  Плюс такого
OL> подхода в том что правится небольшой кусок низкоуровневого кода. Минусы
OL> - все минусы двухфазных транзакций, плюс потеря данных в транзакции на
OL> момент которой произшёл сбой в одном из серверов.

Да, идея хорошая. особенно если сделать еще балансировку нагрузки.
Чтоб селекты (read транзакции) между серверами распределять.
Выглядит как дешевое решение с большими возможностями.

Вот бы кто еще этот небольшой кусок низкоуровневого кода переписал для 
прозрачной имплементации сей возможности.  ;)


--
С уважением
Кочмин Александр
Firebird Foundation associate member #257 

Re: Резервныи сервер

[Roman Rokytskyy]

Можбить в природе есть ешё какието хитрие решения ?


Если при слове Java тебе не бросает в дрожь и ты не хватаешся за 
осиновый кол, то можешь посмотреть на Sequoia 
(http://sequoia.continuent.org/) - это довольно старый проект, при чем у 
них имеются ODBC-драйвер и возможность работы через C++ API.


Роман

����������� ����� ����� ������ �� ��������������

[��������� ������]

ÐÌÚ, ÏÞÅÎØ ÈÏÞÕ ÐÒÏÞÉÔÁÔØ ÕÍÎÕÀ ËÎÉÖËÕ ÇÄÅ ÓÏ ×ÓÅÈ ÓÔÏÒÏÎ ÏÐÉÓÁÎÏ ËÁË ÎÕÖÎÏ
ÓÔÒÏÉÔØ ÒÁÚÎÏÏÂÒÁÚÎÙÅ ÓÌÏÖÎÙÅ (× Ô.Þ. ÒÉÌ-ÔÁÊÍ) âä.
ÐÏÄÒÏÂÎÅÅ Ï ÓÐÏÓÏÂÁÈ ÒÅÐÌÉËÁÃÉÉ, ÒÅÚÅÒ×ÉÒÏ×ÁÎÉÑ É ×ÏÏÂÝÅ ËÁË ÓÔÒÏÉÔØ ÂÁÚÙ Ó
ÎÁÄÅÖÎÏÓÔØÀ ÓÔÅÍÑÝÅÊÓÑ Ë 100%, × ÉÄÅÁÌÅ ÂÅÚÏÔÎÏÓÉÔÅÌØÎÏ Ë ËÁËÏÊÌÉÂÏ óõâä,
ÇÄÅ ÐÏÎÅÍÎÏÖËÕ ÏÂÏ ×ÓÅÈ

ÖÅÌÁÔÅÌØÎÏ ÎÁ ÒÕÓÓËÏÍ ÑÚÙËÅ É ÄÏÓÔÕÐÎÕÀ ÄÌÑ ÓËÁÞÉ×ÁÎÉÑ.
ÂÕÍÁÖÎÙÅ ËÎÉÖËÉ ÞÁÓÔÏ ÎÅÏÐÒÁ×ÄÙ×ÁÀÔ ×ÌÏÖÅÎÎÙÈ 2000Ò

Re: Резервныи сервер

[Alexandr Kochmin]

J> Тогда делаем как можно чаше бекап и кладём
J> на другои сервер и там автоматически ресторим.

Да, примерно так и надо. Но бэкап будет несколько тормозить рабочий сервер. да 
и опять же малая часть данных может потерятсья - та что между бэкапами 
получилась.
Другое решение - однонаправленная репликация на второй сервер. Это лучше, но 
тему надо думать. Хотя такая репликация это простейшая.

--
С уважением
Кочмин Александр
Firebird Foundation associate member #257 

Резервныи сервер

[Janex]

Привет алл.
Пока небыло нужды незамечал - обсуждалось ли такое гдет по близости или 
нет, если да то киньте ссылку плиз ...
Садача следуюшая - заказшик хочет гарантии на 100% что база будет 
доступна на все 24/7 даже если сервер натурально сгорит синем пламенем :)
Решение вроде такое - держать (не рядом а подальше, чтоб oгонь 
неперекинулась :)) второи сервер и если первии сгорит, то юзери

переключаются на второи. Тогда делаем как можно чаше бекап и кладём
на другои сервер и там автоматически ресторим.
Можбить в природе есть ешё какието хитрие решения ?

Пока на Yaffil-e сидим...

Regards
Janex

Re: IBAnalyst так мелочи

[Sergiy S. Tkachenko]

Dmitri Kuzmenko пишет:

IBAnalyst 2.0 - 3000 руб.
IBAnalyst 1.95 - бесплатный, все там же, на forum.ibase.ru ссылка.


спасибо, понял.

Re: IBAnalyst так мелочи

[Dmitri Kuzmenko]

Hello, Sergey!

Sergiy S. Tkachenko wrote:


Дайта, пожалуйста, прямую ссылку на новый IBAnalyst,
а то версия из ibanalyst2_ru.zip говорит, что уже есть новая версия,
и ничего не показывает.


IBAnalyst 2.0 - 3000 руб.
IBAnalyst 1.95 - бесплатный, все там же, на forum.ibase.ru ссылка.

--
Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34

Re: прочитал тут ветку про VLDB... reload

[Dmitri Kuzmenko]

Hello, Алексей!

Кравченко Алексей wrote:


суть в самой проблеме отсутствия online-механизмов


их не может быть. ты вот предложил "не менять базу"
на время "ремонта". А откуда ты будешь ЧИТАТЬ поврежденные
страницы или структуры данных?


вот вы все ссылаетесь на быстро-доступный ближайший бэкап...
но понимаете, в некоторых случаях бэкап даже пятиминутной давности - УЖЕ
слишком устаревший.


тогда из приложений сохраняй логи работы вместе с записью в БД,
и в случае сбоя БД и восстановления из бэкапа (или нбэкапа) накатывай
эти логи.


основная причина - ПОСЛЕДОВАТЕЛЬНОСТЬ логических событий в базе.
нарушится причинно-следственная связь. (смотрели наверно фильм "назад в
будущее")


см. выше. ты сам строишь в базе эти последовательные действия,
значит сам и должен их обрабатывать при сбоях. Серверу похрен,
вставил ты запись из процедуры, триггера или явно.


а вот еслибы мы быстренько могли накатить последние изменения на последний
бэкап...было бы все замечательно...


накатывай. кто тебе не дает?


а существующий nbackup - физический (тоесть все оригинальные косяки
перенесутся).


??? как записал, так и перенесется.

--
Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34

Re: IBAnalyst так мелочи

[Sergiy S. Tkachenko]

Дайта, пожалуйста, прямую ссылку на новый IBAnalyst,
а то версия из ibanalyst2_ru.zip говорит, что уже есть новая версия,
и ничего не показывает.

Re: Текстовая индексация

[Roman Rokytskyy]

Интересно как этот intersect будет работать с множествами c сотнями
тысяч записей. Формально, конечно, побыстрее чем join записей.


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



Но мне хочется отказаться от пересечений в принципе.


Тогда смотри в сторону GiST - это так называемые "signature 
files"-алгоритмы. Для каждого документа считается битовая маска 
определенной длины. Такая же маска считается для запроса. Дальше - 
бинарные операции с последующим просмотром каждого документа для 
фильтрации false positived.


В общем случае быстродействие этих алгоритмов хуже чем для inverted 
files (твой вариант), но читай также инфо от PgSQL - они утверждают, что 
GiST лучше для часто-обновляемых баз.


Роман

Re: Текстовая индексация

[Kovalenko Dmitry]

> То-есть, если говорить грубо, то это было бы что-то такое на нормальном SQL
>
>SELECT intersect(i.doc_ids)
>FROM my_index_table i
>WHERE i.word IN (...)
>
> где intersect(): - аггрегатная ф-ция, которая для каждого
> передаваемого ей списка считает пересечение этого списка с уже
> аггрегированым результатом.

Ясно. Спасибо. Мой джоин завернутый внутрь intersect

Интересно как этот intersect будет работать с множествами c сотнями
тысяч записей. Формально, конечно, побыстрее чем join записей.

Но мне хочется отказаться от пересечений в принципе.

Коваленко Дмитрий.

Re: Текстовая индексация

[Roman Rokytskyy]

Если у объекта 10 уникальных лексем, у меня добавиться десять записей.

Судя по описанию GIN - у них тоже.


Если я правильно понимаю - нет. Смотри сюда:

http://archives.postgresql.org/pgsql-hackers/2006-04/msg00960.php

"Gin is consists of a B-tree constructed over entries (ET, entries 
tree), where entry is an element of indexed value ( element of array, 
lexeme for tsvector) and where each tuple in the leaf pages is either 
pointer to B-tree over item pointers (PT, posting tree), or list of item 
pointers (PL, posting list) if tuple is small enough."


и дальше по тексту "There is no delete operation for ET. The reason for 
this, is that from our experience, a set of unique words of a whole 
collection changed very rare."


При добавлении 10 новых документов изменяется только конкретный "листик" 
из бинарного дерева, но ничего не добавляется (если только это не новая 
лексема в словаре).


То-есть, если говорить грубо, то это было бы что-то такое на нормальном SQL

  SELECT intersect(i.doc_ids)
  FROM my_index_table i
  WHERE i.word IN (...)

где intersect(): - аггрегатная ф-ция, которая для каждого 
передаваемого ей списка считает пересечение этого списка с уже 
аггрегированым результатом.


Мы могли бы использовать intersect(blob):blob, если договорится, что в 
блобах хранятся, например, 64-битные идентификаторы. Но у нас нет 
аггрегатных UDF...



Теперь мне нужно выбрать объекты у которых есть 3 лексемы.


При подходе описаном выше достаточно одного прохода по индексу.

Я, кстати, такое делал для spatial-индекса. Листья дерева хранил в 
блобах (ID документов), пересечение делал на клиенте (предварительно 
отобрав на сервере все подходящие листья). В приложении поиск шел 
одновременно по моему spatial-индексу, полнотекстовому индексу на lucene 
и резалт-сету обычного поиска в базе по другим полям. Работало хорошо, 
но у меня были (если правильно помню) только где-то 100-200 тыс записей 
- инфо о кафешках, ресторанах, и др. организация с текстом (меню, 
например), геогр. координатами, и прочей инфо.


Роман

Re: Текстовая индексация

[Kovalenko Dmitry]

> > Неужто в PG так здорово работают join-ы на больших объемах? Если
> > судить по восторгам о том как там все здорово сделано?
>
> Да, еще (в догонку к первому посту, которого почему-то не видно): не
> знаю как GIN делает, но Lucene еще хранит информацию о частоте
> использования лексемы. Таким образом можно на начальном этапе поиска
> использовать только те лексемы, которые не слишком часто встречаются и
> являются наиболее релевантными для поиска.

Частота у меня тоже есть. И статистика по общему числу использования
лексемы - тоже. Это пересчитывается каждую ночь и юзается для
построения наиболее легковестного запроса.

Суть моего вопроса не в этом. Вот у меня есть индексная таблица с
записями

 

В PG (у GIN-а) тоже такое есть.

Если у объекта 10 уникальных лексем, у меня добавиться десять записей.

Судя по описанию GIN - у них тоже.

Теперь мне нужно выбрать объекты у которых есть 3 лексемы.

Я делаю пересение трех выборок по  из индексной таблицы
для первой, второй и третьей лексемы. То есть два джоина.

На 15 лимонах записей - ощутимые тормоза. Индексы для этого запроса с
двумя join-ами юзаются путевые. Значит тормоза - из самого факта
существования джоина.

А как в PG как это делается? То есть как махом выбрать объекты у
которых мои три лексемы?
Что конкретно представляет из себя их чудо индекс для точного
полнотекстового поиска?

Коваленко Дмитрий.

Re: Текстовая индексация

[Dmitry Yemanov]

WildSery wrote:


В FB1.0.3 работает.


Сорри, я попутал. В таком виде оно действительно всегда работало. Не 
работает IN с подзапросом.



--
Дмитрий Еманов

Re: Текстовая индексация

[Roman Rokytskyy]

Неужто в PG так здорово работают join-ы на больших объемах? Если
судить по восторгам о том как там все здорово сделано?


Да, еще (в догонку к первому посту, которого почему-то не видно): не 
знаю как GIN делает, но Lucene еще хранит информацию о частоте 
использования лексемы. Таким образом можно на начальном этапе поиска 
использовать только те лексемы, которые не слишком часто встречаются и 
являются наиболее релевантными для поиска.


Роман

Re: CVS.SF.NET

[Vladimir A.Bakhvaloff]

 ??>> Ïðîáóé firebird.cvs.sourceforge.net - óæå ãäå-òî ãîä êàê òàì
 ??>> èçìåíèëîñü:
 Makmak> Íó âîò ÿ ââåë â çàáëóæäåíèå, íåäîñìîòðåë
 Makmak> äåéñòâèòåëüíî ó ìåíÿ ñòîèò firebird.cvs.sourceforge.net

Ãëàâíîå, òåïåðü ìû çíàåì â ÷¸ì ïðàâäà, áðàò!.. ;)))

---
E-mail: bobbakhspbru ICQ: 12861767 (1608235)
np: Kraftwerk - Trans-Europe Express (from "Trans-Europe Express" - 1977) 

Re: Текстовая индексация

[Roman Rokytskyy]

Получается, что комбинации лексем (в целях оптимизации поиска) они не
хранят.

Поэтому чтобы получить данные, в которые входят несколько лексем,
нужно построить пересечение.

Неужто в PG так здорово работают join-ы на больших объемах? Если
судить по восторгам о том как там все здорово сделано?


А кто тебе сказал, что join идет по таблице с данными?

Ты в своей реализации этим ограничен, поскольку у тебя присутствуют 
только возможности DSQL.


Ни Lucene, ни, если я правильно понял, PgSQL FTS не ограничены этим - 
отбор кандидатов идет по индексу - идет оценка всего полнотекстового 
запроса, а не его отдельных термов с последующим джойном "отсеяных" 
резалтсетов с реальными даными. В PgSQL для GiST индекса нужна еще 
последующая фильтрация, для GIN оно должно работать сразу.


Скажу еще - для того чтоб сделать поддержку запросов типа "wordA NEAR 
wordB MAX_DISTANCE 10", то на обычном SQL придется очень сильно 
извращатся. Да и для обычных "wordA AND wordB AND wordC" количество 
джойнов растет пропорционально (количество записей для проверки - 
экспоненциально).


Как workaround ты как раз и пробуешь в словарь добавить целые фразы... 
Другие строят свой "индекс" в котором идет оценка всего запроса и 
возвращаются только подходящие результаты. При чем, если реализация 
нормальная, то автоматически считается score для проиндексированого 
документа и hits возвращаются в убывающем порядке.


Роман

Re: CVS.SF.NET

[Makmak]

Пробуй firebird.cvs.sourceforge.net - уже где-то год как там изменилось:


Ну вот я ввел в заблуждение, недосмотрел
действительно у меня стоит firebird.cvs.sourceforge.net
Не хотел я, нехотел.

Макмак 

Re: CVS.SF.NET

[Vladimir A.Bakhvaloff]

 Roman>> Ïðîáóé firebird.cvs.sourceforge.net - óæå ãäå-òî ãîä êàê òàì
 Roman>> èçìåíèëîñü:
 Vladimir> Òàì áû òîãî...
 Vladimir> "Çàíåñëè á ñåáå íà êîìïüþòåðîíå" /Ç.Òåíåíáîéì/ ;)
/Êîìïüþòåðíîå, åñòåñòâåííî/

À íà http://sourceforge.net/cvs/?group_id=9028 ïðàâèëüíî íàïèñàíî...
À âîò íà http://www.firebirdsql.org/index.php?op=devel&id=cvs_howto 
(îòêóäà ÿ ñîáñòâåííî è ñòûðèë ñòðî÷êè :)) - óñòàðåëëîå... :(

---
E-mail: bobbakhspbru ICQ: 12861767 (1608235)
np: none 

Re: исправили перекодировку BLOB?

[Андрій Жук]

function TUIBLibrary.BlobGetSegment(var BlobHandle: IscBlobHandle; out 
length: Word;

BufferLength: Cardinal; Buffer: PChar): boolean;
  var
AStatus: ISCStatus;
  begin
if BufferLength > High(Word) then
  BufferLength := High(Word);
  {$IFDEF UIBTHREADSAFE}
FLIBCritSec.Enter;
try
  {$ENDIF}
  AStatus := isc_get_segment(@FStatusVector, @BlobHandle, @length, 
Word(BufferLength), Buffer);

  {$IFDEF UIBTHREADSAFE}
finally
  FLIBCritSec.Leave;
end;
  {$ENDIF}
Result := (AStatus = 0) or (FStatusVector[1] = isc_segment);
if not Result then
  if (FStatusVector[1] <> isc_segstr_eof) then
CheckUIBApiCall(AStatus);
  end;

тут проверяют...

Re: прочитал тут ветку про VLDB... reload

[Yurij]

On 23 май, 11:29, "Кравченко Алексей" <[EMAIL PROTECTED]> wrote:
> понятное дело раскритиковали

> происходит событие D.
> но поскольку в этот момент в базе нет последствий событий A,B,C, то событие
> D либо не сможет состояться, либо его результат будет неверным. и
> последующее вливание изменений будут уже не кстати. позно. поезд ушел.
> получаем нарушение в технологии.

Неустойчивый алгоритм. С такими постановками задач можно просто
повеситься без всяких VLDB и сбоев. Просто через месяц пользователи
скажут "событие B было ошибочным, надо исправлять" и пойдет
нарастающая цепочка изменений, из которых половина противоречит
реальным фактам. Стандартный пример - складской учет - отпустили товар
из одной партии, записали другую, похожую. Через месяц обнаружили, но
исправить уже нельзя, обе партии ушли, а на учете висит +товаров по
одной партии и - по другой, бухгалтера вешаются :)

Re: прочитал тут ветку про VLDB... reload

[Yurij]

On 23 май, 11:29, "Кравченко Алексей" <[EMAIL PROTECTED]> wrote:
> понятное дело раскритиковали

> происходит событие D.
> но поскольку в этот момент в базе нет последствий событий A,B,C, то событие
> D либо не сможет состояться, либо его результат будет неверным. и
> последующее вливание изменений будут уже не кстати. позно. поезд ушел.
> получаем нарушение в технологии.

Неустойчивый алгоритм. С такими постановками задач можно просто
повеситься без всяких VLDB и сбоев. Просто через месяц пользователи
скажут "событие B было ошибочным, надо исправлять" и пойдет
нарастающая цепочка изменений, из которых половина противоречит
реальным фактам. Стандартный пример - складской учет - отпустили товар
из одной партии, записали другую, похожую. Через месяц обнаружили, но
исправить уже нельзя, обе партии ушли, а на учете висит +товаров по
одной партии и - по другой, бухгалтера вешаются :)

Re: Текстовая индексация

[Kovalenko Dmitry]

> Кстати, те, кто был в Праге в прошлом году, могли наблюдать интеграцию
> Lucene и Fyracle на моей презентации по Java Stored Procedures. Это
> конечно был только пример (где-то 200 строчек кода, может меньше), но
> вполне рабочий. Идея работы там такая же как и в PostgreSQL FTS от
> которой Дима Кузьменко тащится.

Почитал вот этот документ
http://www.sai.msu.su/~megera/postgres/talks/fts_pgsql_intro.html

В частности интересовала структура индекса GIN
http://www.sai.msu.su/~megera/postgres/talks/fts_pgsql_intro.html#ftsindex

Получается, что комбинации лексем (в целях оптимизации поиска) они не
хранят.

Поэтому чтобы получить данные, в которые входят несколько лексем,
нужно построить пересечение.

Неужто в PG так здорово работают join-ы на больших объемах? Если
судить по восторгам о том как там все здорово сделано?

Коваленко Дмитрий.

Re: CVS.SF.NET

[Vladimir A.Bakhvaloff]

 Roman> Ïðîáóé firebird.cvs.sourceforge.net - óæå ãäå-òî ãîä êàê òàì
 Roman> èçìåíèëîñü:

Î!.. Êàíàåò!.. :)
Ñåíüêñ!..
...
Òàì áû òîãî...
"Çàíåñëè á ñåáå íà êîìïüþòåðîíå" /Ç.Òåíåíáîéì/ ;)

---
E-mail: bobbakhspbru ICQ: 12861767 (1608235)
np: none 

Re: CVS.SF.NET

[Roman Rokytskyy]

 Makmak> все нормально.
 Makmak> Специально вот сейчас запустил. Пашет!

Блин, ну даже ж не коннектится!.. А cvs - работает, вижу по 
веб-интерфейсу...

И теперь начало по-другому ныть:
===
connect to cvs.sourceforge.net:2401 failed: Сделана попытка выполнить 
операцию на сокете для недоступного хоста.


Пробуй firebird.cvs.sourceforge.net - уже где-то год как там изменилось:

[EMAIL PROTECTED]:~$ cvs -d 
:pserver:anonymouscvs.sourceforge.net:/cvsroot/firebird login
Logging in to 
:pserver:anonymouscvs.sourceforge.net:2401/cvsroot/firebird

CVS password:
cvs [login aborted]: connect to cvs.sourceforge.net(66.35.250.207):2401 
failed: No route to host


[EMAIL PROTECTED]:~$ cvs -d 
:pserver:anonymousfirebird.cvs.sourceforge.net:/cvsroot/firebird login
Logging in to 
:pserver:anonymousfirebird.cvs.sourceforge.net:2401/cvsroot/firebird

CVS password:
[EMAIL PROTECTED]:~$

Re: прочитал тут ветку про VLDB... reload

[Kovalenko Dmitry]

> Дело в том, что стоимость и надежность системы определяется стоимостью
> данных. И всегда (по-моему скромному мнению) надо иметь документ,
> который описывает, что делать, если эта супер-пупер система загнется.

В этом документе будет только один осмысленный пункт - "Срочно валить,
пока не огребли!"

Коваленко Дмитрий.

Re: CVS.SF.NET

[Vladimir A.Bakhvaloff]

 Makmak> îÅ ÓÐÅÃ, ÎÏ Õ ÍÅÎÑ ÔÏÌØËÏ ÏÄÎÁ ÓÔÒÏËÁ É × ÎÅÊ z9, Á ÎÅ z3

îÕ, ÜÔÏ ÍÅÌÏÞÉ... üÔÏ ÐÒÏÓÔÏ ÓÖÁÔÉÅ ÐÏÔÏËÁ...

 Makmak> ×ÓÅ ÎÏÒÍÁÌØÎÏ.
 Makmak> óÐÅÃÉÁÌØÎÏ ×ÏÔ ÓÅÊÞÁÓ ÚÁÐÕÓÔÉÌ. ðÁÛÅÔ!

âÌÉÎ, ÎÕ ÄÁÖÅ Ö ÎÅ ËÏÎÎÅËÔÉÔÓÑ!.. á cvs - ÒÁÂÏÔÁÅÔ, ×ÉÖÕ ÐÏ 
×ÅÂ-ÉÎÔÅÒÆÅÊÓÕ...
é ÔÅÐÅÒØ ÎÁÞÁÌÏ ÐÏ-ÄÒÕÇÏÍÕ ÎÙÔØ:
===
connect to cvs.sourceforge.net:2401 failed: óÄÅÌÁÎÁ ÐÏÐÙÔËÁ ×ÙÐÏÌÎÉÔØ 
ÏÐÅÒÁÃÉÀ ÎÁ ÓÏËÅÔÅ ÄÌÑ ÎÅÄÏÓÔÕÐÎÏÇÏ ÈÏÓÔÁ.
===
ðÏÐÒÏÂÏ×ÁÌ ÔÅÌÎÅÔÏÍ ÚÁÊÔÉÔØ... 10065 ×ÏÚ×ÒÁÝÁÅÔ... äÁÖÅ ÎÅ ÚÎÁÀ, ÞÔÏ ÜÔÏ 
ÚÁ ÏÛÉÂËÁ-ÔÏ... :)))

---
E-mail: bobbakhspbru ICQ: 12861767 (1608235)
np: none 

Re: CVS.SF.NET

[Makmak]

   Скажите, а это только я на попытки получить этим бантиком:
===
cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/firebird 
login
cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot/firebird 
co firebird2

===

Не спец, но у меня только одна строка и в ней z9, а не z3
все нормально.
Специально вот сейчас запустил. Пашет!

Удачи!
Макмак 

Re: прочитал тут ветку про VLDB... reload

[Kovalenko Dmitry]

> но понимаете, в некоторых случаях бэкап даже пятиминутной давности - УЖЕ
> слишком устаревший.
> его нельзя подложить вместо рабочей базы в работу, а только потом влить
> изменения.
> основная причина - ПОСЛЕДОВАТЕЛЬНОСТЬ логических событий в базе.
> нарушится причинно-следственная связь. (смотрели наверно фильм "назад в
> будущее")

Неверное восприятие мира.

Для того что бы восстановить данные не нужно знать последовательность
их появления.

Нужно знать порядок их восстановления, для того чтобы не нарушить
ссылочную целостность базы. И этот порядок может децел отличаться от
ПОСЛЕДОВАТЕЛЬНОСТИ.

Коваленко Дмитрий.

Re: прочитал тут ветку про VLDB... reload

[Alexandr Kochmin]

W>
W> On Wed, 23 May 2007 12:36:40 +0400, Kovalenko Dmitry
W> <[EMAIL PROTECTED]> wrote:
W>
W>> Для того что бы восстановить данные не нужно знать последовательность
W>> их появления.
W>
W> +1
W> Ярким примером является бэкап-рестор  :)

тото он индексы Fk восстанавливает апосля

--
С уважением
Кочмин Александр
Firebird Foundation associate member #257 

Re: прочитал тут ветку про VLDB... reload

[WildSery]

On Wed, 23 May 2007 12:36:40 +0400, Kovalenko Dmitry <[EMAIL PROTECTED]> wrote:

> Для того что бы восстановить данные не нужно знать последовательность
> их появления.

+1
Ярким примером является бэкап-рестор  :)

-- 
Сергей Смирнов.

Re[2]: прочитал тут ветку про VLDB... reload

[Sergey Mereutsa]

Привет!


> вот вы все ссылаетесь на быстро-доступный ближайший бэкап...
> но понимаете, в некоторых случаях бэкап даже пятиминутной давности - УЖЕ
> слишком устаревший.

Хуже всего вещь, которая не может сломаться - потому, что если она
все-таки сломается, ее нельзя будет починить. (С) не помню кто.

Дело в том, что стоимость и надежность системы определяется стоимостью
данных. И всегда (по-моему скромному мнению) надо иметь документ,
который описывает, что делать, если эта супер-пупер система загнется.

При этом, нельзя забывать, что даже если сервак и стоит пол лимона
евриков, он ТОЖЕ можен взять и загнуться. Просто так, для
профилактики. И если это иметь ввиду - то все будет нормально. А то
есть деятели, которые приходят к директору и говорят, мол, возьмем
сервак за сто тыщ - и нам ничего не страшно. А Звездец стоит за дверью
и ждет подходящего момента.

-- 
Best regards,
 Sergeymailto:[EMAIL PROTECTED]

Re: CVS.SF.NET

[Vladimir A.Bakhvaloff]

 Vladimir> 
cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/firebird 
login

ëÒÁÓÉ×Ï!.. :)))
ôÕÔ, ÅÓÔÅÓÔ×ÅÎÎÏ, ÂÙÌÏ:
cvs -d:pserver:anonymouscvs.sourceforge.net:/cvsroot/firebird login

---
E-mail: bobbakhspbru ICQ: 12861767 (1608235)
np: Journey - Don't Stop Believing (from "String Quartet Tribute to John 
Cougar Mellencamp" - ) 

CVS.SF.NET

[Vladimir A.Bakhvaloff]

Hello, All!

óËÁÖÉÔÅ, Á ÜÔÏ ÔÏÌØËÏ Ñ ÎÁ ÐÏÐÙÔËÉ ÐÏÌÕÞÉÔØ ÜÔÉÍ ÂÁÎÔÉËÏÍ:
===
cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/firebird login
cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot/firebird co 
firebird2
===
ÓÏÒÃÙ, ÐÏÌÕÞÁÀ:
===
connect to cvs.sourceforge.net:2401 failed: ðÏÐÙÔËÁ ÕÓÔÁÎÏ×ÉÔØ ÓÏÅÄÉÎÅÎÉÅ 
ÂÙÌÁ ÂÅÚÕÓÐÅÛÎÏÊ, Ô.Ë. ÏÔ ÄÒÕÇÏÇÏ ËÏÍÐØÀÔÅÒÁ ÚÁ ÔÒÅÂÕÅÍÏÅ ×ÒÅÍÑ ÎÅ ÐÏÌÕÞÅÎ 
ÎÕÖÎÙÊ ÏÔËÌÉË, ÉÌÉ ÂÙÌÏ ÒÁÚÏÒ×ÁÎÏ ÕÖÅ ÕÓÔÁÎÏ×ÌÅÎÎÏÅ ÓÏÅÄÉÎÅÎÉÅ ÉÚ-ÚÁ 
ÎÅ×ÅÒÎÏÇÏ ÏÔËÌÉËÁ ÕÖÅ ÐÏÄËÌÀÞÅÎÎÏÇÏ ËÏÍÐØÀÔÅÒÁ.
===
ë ÄÒÕÇÉÍ cvs (ÎÁÐÒÉÍÅÒ, [EMAIL PROTECTED]) ×Ó£ ÏÔÌÉÞÎÏ ÐÒÏÈÏÄÉÔ...

With best regards, Vladimir A.Bakhvaloff.
E-mail: bobbakhspbru
ICQ: 12861767 (1608235)
---
np: Janet Jackson - Control (from "Design of a Decade 1986/1996" - ) 

Re: исправили перекодировку BLOB?

[Vlad Horsun]

"Андрій Жук" ...
>
> Кстати, вот как сделано в UIB
>
>procedure TSQLResult.ReadBlob(const Index: Word; Stream: TStream);
>var BlobData: PBlobData;
>begin
>  CheckRange(Index);
>  if not FFetchBlobs then
>raise Exception.Create(EUIB_FETCHBLOBNOTSET);
>  BlobData := GetDataQuadOffset(Index);
>  Stream.Seek(0, 0);
>  Stream.Write(BlobData.Buffer^, BlobData.Size);
>  Stream.Seek(0, 0);
>end;
>
> Тоже завалится, да?

Тут нет чтения блоба. Может оно в GetDataQuadOffset, но я не знаю наверняка.
Ищи вызовы isc_get_segment

--
Хорсун Влад

Re: исправили перекодировку BLOB?

[Андрій Жук]

Кстати, вот как сделано в UIB

  procedure TSQLResult.ReadBlob(const Index: Word; Stream: TStream);
  var BlobData: PBlobData;
  begin
CheckRange(Index);
if not FFetchBlobs then
  raise Exception.Create(EUIB_FETCHBLOBNOTSET);
BlobData := GetDataQuadOffset(Index);
Stream.Seek(0, 0);
Stream.Write(BlobData.Buffer^, BlobData.Size);
Stream.Seek(0, 0);
  end;

Тоже завалится, да?

Re: прочитал тут ветку про VLDB... reload

[Kovalenko Dmitry]

> но понимаете, в некоторых случаях бэкап даже пятиминутной давности - УЖЕ
> слишком устаревший.
> его нельзя подложить вместо рабочей базы в работу, а только потом влить
> изменения.
> основная причина - ПОСЛЕДОВАТЕЛЬНОСТЬ логических событий в базе.
> нарушится причинно-следственная связь. (смотрели наверно фильм "назад в
> будущее")

Неверное восприятие мира.

Для того что бы восстановить данные не нужно знать последовательность
их появления.

Нужно знать порядок их восстановления, для того чтобы не нарушить
ссылочную целостность базы. И этот порядок может децел отличаться от
ПОСЛЕДОВАТЕЛЬНОСТИ.

Коваленко Дмитрий.

Re: прочитал тут ветку про VLDB... reload

[Alexandr Kochmin]

КА> тоесь я склоняю к необходимости вести логическую дельту с момента
КА> последнего бэкапа. в описанном случае она спасет.

логическая дельта это суть репликация уже, а репликация имеет особенности не 
всегда совместимые с конкретной произвольной базой. И поручать серверу самому 
разбираться в этом ненадо.
Вывод: если тебе это надо, сделай сам как надо тебе эту репликацию да и все.
Вообщем, надо проектирвоать базу правильно и с учетом этого. Тогда и проблемы 
не будет.
имхо

--
С уважением
Кочмин Александр
Firebird Foundation associate member #257 

Re: �������� ��� ����� ��� VLDB... reload

[��������� ������]

ÐÏÎÑÔÎÏÅ ÄÅÌÏ ÒÁÓËÒÉÔÉËÏ×ÁÌÉ
ÄÁ, ÓÏÇÌÁÓÅÎ, ÄÉÓËÉ ÇÁ×ÎÏ, ÖÅÌÅÚÏ ÇÏ×ÎÏ, ÒÕËÉ ÉÚ ÖÏÐÙ ÐÒÏÓÔÉÔÅ ÚÁ
×ÙÒÁÖÅÎÉÅ...
ÃÉÆÒÙ ÐÒÉÂÌÉÚÉÔÅÌØÎÙÅ É ×ÏÏÂÝÅ ÐÒÉÍÅÒ ÍÏÖÅÔ ÎÅ ÐÏÄÈÏÄÑÝÉÊ,
ÎÏ ÄÅÌÏ ÎÅ × ÜÔÏÍ...
ÓÕÔØ × ÓÁÍÏÊ ÐÒÏÂÌÅÍÅ ÏÔÓÕÔÓÔ×ÉÑ online-ÍÅÈÁÎÉÚÍÏ×

×ÏÔ ×Ù ×ÓÅ ÓÓÙÌÁÅÔÅÓØ ÎÁ ÂÙÓÔÒÏ-ÄÏÓÔÕÐÎÙÊ ÂÌÉÖÁÊÛÉÊ ÂÜËÁÐ...
ÎÏ ÐÏÎÉÍÁÅÔÅ, × ÎÅËÏÔÏÒÙÈ ÓÌÕÞÁÑÈ ÂÜËÁÐ ÄÁÖÅ ÐÑÔÉÍÉÎÕÔÎÏÊ ÄÁ×ÎÏÓÔÉ - õöå
ÓÌÉÛËÏÍ ÕÓÔÁÒÅ×ÛÉÊ.
ÅÇÏ ÎÅÌØÚÑ ÐÏÄÌÏÖÉÔØ ×ÍÅÓÔÏ ÒÁÂÏÞÅÊ ÂÁÚÙ × ÒÁÂÏÔÕ, Á ÔÏÌØËÏ ÐÏÔÏÍ ×ÌÉÔØ
ÉÚÍÅÎÅÎÉÑ.
ÏÓÎÏ×ÎÁÑ ÐÒÉÞÉÎÁ - ðïóìåäï÷áôåìøîïóôø ÌÏÇÉÞÅÓËÉÈ ÓÏÂÙÔÉÊ × ÂÁÚÅ.
ÎÁÒÕÛÉÔÓÑ ÐÒÉÞÉÎÎÏ-ÓÌÅÄÓÔ×ÅÎÎÁÑ Ó×ÑÚØ. (ÓÍÏÔÒÅÌÉ ÎÁ×ÅÒÎÏ ÆÉÌØÍ "ÎÁÚÁÄ ×
ÂÕÄÕÝÅÅ")
ÒÅÄËÁÑ ÂÁÚÁ - ÐÒÏÓÔÏ ÈÒÁÎÉÌÉÝÅ ÄÁÎÎÙÈ. × ÏÓÎÏ×ÎÏÍ ÔÁÍ ÚÁÌÏÖÅÎÁ É ËÕÞÁ ÌÏÇÉËÉ
ðòéíåò:
ÄÏÐÕÓÔÉÍ ÉÍÅÅÔÓÑ ÂÅËÁÐ ÞÁÓÏ×ÏÊ ÄÁ×ÎÏÓÔÉ...
ÐÏÓÌÅ ÜÔÏÇÏ × ÂÁÚÅ ÐÒÏÉÓÈÏÄÑÔ ÓÏÂÙÔÉÑ A,B,C É ËÁËÏÊÎÉÂÕÄØ ÓÂÏÊ
ÔÕÔ ÍÙ ÐÏÄËÌÁÄÙ×ÁÅÍ ÐÏÓÌÅÄÎÉÊ ÂÜËÁÐ (ÔÅÒÑÅÍ ÐÏÓÌÅÄÓÔ×ÉÑ ÓÏÂÙÔÉÊ A,B,C).
ÐÒÏÉÓÈÏÄÉÔ ÓÏÂÙÔÉÅ D.
ÎÏ ÐÏÓËÏÌØËÕ × ÜÔÏÔ ÍÏÍÅÎÔ × ÂÁÚÅ ÎÅÔ ÐÏÓÌÅÄÓÔ×ÉÊ ÓÏÂÙÔÉÊ A,B,C, ÔÏ ÓÏÂÙÔÉÅ
D ÌÉÂÏ ÎÅ ÓÍÏÖÅÔ ÓÏÓÔÏÑÔØÓÑ, ÌÉÂÏ ÅÇÏ ÒÅÚÕÌØÔÁÔ ÂÕÄÅÔ ÎÅ×ÅÒÎÙÍ. É
ÐÏÓÌÅÄÕÀÝÅÅ ×ÌÉ×ÁÎÉÅ ÉÚÍÅÎÅÎÉÊ ÂÕÄÕÔ ÕÖÅ ÎÅ ËÓÔÁÔÉ. ÐÏÚÎÏ. ÐÏÅÚÄ ÕÛÅÌ.
ÐÏÌÕÞÁÅÍ ÎÁÒÕÛÅÎÉÅ × ÔÅÈÎÏÌÏÇÉÉ.

Á ×ÏÔ ÅÓÌÉÂÙ ÍÙ ÂÙÓÔÒÅÎØËÏ ÍÏÇÌÉ ÎÁËÁÔÉÔØ ÐÏÓÌÅÄÎÉÅ ÉÚÍÅÎÅÎÉÑ ÎÁ ÐÏÓÌÅÄÎÉÊ
ÂÜËÁÐ...ÂÙÌÏ ÂÙ ×ÓÅ ÚÁÍÅÞÁÔÅÌØÎÏ...
ÔÏÅÓØ Ñ ÓËÌÏÎÑÀ Ë ÎÅÏÂÈÏÄÉÍÏÓÔÉ ×ÅÓÔÉ ÌÏÇÉÞÅÓËÕÀ ÄÅÌØÔÕ Ó ÍÏÍÅÎÔÁ ÐÏÓÌÅÄÎÅÇÏ
ÂÜËÁÐÁ. × ÏÐÉÓÁÎÎÏÍ ÓÌÕÞÁÅ ÏÎÁ ÓÐÁÓÅÔ.

Á ÓÕÝÅÓÔ×ÕÀÝÉÊ nbackup - ÆÉÚÉÞÅÓËÉÊ (ÔÏÅÓÔØ ×ÓÅ ÏÒÉÇÉÎÁÌØÎÙÅ ËÏÓÑËÉ
ÐÅÒÅÎÅÓÕÔÓÑ).

ËÒÏÍÅ ÔÏÇÏ × ×ÅÔËÅ ÐÒÏ VLDB ÏÂÓÕÖÄÁÌÓÑ ×ÏÐÒÏÓ ÐÒÏ "ÎÅÄÏÒÅÓÔÏÒ"
(ÎÅÏÂÈÏÄÉÍÏÓÔØ ÉÍÅÔØ ×ÏÚÍÏÖÎÏÓÔØ ÎÁËÁÔÉÔØ, ÓËÁÖÅÍ, ÕÒÏ×ÅÎØ 3 ÎÁ ÕÖÅ
ÉÍÅÀÝÉÊÓÑ ÒÅÓÔÏÒ ÕÒÏ×ÎÅÊ 0+1+2). ÎÁ ÄÁÎÎÙÊ ÍÏÍÅÎÔ ÒÅÓÔÏÒ ÍÏÖÎÏ ÄÅÌÁÔØ ÔÏÌØËÏ
ÏÄÎÏÊ ÏÐÅÒÁÃÉÅÊ, Á ÜÔÏ ÐÏÔÅÒÑ ×ÒÅÍÅÎÉ ÎÕ ÜÔÏ ×ÒÏÄÅ ×ÓÅÍ ÐÏÎÑÔÎÏ.

Re: исправили перекодировку BLOB?

[Андрій Жук]

Oleg LOA wrote:

"Vlad Horsun" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]

   Да, я имел в виду не AV конечно. Но легче от этого вряд ли...


А я просто не понял чего тогда IBExpert вешается, думал там в IBX "Полный Пэ"
Да он там не совсем вешается, просто ошибка выскакивает бесконечное 
число раз.

Re: исправили перекодировку BLOB?

[Vlad Horsun]

"Oleg LOA" ...
> "Vlad Horsun" ...
> >Да, я имел в виду не AV конечно. Но легче от этого вряд ли...
>
> А я просто не понял чего тогда IBExpert вешается, думал там в IBX "Полный Пэ"

У него по разному - иногда редактор блобов просто не показывается,
иногда ошибками сыпет, пока не снимешь (это если прямые селекты делать).
В тексте процедуры показывает "(Blob)"

--
Хорсун Влад

Re: исправили перекодировку BLOB?

[Vlad Horsun]

"Oleg LOA" ...
> "Vlad Horsun" ...
> >Вот здесь. Ибо возвращается isc_segstr_eof (он пытается прочитать больше,
> > чем есть) и BytesRead == 0
> >
>
> Так он просто исключение выбросит но не упадёт по AV

Да, я имел в виду не AV конечно. Но легче от этого вряд ли...

--
Хорсун Влад

Re: Текстовая индексация

[Makmak]

З.Ы. Народ, а никто не в курсе, с каких пор в процедуро-триггерном DML
поддерживаются конструкции типа
if(stringvalue in ('abc','bca', 'cab'))
then begin
 blah-blah-blah
end
?

Я был в легком удивлении, когда обнаружил сей факт. В релизнотах
ничего не заметил...


Как IN сделали, так и поддерживается, AFAIU ;)


IIRC, никогда он не работал. Если заработал в 2.х, то это скорее побочный 
эффект :-)


Ну спасибо вам за этот "побочный эффект" и проявился он ну очень давно.

Удачи!
Макмак