Firebird+ODBC

[Sla]

option B

[Алексей++]

Sla, я видел этот рисунок. На нём OptionA - это часть от моей схемы

[Sla]

почитал, разницы, практически, между option нет. Только порт 3050 нужно закрывать от внешних соединений.

ZeBeDee  выступает только одним клиентом...
Серверов ZeBeDee, может быть несколько (например на разных, портах, на разных адресах)

Один клиент подразумевает, что ZeBeDee является только мостом к Одному сервису.

[Алексей++]

то есть я пролетаю, похоже

[Sla]

почему?
что тебя смущает?
option A видишь? две косых - это много клиентов коннекттся через ZeBeDee к птице

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

[Алексей++]

но это же мне придётся для каждого УК на сервере один парный ZBD ставить

Добавлено через 1 минуту и 25 секунд:
то есть вот так

УК1::[FB <-> ZBD] <------------> |
                                 |
УК2::[FB <-> ZBD] <------------> | [тырнет]   <---------> СЕРВЕР::[ZBD1,ZBD2,ZBD3 <-> FB]
                                 |
УК3::[FB <-> ZBD] <------------> |

?

[Sla]

Вот так!

УК1::[FBclient <-> ZBDclient] <------------> |
                                 |
УК2::[FBclient <-> ZBDclient] <------------> | [тырнет]   <---------> СЕРВЕР::[ZBD3 <client> FB]
                                 |
УК3::[FBclient <-> ZBDclient] <------------> |

[Sla]

но не так

УК1::[FBclient <-> ZBDclient] <------------> |                                      |<client> FB1]
                                 |
УК2::[FBclient <-> ZBDclient] <------------> | [тырнет]   <---------> СЕРВЕР::[ZBD3 |<client> FB2]
                                 |
УК3::[FBclient <-> ZBDclient] <------------> |                                      |<client> FB3]

[Алексей++]

эхъ. Ладно, когда займусь ближе к делу - там, видимо, и смогу всё понять сразу ))

но Ответ #96 - для меня самое то

[Oldy]

  Где нужно трафик сжать, по тырнету (+шифрование)или между серверами?

[Алексей++]

Oldy, у меня один сервер. Надо жать и шифровать между клиентом птицы и птицей (то есть между машиной-клиентом и машиной-сервером)

[Алексей++]

вопрос связан скорее  с птицей, поэтому тут

в общем, всплыло внезапно такое: к примеру, у меня сейчас в городе время  16:00 . На компе выставлен пояс Екатеринбург GMT+6 , на часах в трее, само собой, 16:00.

Сейчас:
   функция "current_time" в птичьем запросе возвращает 16:00
   функция WinAPI "GetlocalTime" возвращает 16:00

Меняем пояс в винде, к примеру, на GMT+7  (часы в трее автоматом стали 17:00)

Теперь:

   функция "current_time" в птичьем запросе возвращает 16:00 
   функция WinAPI "GetlocalTime" возвращает 17:00


а как заставить current_time возвращать правильно локальное время ?

[Kivals]

Алексей1153++, рестарт службы сервера птицы пробовал?

[Алексей++]

Kivals, а что, помогает ? ))  Попробую завтра

[Kivals]

Алексей1153++, первое, что пришло на ум
Второе, что может быть - у птицы timezone настраивается отдельно где-то в конфигурации

[Алексей++]

ну да, перезапуск птицы помогает

[Алексей++]

дано: таблица MESS_LOG  с 50000 записями , триггеров нет, индекс - поле MESSAGE_ID

выполняю запрос

Код:

DELETE FROM MESS_LOG WHERE MESSAGE_ID<=NNNNNNN

(в результате запроса удаляются все 50000 записей)

------ Performance info ------
Prepare time = 0ms
Execute time = 23s 640ms
Current memory = 930 952
Max memory = 1 289 352
Memory buffers = 2 048
Reads from disk to cache = 5 645
Writes from cache to disk = 2 536
Fetches from cache = 252 330

смущает долгое время выполнения - сама операция полминуты, плюс коммит ещё на полминуты

где тут могут быть подводные камни, либо что нужно подкрутить ?

Добавлено через 3 минуты и 8 секунд:
Это у меня на столе 50 тыс сообщения, а у клиентов больше! На машине клиентов полмиллиона сообщений удаляется 15 минут, если не врут.  Но я им  почему-то верю.  А это недопустимо долго.

