Re: контекст
Hello, Alexander! Alexander A. Venikov wrote: Чудес на свете не бывает, но вот взвёл ты народ... ;) VK А вот теперь перечитай N раз то, что я написал изначально Да ладно, Влад, облажался... :) Я в исходном посте именно про hostname писал. :-P а в IB имя хоста в дополнение к IP есть. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: контекст
Alexander A. Venikov wrote: Отресолвить может, конечно, не только FB, но тут надо уже UDF городить... Если FB сам начнет ресолвить ip-адреса в имена хостов - возможны хорошие тормоза в случае [криво/не]настроенного DNS. Лучше уж UDF кому надо пусть пользует ;-) -- Oleg
GTT и оптимизатор
Добрый день! FireBird WI-V6.3.0.17755 RC2 CREATE TABLE OUT_INVOICE ( CODED_INT NOT NULL /* D_INT = INTEGER NOT NULL */, CODE_SHOP D_INT /* D_INT = INTEGER NOT NULL */, CODE_STORAGED_INT /* D_INT = INTEGER NOT NULL */, CODE_DSTD_INT /* D_INT = INTEGER NOT NULL */, CODE_PATTERND_INT /* D_INT = INTEGER NOT NULL */, PAYER_VAT D_INT DEFAULT 1 /* D_INT = INTEGER NOT NULL */, NUMBER_INVOICE D_VAR15_NN /* D_VAR15_NN = VARCHAR(15) NOT NULL */, DATE_INVOICED_DATE /* D_DATE = DATE NOT NULL */, STATE_INVOICE D_INT /* D_INT = INTEGER NOT NULL */, DATE_PAYD_DATE /* D_DATE = DATE NOT NULL */, SUMMA_PAY D_DP DEFAULT 0.0 /* D_DP = DOUBLE PRECISION DEFAULT 0.0 */, PAY_TYPED_INT /* D_INT = INTEGER NOT NULL */, CODE_BILL D_INT default 0 /* D_INT = INTEGER NOT NULL */, CODE_KASSA D_INT DEFAULT 0 /* D_INT = INTEGER NOT NULL */, NUMBER_BILL D_INT DEFAULT 0 /* D_INT = INTEGER NOT NULL */, NUMBER_SLIP D_VAR5 /* D_VAR5 = VARCHAR(5) */, CODE_CORRECTD_INT DEFAULT 0 /* D_INT = INTEGER NOT NULL */, CREATOR D_VAR15 /* D_VAR15 = VARCHAR(15) */, DATE_CREATE D_TIME /* D_TIME = TIMESTAMP */, UPDATOR D_VAR15 /* D_VAR15 = VARCHAR(15) */, DATE_UPDATE D_TIME /* D_TIME = TIMESTAMP */ ); / **/ /*** Primary Keys ***/ / **/ ALTER TABLE OUT_INVOICE ADD PRIMARY KEY (CODE); / **/ /*** Foreign Keys ***/ / **/ ALTER TABLE OUT_INVOICE ADD CONSTRAINT FK_OUT_INVOICE_1 FOREIGN KEY (CODE_PATTERN) REFERENCES DOCUMENT_PATTERN_LIST (CODE_PATTERN); ALTER TABLE OUT_INVOICE ADD CONSTRAINT FK_OUT_INVOICE_DST FOREIGN KEY (CODE_DST) REFERENCES CLIENT_LIST (CODE_CLIENT); ALTER TABLE OUT_INVOICE ADD CONSTRAINT FK_OUT_INVOICE_SHOP FOREIGN KEY (CODE_SHOP) REFERENCES CLIENT_LIST (CODE_CLIENT); ALTER TABLE OUT_INVOICE ADD CONSTRAINT FK_OUT_INVOICE_STORAGE FOREIGN KEY (CODE_STORAGE) REFERENCES CLIENT_LIST (CODE_CLIENT); / **/ /*** Indices ***/ / **/ CREATE DESCENDING INDEX OUT_INVOICE_IDX1 ON OUT_INVOICE (DATE_INVOICE, CODE_PATTERN); CREATE INDEX OUT_INVOICE_IDX2 ON OUT_INVOICE (NUMBER_INVOICE); CREATE INDEX OUT_INVOICE_IDX3 ON OUT_INVOICE (NUMBER_BILL, CODE_KASSA); CREATE TABLE OUT_INVOICE_WARES ( CODE_OUT D_INT NOT NULL /* D_INT = INTEGER NOT NULL */, CODE_IND_INT /* D_INT = INTEGER NOT NULL */, CODE_OUT_INVOICE D_INT /* D_INT = INTEGER NOT NULL */, CODE_INVOICE D_INT /* D_INT = INTEGER NOT NULL */, CODE_WARES D_INT /* D_INT = INTEGER NOT NULL */, CODE_UNIT D_INT /* D_INT = INTEGER NOT NULL */, CODE_UNIT_INVOICE D_INT /* D_INT = INTEGER NOT NULL */, CODE_DST D_INT /* D_INT = INTEGER NOT NULL */, DATE_INVOICE D_DATE /* D_DATE = DATE NOT NULL */, STATE_INVOICE D_INT /* D_INT = INTEGER NOT NULL */, AMOUNT D_DP /* D_DP = DOUBLE PRECISION DEFAULT 0.0 */, AMOUNT_BASIS D_DP /* D_DP = DOUBLE PRECISION DEFAULT 0.0 */, PRICE D_DP /* D_DP = DOUBLE PRECISION DEFAULT 0.0 */, VATD_DP /* D_DP = DOUBLE PRECISION DEFAULT 0.0 */, FIRST_CODE D_INT /* D_INT = INTEGER NOT NULL */, CODE_TYPE D_INT /* D_INT = INTEGER NOT NULL */, CREATORD_VAR15 /* D_VAR15 = VARCHAR(15) */, DATE_CREATED_TIME /* D_TIME = TIMESTAMP */, UPDATORD_VAR15 /* D_VAR15 = VARCHAR(15) */, DATE_UPDATED_TIME /* D_TIME = TIMESTAMP */ ); / **/ /*** Primary Keys ***/ / **/ ALTER TABLE OUT_INVOICE_WARES ADD CONSTRAINT PK_OUT_INVOICE_WARES PRIMARY KEY (CODE_OUT); / **/ /*** Foreign Keys ***/ / **/ ALTER TABLE OUT_INVOICE_WARES ADD CONSTRAINT FK_OUT_INVOICE_WARES_1 FOREIGN KEY (CODE_IN) REFERENCES INVOICE_WARES (CODE_IN); ALTER TABLE OUT_INVOICE_WARES ADD CONSTRAINT
Re: GTT и оптимизатор
Peter wrote: Что делать? Проблема небось в нулевой статистике индекса на GTT. И откуда ей быть правильной, если данные существуют лишь в пределах транзакции, а SET STATISTICS срабатывает при коммите. Сходу выхода видится два: рулить планом вручную или пытаться переделать логику приложения под GTT PRESERVE ROWS. -- Дмитрий Еманов
Re: GTT и оптимизатор
Peter пишет: select oiw.code_wares,wl.code_group,tgl.code,wl.name_wares from out_invoice oi join out_invoice_wares oiw on (oi.date_invoice between '01.03.2007' and '01.03.2007' and oi.code=oiw.code_out_invoice ) join wares_list wl on (oiw.code_wares=wl.code_wares) left join temp_group_list tgl on (tgl.code=wl.code_group) where tgl.code is not null? -- Александр Замараев
Re: контекст
Hello, Dmitry! Dmitry Yemanov wrote: а в IB имя хоста в дополнение к IP есть. Добавить-то можно. Но смысл? Идентификация хоста есть уже сейчас. Если кому-то шашечки, а не ехать, то IMHO в сад. Если у секьюрити нет таблицы соответствия хостов ip-шникам -- разогонать нах :-) Дим, это УДОБНО. и других объяснений не требует. как делается эта идентификация в IB - не знаю. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: контекст
Alexander A. Venikov ... Чудес на свете не бывает, но вот взвёл ты народ... ;) VK А вот теперь перечитай N раз то, что я написал изначально Да ладно, Влад, облажался... :) Та ты шо ! Я в исходном посте именно про hostname писал. :-P А я писал про а) поможет, а не в нём именно это есть и б) протоколироватьконнект/дисконнект В следующий раз я просто буду игнорировать такие вопросы. Мне есть чем заниматься, кроме как поддерживать тупой флейм -- Хорсун Влад
Re: GTT и оптимизатор
On 16 апр, 10:25, Dmitry Yemanov [EMAIL PROTECTED] wrote: Peter wrote: Что делать? Проблема небось в нулевой статистике индекса на GTT. И откуда ей быть правильной, если данные существуют лишь в пределах транзакции, а SET STATISTICS срабатывает при коммите. Сходу выхода видится два: рулить планом вручную или пытаться переделать логику приложения под GTT PRESERVE ROWS. -- Дмитрий Еманов План от второго запроса к первому не прибивается :( Попробую поменять логику. Спасибо.
Re: GTT и оптимизатор
On 16 апр, 10:40, Tonal [EMAIL PROTECTED] wrote: Peter пишет: select oiw.code_wares,wl.code_group,tgl.code,wl.name_wares from out_invoice oi join out_invoice_wares oiw on (oi.date_invoice between '01.03.2007' and '01.03.2007' and oi.code=oiw.code_out_invoice ) join wares_list wl on (oiw.code_wares=wl.code_wares) left join temp_group_list tgl on (tgl.code=wl.code_group) where tgl.code is not null? -- Александр Замараев Те же яйца, вид с боку.
Re[2]: контекст
Привет! а в IB имя хоста в дополнение к IP есть. Добавить-то можно. Но смысл? Идентификация хоста есть уже сейчас. Если кому-то шашечки, а не ехать, то IMHO в сад. Если у секьюрити нет таблицы соответствия хостов ip-шникам -- разогонать нах :-) Дим, это УДОБНО. и других объяснений не требует. как делается эта идентификация в IB - не знаю. Дим, ты знаешь, я параноик местами ;-) Но все равно не понимаю, чем знание имени хоста поможет в разборках. Кроме того, что ethostbyaddr() тормознутая вещь даже при хорошо настроенном dns при большом количестве подключений/отключений (именно поэтому в логах обычно хранят только IP, а не имя хоста), проблем безопасности это не решает - если уж предположить, что некто сменит IP и при этом все будет работать (да, я знаю. и MAC-адрес поменять можно), то он точно также сможет устроить подмену имени хоста. А если это не кулхацкер - то и заморачиваться нечего. А для защиты от кулхацкеров можно использовать туннели с ключами и прочими садо-мазо игрушками. -- Best regards, Sergeymailto:[EMAIL PROTECTED]
Re: контекст
On Wed, 16 Apr 2008 11:49:16 +0400, Dmitri Kuzmenko [EMAIL PROTECTED] wrote: Дим, это УДОБНО. и других объяснений не требует. как делается эта идентификация в IB - не знаю. И я не вижу никакого дополнительного удобства. Таблицу соответствия имён можно и отдельно забить, как раз для отчёта секуристам. Ты лучше скажи, как быть с WiFi-ноутами, которых то нет, то есть, но уже новый IP им DHCP выдал, то имя ноута поменяли, потому что так красивее, или настроение изменилось ... Если нужна регистрация, нужно регистрировать всё. IP, Hostname, MAC, current_user, ... Пока контекстов не было, мы UDF-кой большую часть этого доставали. И не жужжим. -- Сергей Смирнов.
Re: контекст
Hello, Sergey! You wrote to Dmitri Kuzmenko on Wed, 16 Apr 2008 11:04:05 +0300: Дим, это УДОБНО. и других объяснений не требует. Да. SM Но все равно не понимаю, чем знание имени SM хоста поможет в разборках. Да ничем не поможет, ибо и IP, и hostname, и MAC можно подменять. Смысла вообще нет в таком протоколировании. Злоумышленника так не выловить. Идиоту по рукам дать можно, но не более. И то, от идиотов существует правильная раздача грантов в БД. Но наши секьюрити возомнили себя крутыми специалистами и банально сношают мозг. -- Удач Alexander A. Venikov, Tobolsk, Russia
Re: GTT и оптимизатор
On Wed, 16 Apr 2008 10:40:57 +0400, Peter info-E5/[EMAIL PROTECTED] wrote: Интересно, а какой план получается вот так: select oiw.code_wares,wl.code_group,tgl.code,wl.name_wares from out_invoice oi join out_invoice_wares oiw on (oi.code+0 = oiw.code_out_invoice) join wares_list wl on (oiw.code_wares+0 = wl.code_wares) join temp_group_list tgl on (tgl.code = wl.code_group+0) where oi.date_invoice between date '01.03.2007' and date '01.03.2007' -- Сергей Смирнов.
Re: контекст
Hello, Vlad! You wrote on Wed, 16 Apr 2008 10:52:39 +0300: VK В следующий раз я просто буду игнорировать VK такие вопросы. Мне есть чем заниматься, кроме VK как поддерживать тупой флейм Представь себе, мне тоже есть чем заниматься. Вопрос был поставлен конкретно. Твой неконкретный ответ этот тупой флейм и спровоцировал. Лучше уж игнорировать, в самом деле, чем вводить в заблуждение. Ладно, проехали. -- Удач Alexander A. Venikov, Tobolsk, Russia
Re: контекст
Alexander A. Venikov ... Лучше уж игнорировать Договорились, я тебе больше не помогаю -- Хорсун Влад
Re: GTT и оптимизатор
On 16 апр, 11:17, WildSery [EMAIL PROTECTED] wrote: On Wed, 16 Apr 2008 10:40:57 +0400, Peter info-E5/[EMAIL PROTECTED] wrote: Интересно, а какой план получается вот так: select oiw.code_wares,wl.code_group,tgl.code,wl.name_wares from out_invoice oi join out_invoice_wares oiw on (oi.code+0 = oiw.code_out_invoice) join wares_list wl on (oiw.code_wares+0 = wl.code_wares) join temp_group_list tgl on (tgl.code = wl.code_group+0) where oi.date_invoice between date '01.03.2007' and date '01.03.2007' -- Сергей Смирнов. Получается как от второго запроса. Но я уже переделал на ON COMMIT PRESERVE ROWS. Работает как надо. Считаю, что тему можна закрыть. Всем спасибо.
Re: контекст
Hello, WildSery! WildSery wrote: Дим, это УДОБНО. и других объяснений не требует. как делается эта идентификация в IB - не знаю. И я не вижу никакого дополнительного удобства. трудно спорить о вкусе ананасов. Таблицу соответствия имён можно и отдельно забить, как раз для отчёта секуристам. блин, да идите нафиг со своей секурностью. Основная задача таблиц TMP$ и MON$ - анализ производительности. И там НАДО видеть имя компа а не IP. IP можно, до кучи, но в локальной сети он почти не имеет значения, т.к. может меняться при динамической выдаче. то есть, И имя И ip в мониторинге нужны. Они служат разным целям. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: GTT и оптимизатор
Peter wrote: Шаг первый - пересчитываю статистику по GTT через IBExpert (v 2008.04.04) Шаг второй - повторная попытка пересчитать статистику по той же таблице выдает maximum indexes per table (408) exceeded Бага, похоже. -- Дмитрий Еманов
Re: контекст
Hello, Dmitri! You wrote on Wed, 16 Apr 2008 13:29:21 +0400: DK для разборок - ip. для визуального просмотра - имя. DK Вот ты не работаешь с IB. А я несколько реальных DK систем знаю, и там ОЧЕНЬ удобно когда пишется имя. DK Видно - что это за комп, а на ip можно и потом посмотреть. DK А по IP, особенно если включена динамическая раздача DK с DHCP - и что тебе даст IP, если у одной и той же DK машины сегодня и завтра они РАЗНЫЕ??? не так часто они изменяются (от настроек DHCP зависит), но таки да. Кроме того, что gethostbyaddr() тормознутая вещь даже при хорошо настроенном dns при большом количестве подключений/отключений (именно DK да не знаю я, чем ИБ это имя получает. Может, DK клиент его передает на сервер при коннекте. А нет ли его где-нить в структурах сокета? Если уж имя пользовательского процесса есть, породившего коннект, то имя хоста здесь само напрашивается. Да, не только секурность, а в дальнейшем и для анализа кто сервер завесил. Не ожидается частых коннектов-дисконнектов. Задача - документооборот. -- Удач Alexander A. Venikov, Tobolsk, Russia
Re: контекст
Hello, Dmitry! You wrote on Wed, 16 Apr 2008 13:57:39 +0400: DY Alexander A. Venikov wrote: имя хоста здесь само напрашивается DY В трекер. Не умею. Поможет кто? Или пните в нужном направлении :) -- Удач Alexander A. Venikov, Tobolsk, Russia
Re[2]: контекст
Привет! А по IP, особенно если включена динамическая раздача с DHCP - и что тебе даст IP, если у одной и той же машины сегодня и завтра они РАЗНЫЕ??? Уволить такого админа :) Lease time == forever и ваша секурити страдать не будет. Разумеется, привязка идет по маку. Ну если ооочень хочется - то выставить время назначения адреса длиной в год - если за год секурити не спохватилась - нах такую секурити :) Кроме того, что ethostbyaddr() тормознутая вещь даже при хорошо настроенном dns при большом количестве подключений/отключений (именно да не знаю я, чем ИБ это имя получает. Может, клиент его передает на сервер при коннекте. А оно ничем другим это имя получать и не может. Разве что мы не про TCP/IP говорим. А так - только gethostbyaddr() которая вызывается при коннекте пользователя. И в общем случае - оно _может_ тормозить. К тому же, у машины (как в винде, так и других ОС) имя может несовпадать с тем, что прописано в DNS. И что тогда делать? ;-) это не кулхацкер - то и заморачиваться нечего. А для защиты от кулхацкеров можно использовать туннели с ключами и прочими садо-мазо игрушками. какие нафиг кулхацкеры??? При мониторинге производительности (!!!) нужно знать имена клиентских машин. В локальной сети. Полностью согласен, особенно когда компов целая куча. Хотя я считаю это незначительным неудобством по сравнению с проблемами распараллеливаимости супера :) -- Best regards, Sergeymailto:[EMAIL PROTECTED]
Re: контекст
Hello, Sergey! Sergey Mereutsa wrote: Но все равно не понимаю, чем знание имени хоста поможет в разборках. для разборок - ip. для визуального просмотра - имя. Вот ты не работаешь с IB. А я несколько реальных систем знаю, и там ОЧЕНЬ удобно когда пишется имя. Видно - что это за комп, а на ip можно и потом посмотреть. А по IP, особенно если включена динамическая раздача с DHCP - и что тебе даст IP, если у одной и той же машины сегодня и завтра они РАЗНЫЕ??? Так что, Серж, за статью по кластерам уважаю, а вот тут ты сел в лужу натурально :-) Кроме того, что ethostbyaddr() тормознутая вещь даже при хорошо настроенном dns при большом количестве подключений/отключений (именно да не знаю я, чем ИБ это имя получает. Может, клиент его передает на сервер при коннекте. это не кулхацкер - то и заморачиваться нечего. А для защиты от кулхацкеров можно использовать туннели с ключами и прочими садо-мазо игрушками. какие нафиг кулхацкеры??? При мониторинге производительности (!!!) нужно знать имена клиентских машин. В локальной сети. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: GTT и оптимизатор
On 16 апр, 11:32, Tonal [EMAIL PROTECTED] wrote: Peter пишет: left join temp_group_list tgl on (tgl.code=wl.code_group) where tgl.code is not null? Те же яйца, вид с боку. Эээ. А план какой? PLAN JOIN (TGL NATURAL, BGL INDEX (INTEG_4), WL INDEX (FK_WARES_LIST_GROUP), OIW INDEX (OUT_INVOICE_WARES_IDX3), OI INDEX (RDB$PRIMARY17)) А если явно указать? PLAN JOIN (JOIN (OI INDEX (OUT_INVOICE_IDX1),OIW INDEX (FK_OUT_INVOICE_WARES_4), WL INDEX (INTEG_17)), TGL INDEX (TEMP_GROUP_LIST_IDX1)) Не прибивается.
Re: контекст
Alexander A. Venikov wrote: имя хоста здесь само напрашивается В трекер. -- Дмитрий Еманов
Re: GTT и оптимизатор
Воспроизводимый пример, желательно без IBE, можешь сделать ? -- Хорсун Влад Есть база с двумя GTT таблицами (пустые обе). Любая попытка выполнить повторно в SQL-едиторе запрос : SET STATISTICS INDEX TEMP_GROUP_LIST_IDX1 или SET STATISTICS INDEX TEMP_GROUP_LIST_IDX11 приводит к Cannot commit transaction: This operation is not defined for system tables. unsuccessful metadata update. maximum indexes per table (408) exceeded. Куда заслать?
Re: GTT и оптимизатор
Кстати, Дима, такой вопрос : Шаг первый - пересчитываю статистику по GTT через IBExpert (v 2008.04.04) Шаг второй - повторная попытка пересчитать статистику по той же таблице выдает maximum indexes per table (408) exceeded После реконекта аналогично облом на 2 шаге.
Re: контекст
Dmitri Kuzmenko wrote: Но все равно не понимаю, чем знание имени хоста поможет в разборках. для разборок - ip. для визуального просмотра - имя. Вот ты не работаешь с IB. А я несколько реальных систем знаю, и там ОЧЕНЬ удобно когда пишется имя. Видно - что это за комп, а на ip можно и потом посмотреть. Еще удобнее когда фотография пользователя показывается. А на имя можно и потом посмотреть... ;-) -- Oleg
Re: GTT и оптимизатор
Peter ... Кстати, Дима, такой вопрос : Шаг первый - пересчитываю статистику по GTT через IBExpert (v 2008.04.04) Шаг второй - повторная попытка пересчитать статистику по той же таблице выдает maximum indexes per table (408) exceeded После реконекта аналогично облом на 2 шаге. Воспроизводимый пример, желательно без IBE, можешь сделать ? -- Хорсун Влад
Re[2]: контекст
Привет! Кроме того, что ethostbyaddr() тормознутая вещь даже при хорошо настроенном dns при большом количестве подключений/отключений (именно да не знаю я, чем ИБ это имя получает. Может, клиент его передает на сервер при коннекте. Да, кстати, подумалось - а может имя хоста (которое может не совпадать с DNS-овским) они передают из клиентской либы при коннекте? Если есть возможность - было бы интересно посмотреть, что у IB будет в том поле, когда имя машины machine1, а у DNS-а она числится как dyn-x-001, к примеру. Какое поле там будет? Если окажется, что это имя присылает клиент и сервер ему верит на слово (а по-другому в данном случае и быть не может), то тут такой простор для кулхацкеров... :) -- Best regards, Sergeymailto:[EMAIL PROTECTED]
Re: контекст
Sergey Mereutsa wrote: Если окажется, что это имя присылает клиент Думаю, так оно и есть. тут такой простор для кулхацкеров... :) Только если они будут фильтровать пакеты. А если такое в сети допускается, то секьюрити вообще распять надо :-) -- Дмитрий Еманов
Re: GTT и оптимизатор
Есть база с двумя GTT таблицами (пустые обе). Любая попытка выполнить повторно в SQL-едиторе запрос : SET STATISTICS INDEX TEMP_GROUP_LIST_IDX1 или SET STATISTICS INDEX TEMP_GROUP_LIST_IDX11 приводит к Cannot commit transaction: This operation is not defined for system tables. unsuccessful metadata update. maximum indexes per table (408) exceeded. Куда заслать? В трекер :) Я уже исправил, так что сам внесу. Спасибо за пример. -- Хорсун Влад
Re: контекст
Hello, Sergey! Sergey Mereutsa wrote: Уволить такого админа :) Lease time == forever и ваша секурити страдать не будет. Разумеется, привязка идет по маку. Ну если ооочень хочется - то выставить время назначения адреса длиной в год - если за год секурити не спохватилась - нах такую секурити :) Сергей, мы тут вообще о чем говорим? При чем тут вообще секурность? MON$ATTACHMENTS использовать для отлова левых IP? А разве MON$ - это аудит? Это съем текущего состояния сервера. Дальше - по поводу уволить админа - это демагогия. Ты не можешь к каждой копии FB выдавать такую бумажку, что если у вас динамический айпи - увольняйте админа. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: контекст
DY В трекер. AAV Не умею. Поможет кто? Или пните в нужном направлении :) где-то здесь http://tracker.firebirdsql.org/browse/CORE
Re: контекст
Hello, Sergey! Sergey Mereutsa wrote: клиент и сервер ему верит на слово (а по-другому в данном случае и быть не может), то тут такой простор для кулхацкеров... :) давайте забудем про кулхацкеров в отношении MON$. Если это попытка обеспечить безопасность, то на мой взгляд это попытка натягивания глаза на заднюю часть тела. кулхацкеров надо ловить при помощи аудита. А еще лучше - не при помощи СУБД. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: контекст
Если FB сам начнет ресолвить ip-адреса в имена хостов - возможны хорошие тормоза в случае [криво/не]настроенного DNS. Лучше уж UDF кому надо пусть пользует ;-) А у меня уже давно в стартап скрипте пишется ip, имя рабочей станции и время начала работы в табличку БД. В шатдаун скрипте заносится время окончания работы. В случае кнопки ресет, в триттерах при добавлении очередной записи, проставляется время окончания работы у предыдущей записи для рабочей станции. Имя компьютера пользователь менять не может. With b/r. Gleb.
Re[2]: контекст
Привет! Сергей, мы тут вообще о чем говорим? При чем тут вообще секурность? MON$ATTACHMENTS использовать для отлова левых IP? А разве MON$ - это аудит? Это съем текущего состояния сервера. Дальше - по поводу уволить админа - это демагогия. Ты не можешь к каждой копии FB выдавать такую бумажку, что если у вас динамический айпи - увольняйте админа. Согласен, что это не выход - тут я с увольнениями загнул :) Но вот слепо доверять тому, что там в этом поле... для этого хотелось бы знать, как туда попадает это значение. Хотя, если говорить об анализе производительности - то мне лично адреса с головой хватает, но на вкус и цвет... З.Ы. А низзя у борланда (или кто там сейчас IB владеет) узнать, как они получают значение этого пля - с клиента или резолвят адрес в имя? -- Best regards, Sergeymailto:[EMAIL PROTECTED]
Re: контекст
Мадорский Г.В. wrote: время начала работы в табличку БД. В шатдаун скрипте заносится время окончания работы. В случае кнопки ресет, в триттерах при добавлении очередной записи, проставляется время окончания работы у предыдущей записи для рабочей станции. какое время проставляешь в последнюю запись?
Re: Re[2]: контекст
Привет, Sergey! Вы пишешь к Dmitri Kuzmenko 16 апреля 2008: [Sorry, skipped] SM З.Ы. А низзя у борланда (или кто там сейчас IB владеет) узнать, как SM они получают значение этого пля - с клиента или резолвят адрес в имя? Для этого достаточно tdump-а. (для Win, естественно) tdump -em fbserver.exe|grep host Вместо fbserver, естественно, нужно экзешник IB. -- With best regards, Alex Cherednichenko.
Re: контекст
давайте забудем про кулхацкеров в отношении MON$. Если это попытка обеспечить безопасность, то на мой взгляд это попытка натягивания глаза на заднюю часть тела. кулхацкеров надо ловить при помощи аудита. А еще лучше - не при помощи СУБД. Дима, ты чего? На клиент-сервер руку поднял?! Все, абсолютно все должен делать сервер! О боже я вижу будущее и стандартные UDF, которые конвертируют IP в символьное имя! Коваленко Дмитрий.
Re: Re[2]: контекст
Alex Cherednichenko ... Привет, Sergey! Вы пишешь к Dmitri Kuzmenko 16 апреля 2008: [Sorry, skipped] SM З.Ы. А низзя у борланда (или кто там сейчас IB владеет) узнать, как SM они получают значение этого пля - с клиента или резолвят адрес в имя? Если с клиента - обязаны опубликовать соотв. dpb_xxx Для этого достаточно tdump-а. (для Win, естественно) tdump -em fbserver.exe|grep host И шо ? Ну, найдёшь ты их там 5 штук... -- Хорсун Влад
Re: ��������
Hello, Alex! You wrote to Vlad Khorsun on Tue, 15 Apr 2008 20:54:20 +0400: VK á ×ÏÔ ÔÅÐÅÒØ ÐÅÒÅÞÉÔÁÊ N ÒÁÚ ÔÏ, ÞÔÏ Ñ VK ÎÁÐÉÓÁÌ ÉÚÎÁÞÁÌØÎÏ AC îÕ, ÜÔÏ ÕÖ ÐÕÓËÁÊ Alexander A. Venikov ÓËÁÖÅÔ, AC ÎÁÓËÏÌØËÏ ÔÙ ÅÇÏ ÏÂÍÁÎÕÌ... ;) ñ ÄÁÖÅ M ÒÁÚ ÐÒÏÞÉÔÁÌ, ÎÅÔ, ÄÁÖÅ K... :) ëÏÒÏÞÅ, ÍÙ ÖÅ ÅÝ£ É ÓÁÍÉ ÄÕÒÁËÉ... :))) -- Alexander A. Venikov, Tobolsk, Russia
Временные ряды в FB и не только
Приветствую уважаемую конференцию! Когда-то постоянно был тут с вами, теперь очень редко почитываю. Может что-то и пропустил по интересующему меня вопросу, не обессудьте. У нас есть программный продукт для построения АСУТП, АСКУЭ и прочей автоматизации - SCADA-система ЭНТЕК (она же КАСКАД). В качестве базы данных, в первую очередь для истории изменения параметров и прочего, используется FB. Структурой БД забивать головы не буду, примитивно ее можно описать так (основные таблицы для хранения данных): 1. Дата-время - поле для даты времени отсчета 2. Список значений - поле для списка значений многих параметров на указанную дату-время, переменной длины. В случае FB второе поле имеет тип BLOB, и мы там размещаем любой необходимый нам список значений в каждой записи. Такая методология хранения удобна для регистрации данных в процессе их появления, но плоха для их последующей обработки (нет индексации по параметрам, только по дате-времени). Правда последнее начинает сказываться все таки на реально больших объемах информации. Сейчас перед нами стоит задача создать новый тип хранилища с универсальным доступом (видимо OLE DB) на базе серверов Oracle и MS SQL. Эти сервера - просто требования рынка, заказчиков, приходится к ним прислушиваться. В любом случае FB в существующей реализации останется как сервер для локальных участков автоматизации, а большие сервера будут использоваться как накопители для объединения информации с участков в центральной хранилище. В новом хранилище сразу будет использоваться другой принцип хранения временных рядов (примерная структура таблицы): 1. Идентификатор параметра, которому принадлежит временной ряд 2. Дата-время начала данных в ряду 3. Дата-время конца данных в ряду 4. Список значений указанного параметра, от начала и до конца ряда, любой длины. Такая структура позволит ввести индексацию как по дате-времени, так и по идентификатору параметра. Если реализовывать такую структуру только в FB, то все понятно - последнее поле делаем в БЛОБе (или даже во внешних файлах). Теперь сам вопрос. Я давно отошел от кодирования, занимаюсь больше постановкой задач, сервера Oracle и MS SQL абсолютно не знаю. Хотелось бы услышать совет - как можно реализовать последнюю структуру в этих серверах, фактически конкретно поле переменной длины для хранения бинарных данных. Еще лучше, если это можно будет сделать универсально для обоих, а может даже и для всех трех (никто в приниципе не мешает и сам FB использовать как центральное хранилище, если заказчик не против). Спасибо за внимание, Александр Бурмистров, www.entels.ru. -- View this message in context: http://www.nabble.com/%D0%92%D1%80%D0%B5%D0%BC%D0%B5%D0%BD%D0%BD%D1%8B%D0%B5-%D1%80%D1%8F%D0%B4%D1%8B-%D0%B2-FB-%D0%B8-%D0%BD%D0%B5-%D1%82%D0%BE%D0%BB%D1%8C%D0%BA%D0%BE-tp16730130p16730130.html Sent from the firebird-russian mailing list archive at Nabble.com.
Разработчики подскажите про CURSOR
Курсорами не пользовался практически. Было гдето одно или 2 места ито с одной таблицей. А тут с пылу с жару написаль такое запустил отработало. Но потом подумалось, а ведь я использовал 2 таблицы. Вот теперь гложат сомнения, а вдруг глюк и потом уберут возможность или все нормаль, и работать будет всегда и правильно. С точки зрения логики вроде все нормально. for select CODED049n, CODED206n, CODED040n, CODED016n, CODED050n from d048 D, ALTNAMES A where A.CodeD049 = D.CodeD049 and A.CodeD206 = D.CodeD206 and A.CodeD040 = D.CodeD040 and A.CodeD016 = D.CodeD016 and ((A.CodeD050 = D.CodeD050) or (A.CodeD050 = '' and D.CodeD050 is null)) INTO CODED049n, CODED206n, CODED040n, CODED016n, CODED050n AS CURSOR TMPCURSOR do begin if (CODED050n = '') then CODED050n = null; update d048 set CodeD049 = :CodeD049n, CodeD206 = :CodeD206n, CodeD040 = :CodeD040n, CodeD016 = :CodeD016n, CodeD050 = :CodeD050n where CURRENT OF TMPCURSOR; suspend; end
Re: Разработчики подскажите про CURSOR
Boltik Evgeny wrote: for select CODED049n, CODED206n, CODED040n, CODED016n, CODED050n from d048 D, ALTNAMES A where A.CodeD049 = D.CodeD049 and A.CodeD206 = D.CodeD206 and A.CodeD040 = D.CodeD040 and A.CodeD016 = D.CodeD016 and ((A.CodeD050 = D.CodeD050) or (A.CodeD050 = '' and D.CodeD050 is null)) INTO CODED049n, CODED206n, CODED040n, CODED016n, CODED050n AS CURSOR TMPCURSOR do begin if (CODED050n = '') then CODED050n = null; update d048 set CodeD049 = :CodeD049n, CodeD206 = :CodeD206n, CodeD040 = :CodeD040n, CodeD016 = :CodeD016n, CodeD050 = :CodeD050n where CURRENT OF TMPCURSOR; suspend; end Обычный (без DISTINCT / GROUP BY) внутренний джойн курсорам не мешает. Единственный нюанс это если джойн будет left и апдейтиться будет внутренняя таблица -- тогда возможны сюрпризы на отсутствующих записях. Что, в принципе, вполне логично :-) -- Дмитрий Еманов
