reshetnyakvkt | 2 Dec 10:50
Picon

delete from MON$ATTACHMENTS where MON$ATTACHMENTS.MON$ATTACHMENT_ID<>CURRENT_CONNECTION

Установлена ОС Mandriva 2009 x64, 9Гб оперативки, винты 160Гб.
До этого стоял *FirebirdSS-2.5.0.25946-ReleaseCandidate3.amd64* конструкция
отваливает все залипшие коннекты из текущей БД, а
далее и в цикле из всех
архивов. Работало безупречно:
>>>
  in AUTONOMOUS TRANSACTION
  do delete from MON$ATTACHMENTS where
MON$ATTACHMENTS.MON$ATTACHMENT_ID<>CURRENT_CONNECTION;
  --
  for
    select a_path from DYN_PATH_NAME_ARCH(null, 199901, 201110)
  into :PATH
  do begin
    IN AUTONOMOUS TRANSACTION
    DO BEGIN
      EXECUTE STATEMENT ('delete from MON$ATTACHMENTS'
        ||' where MON$ATTACHMENTS.MON$ATTACHMENT_ID<>CURRENT_CONNECTION')
        ON EXTERNAL :PATH AS USER 'SYSDBA' PASSWORD :PASS;
    END
  end
>>>
После установки *FirebirdSS-2.5.1.26351-0.amd64*, такая
конструкция валит
сервер наглухо. Приложения выполняющее этот запрос
висит не реагируя. Не
помогает service firebird restart, а также stop/start. Зависшего
процесса не
замечено. В логе firebird.log лишь несколько строк об
ошибках с номерами и
(Continue reading)

Dmitry Yemanov | 2 Dec 11:37

Re: delete from MON$ATTACHMENTS where MON$ATTACHMENTS.MON$ATTACHMENT_ID<>CURRENT_CONNECTION

02.12.2011 13:50, reshetnyakvkt пишет:

> До этого стоял *FirebirdSS-2.5.0.25946-ReleaseCandidate3.amd64*

Как был установлен? Из RPM или из tar.gz или собран и
установлен из сорцов?

> После установки *FirebirdSS-2.5.1.26351-0.amd64*

Как был установлен? Из RPM или из tar.gz или собран и
установлен из сорцов?

> такая конструкция валит
> сервер наглухо. Приложения выполняющее этот запрос
висит не реагируя

Так валит сервер или вешает коннект, выполняющий
запрос? Это совсем 
разные вещи. Как при этом себя чувствуют остальные коннекты?

> Это уже второй раз так случается и прослеживается закономерность.

Т.е. это выполнялось всего дважды и оба раза висло или
же выполнялось 
многократно, но висло всего дважды?

Какие права даны на каталог /tmp/firebird?

> Вопрос к разработчикам что происходит. Если
конструкция с
(Continue reading)

reshetnyakvkt | 2 Dec 12:05
Picon

Re: delete from MON$ATTACHMENTS where MON$ATTACHMENTS.MON$ATTACHMENT_ID<>CURRENT_CONNECTION

Во всех случаях сервер установлен из rpm. Старый
удалялся ч/з rpm -e, с
перезагрузкой оси.
Сама ось не висит, выполняет команды и т.д. А к серверу
firebird не
присоединится, все соединения уходят в никуда, т.е.
висят без ответа на
ошибку коннекта или другое.
Такой скипт после установки новой версии FB
выполнялся дважды оба раза с
печальным итогом.
Права на /tmp/firebird (rwx-rwx-__ [firebird/firebird]), вроде нормально.
Висят в нем 8 файлов суммарно 8мб.
Вот еще - на клиенте установлен снэпшот FB2.5.1.26353-0_win32.
Суммарный объем файлов баз к которым применяется
скрипт около 28Гб, могу
предположить что дело может быть в попытке поднять их
в память которой
только 8Гб, и сервер уходит в глубокий своппинг.
Хотя раньше такого не наблюдалось.
Не знаю что ещё добавить. Если скрипт работает у
других, то подожду
следущего раза и если ситуация повторится, буду
отслеживать кто виноват
пробуя с разными базами. Может отчленять по кускам.

--
View this message in context: http://firebird.1100200.n4.nabble.com/delete-from-MON-ATTACHMENTS-where-MON-ATTACHMENTS-MON-ATTACHMENT-ID-CURRENT-CONNECTION-tp4145993p4146299.html

Sent from the firebird-russian mailing list archive at Nabble.com.
Dmitry Yemanov | 2 Dec 12:18

Re: delete from MON$ATTACHMENTS where MON$ATTACHMENTS.MON$ATTACHMENT_ID<>CURRENT_CONNECTION

02.12.2011 15:05, reshetnyakvkt пишет:

> Во всех случаях сервер установлен из rpm. Старый
удалялся ч/з rpm -e, с
> перезагрузкой оси.
> Сама ось не висит, выполняет команды и т.д. А к серверу
firebird не
> присоединится, все соединения уходят в никуда, т.е.
висят без ответа на
> ошибку коннекта или другое.

А уже установленные на этот момент соединения
продолжают работать? Или 
тоже виснут наглухо? Или прибиваются скриптом перед
его подвисом?

> Такой скипт после установки новой версии FB
выполнялся дважды оба раза с
> печальным итогом.

А если убрать FOR-цикл с удаленным выполнением
запросов, т.е. гасить 
только коннекты к своей базе?

Если будет работать, то проблема не в MON$, а в коннектах к
другим 
базам, см. ниже.