Добавлено через 55 секунд:
пробовал "чистить" БД - полный бэкап/восстановление . Это не повлияло на время запроса и коммита

[Sla]

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

[Алексей++]

1) как это сделать ?
2) на отдельном (моём рабочем) компе никто больше не подцеплен к базе, кроме меня. Это тот самый режим ? или как ?

[Sla]

1) как это сделать ?
2) на отдельном (моём рабочем) компе никто больше не подцеплен к базе, кроме меня. Это тот самый режим ? или как ?

без понятия (я только предположил).
Может есть что-то типа  WITH LOCK

[Алексей++]

Код:

DELETE FROM MESS_LOG WHERE MESSAGE_ID<=6171788 with lock

нет, не понимает такого. И, насколько я понял,  with lock - это для select

[Sla]

Перед удалением отключить индекс, после удаления  включить

[Алексей++]

я уже находил такой совет в тырнете. Попробовал - нет изменений по времени

Добавлено через 29 секунд:
может быть в конфиге птицы что-то подправить ?

[RXL]

Леш, имеется индекс по полю MESSAGE_ID? Покажи его DDL.

[Алексей++]

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

код создания таблицы из IB Expert

Код:

/******************************************************************************/
/****                                Tables                                ****/
/******************************************************************************/
CREATE GENERATOR NEW_MESS_ID;

CREATE TABLE MESS_LOG (
    MESSAGE_ID            BIGINT NOT NULL,
    DMESSAGE              TIMESTAMP,
    MESS_TYPE             SMALLINT,
    NUA_TYPE              SMALLINT,
    COLOR                 SMALLINT,
    NOMER                 SMALLINT NOT NULL,
    RAZDEL                SMALLINT NOT NULL,
    USERID                SMALLINT,
    OPERID                SMALLINT,
    IS_QUITED             SMALLINT,
    AUTO_QUITED           SMALLINT,
    QUIT_DATE             TIMESTAMP,
    CANAL_NUMBER          SMALLINT,
    DATAWORD              INTEGER,
    POWER_LEVEL           VARCHAR(2),
    NEW_COD_X_MESS      SMALLINT,
    F_18_GUARDEDNOW       SMALLINT,
    TAGPOINTID32          INTEGER,
    QUIT_REASON           SMALLINT,
    CANALNUMBER_PER       SMALLINT,
    TYPEFOR_CLIENTFILTER  SMALLINT,
    TECH_SMS_COUNT        SMALLINT,
    NON_TECH_SMS_COUNT    SMALLINT,
    ADR_GUID_M4S          VARCHAR(32),
    CHOP_NUM_M4S          SMALLINT,
    DELTA_TIME_CHOP_M4S   INTEGER,
    GSM_SIG_LVL           SMALLINT default NULL
);

/******************************************************************************/
/****                               Indices                                ****/
/******************************************************************************/

CREATE UNIQUE DESCENDING INDEX PK_MESS_LOG ON MESS_LOG (MESSAGE_ID);


/******************************************************************************/
/****                               Triggers                               ****/
/******************************************************************************/

SET TERM ^ ;


/* Trigger: MESS_LOG_BI */
CREATE TRIGGER MESS_LOG_BI FOR MESS_LOG
ACTIVE BEFORE INSERT POSITION 0
as
 begin
  if (new.MESSAGE_ID is null)
   then new.MESSAGE_ID = gen_id(NEW_MESS_ID,1);
 end
^


SET TERM ; ^

[RXL]

1. Обязательно делать "DESCENDING"? Попробуй ASC.
2. FB понимает PK? Попробуй его.

[Dale]

Является ли поле MESSAGE_ID внешним ключом какой-либо таблицы?

[Алексей++]

RXL,
1 -  пробовал оба направления. Пробовал вообще без индекса. Результат один
2 -  не успел попробовать, на работе свет чикнули. Завтра попробую

Dale, "встроенные" ключи в той БД не используются, только "логические", то есть без поддержки СУБД

[RXL]

Что такое "логический ключ"?

[Dale]

Предлагаю эксперимент.

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

Если время то же - причина тормозов в самой СУБД (например, лог транзакций), укрощаем. Если нет - значит, какие-то связи между таблицами все же имеются, ищем их.

И вот это подозрительно:

я уже находил такой совет в тырнете. Попробовал - нет изменений по времени

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