> Вот еще - на клиенте установлен снэпшот FB2.5.1.26353-0_win32.

(Continue reading)

Khorsun Vlad | 2 Dec 12:19
Picon

Re: delete from MON$ATTACHMENTS where MON$ATTACHMENTS.MON$ATTACHMENT_ID<>CURRENT_CONNECTION

"reshetnyakvkt" ...

> Сама ось не висит, выполняет команды и т.д. А к серверу
firebird не
> присоединится, все соединения уходят в никуда, т.е.
висят без ответа на
> ошибку коннекта или другое.

    Бектрейс висячего процесса и копия лок-таблицы
могут пролить свет
на эту тайну

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

Tonal | 12 Dec 11:59
Picon
Favicon
Gravatar

Глюки в рекурсивном запросе

Наткнулся на такую глючу.
В запросе ниже, выдаётся разные результаты при
закомментированном и
раскомментированном group by, хотя вроде бы должны быть одинаковые.

with recursive
SYM as (
  select sr1.ID, sr1.PARENT_ID
  from SYMPTOMS sr1
  --group by 1, 2
),
TREE as (
  select 1 as LEV, sp.ID, sp.PARENT_ID
  from SYM sp where sp.ID = 450797
  union all
  select t.LEV + 1, st.ID, st.PARENT_ID
  from SYM st inner join TREE t on st.PARENT_ID = t.ID
)
select
  t.LEV, t.ID
from TREE t

Или меня опять подводит мой «здравый смысл»?
Пример возник из попытки написать проверку
некоторого условия которое
зависит от родителей.
Т. е. SYM предполагался довольно сложным - вычисляющим
данные для этого
условия.

(Continue reading)

Khorsun Vlad | 12 Dec 15:01
Picon

Re: Глюки в рекурсивном запросе

"Tonal" ...
> Наткнулся на такую глючу.
> В запросе ниже

    Хорошо бы, чтобы DLL мог выполниться. На новой пустой БД.

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

PS http://tracker.firebirdsql.org/browse/CORE-3683 - не оно ? 

Tonal | 13 Dec 05:12
Picon
Favicon
Gravatar

Re: Глюки в рекурсивном запросе

12.12.2011 21:01, Khorsun Vlad пишет:
> "Tonal" ...
>> Наткнулся на такую глючу.
>    Хорошо бы, чтобы DLL мог выполниться. На новой пустой БД.
--DDL:
CREATE DOMAIN D_ID AS integer NOT NULL;
CREATE DOMAIN D_ID_OR_NULL AS integer;

CREATE TABLE SYMPTOMS (
  ID D_ID,
  PARENT_ID D_ID_OR_NULL,
  CONSTRAINT PK_SYMPTOMS PRIMARY KEY (ID),
  CONSTRAINT FK_SYMP2SYM_ID FOREIGN KEY (PARENT_ID) REFERENCES SYMPTOMS (ID)
);

--Datas
INSERT INTO SYMPTOMS (ID, PARENT_ID) VALUES ('450797', null);
INSERT INTO SYMPTOMS (ID, PARENT_ID) VALUES ('450798', '450797');
INSERT INTO SYMPTOMS (ID, PARENT_ID) VALUES ('450799', '450798');
INSERT INTO SYMPTOMS (ID, PARENT_ID) VALUES ('450800', '450798');
INSERT INTO SYMPTOMS (ID, PARENT_ID) VALUES ('450801', '450797');
INSERT INTO SYMPTOMS (ID, PARENT_ID) VALUES ('450802', '450801');
INSERT INTO SYMPTOMS (ID, PARENT_ID) VALUES ('450803', '450801');
INSERT INTO SYMPTOMS (ID, PARENT_ID) VALUES ('645590', '450797');
INSERT INTO SYMPTOMS (ID, PARENT_ID) VALUES ('645591', '645590');
INSERT INTO SYMPTOMS (ID, PARENT_ID) VALUES ('645592', '645590');
INSERT INTO SYMPTOMS (ID, PARENT_ID) VALUES ('645593', '645592');

> PS http://tracker.firebirdsql.org/browse/CORE-3683 - не оно ?
Похоже. Только в моём случае создание уникальности
(Continue reading)

Tonal | 13 Dec 05:30
Picon
Favicon
Gravatar

Re: Глюки в рекурсивном запросе

Ещё странность на похожем запросе:
Добавим в корневой подзапрос неименованную
вычисляемую колонку
with recursive
SYM as (
  select sr1.ID, sr1.PARENT_ID, count(*) --  Добавили count(*)
  from SYMPTOMS sr1
  group by 1, 2
),
TREE as (
  select 1 as LEV, sp.ID, sp.PARENT_ID
  from SYM sp where sp.ID = 450797
  union all
  select t.LEV + 1, st.ID, st.PARENT_ID
  from SYM st inner join TREE t on st.PARENT_ID = t.ID
)
select
  t.LEV, t.ID
from TREE t

Получаем ошибку:
Message: isc_dsql_prepare failed

SQL Message : -104
Invalid token

Engine Code    : 335544569
Engine Message :
Dynamic SQL Error
SQL error code = -104
(Continue reading)

Dmitry Yemanov | 13 Dec 07:54

Re: Глюки в рекурсивном запросе

13.12.2011 8:30, Tonal пишет:

> Вроде бы не было ограничений про неименованные
вычисляемые поля в
> подзапросах.
> Или я опять что-то пропустил?

В derived table все столбцы должны быть именованы, так
всегда было.

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


Gmane