Полное протоколировани запросов к MySQL - как? : MySQL & MariaDB

УКМ_эксплуатант_2 · █ 24.02.2016 16:13

УКМ4 версии 67СП3
В бд стандартного экпорта 4 есть таблицы shift_result. Заполнятся нормально. Как только запускается "что-то" в 1С-е - в этой таблице становится пусто.
По моим данным кроме 1С-ки этой БД больше никто не пользуется. А одинэсники пяткой в грудь стучат: ну ведь русским по белому написано только ЧИТАТЬ или ОБНОВЛЯТЬ.
Вопрос: как включить запись всех запросов к опрдленной БД? Медленные протоколировать умею. Хочу все.

Micle · █ 24.02.2016 16:25

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

УКМ_эксплуатант_2 · █ 24.02.2016 17:12

Включил логирование всех запросов.
log=/var/log/mysql/mysql.log # Лог всех SQL-запросов
Нашел запрос на делит

Осталось определить кто его посылает.
Ковыряю инет на анализатор лога..

XsevenBeta · █ 25.02.2016 10:31

Можно прямо в онлайне включать и выключать:
SET GLOBAL general_log = 'ON';
SET GLOBAL general_log = 'OFF';
SET GLOBAL general_log_file= 'd:/temp/mysql-query.log'

УКМ_эксплуатант_2 · █ 26.02.2016 12:31

Наковырял следующее:
поставил тригеры на BEFORE DELETE, BEFORE UPDATE, BEFORE INSERT
с содержанием:

SQL код:

 CREATE DEFINER = 'ПОЛЬЗВАТЕЛЬ'@'%' TRIGGER `shift_before_ins_tr` BEFORE INSERT ON `shift`
  FOR EACH ROW
BEGIN
insert into `tbl_log_delete` (u_ser,dt,tip) values (USER(),NOW(),"ins");
END;

(tip для каждого события свой)
ну и логирование запросов включил.
В таблице tbl_log_delete видно что пользователь 1С производит DELETE
Но вот лог запросов смутил:

Код:

160226 11:55:18	    251 Connect     ПОЛЬЗОВАТЕЛЬ 1С@ИМЯ_МАШИНЫ_С_1С on export_no_sh
		    251 Query       SET NAMES utf8
		    251 Query       SET character_set_results = NULL
		    251 Query       SET SQL_AUTO_IS_NULL = 0
		    251 Query       set @@sql_select_limit=DEFAULT
		    251 Query       SELECT
CAST(SUM(T1.
бла-бла-бла
T1.`ext_status`
FROM shift T1 
WHERE (T1.`ext_status` = 0)
		    251 Query       SELECT
T1.store,
бла-бла-бла
ORDER BY T1.`cash_id`, T1.id
		    251 Query       SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE
		    251 Query       SET AUTOCOMMIT=0
		    251 Query       DELETE FROM shift 
WHERE shift.`cash_id` = 15012001 AND shift.id = 1135
160226 11:55:19	    251 Query       DELETE FROM shift 
WHERE shift.`cash_id` = 15012001 AND shift.id = 1135
		    251 Query       INSERT INTO shift  (store,`cash_number`,`cash_id`,id,number,login,date,sale,return,cancel,`cancel_return`,`close_login`,`close_date`,`ext_status`) VALUES
('025','1','15012001','1135','1222','1474','2016-02-23 07:58:45','330703038.68','14820900.83','9753418.94','160810.14','1474','2016-02-23 23:08:19','1')
		    251 Query       ROLLBACK
		    251 Query       SET AUTOCOMMIT=1
		    251 Query       SELECT
бла-бла-бла

Видно, что 1С сначала делитит запись, потом вставляет, НО ПОТОМ!!! делает откат транзакции!

Вопрос: сие является признаком того, что "виноват" в "пустой таблице" одинэс? Ведь сам смотрел исходники на чистом русском: нет слова УДАЛИТЬ!
Ну и как это можно попробовать исправить?
З.Ы. И че смотрел смотрел исходники - там можно было написать все что угодноо: я ж по 1С читать не умею

З.З.Ы. Попытался "завернуть" лог в спойлер - запросил какую-то опцию. Что это?

Mtirt · █ 26.02.2016 12:40

Так запросы в 1С обычным текстом, обычно.

УКМ_эксплуатант_2 · █ 26.02.2016 12:53

Цитата:

Mtirt ➤ Так запросы в 1С обычным текстом, обычно.

эээ, а подробнее?

В результате экспериментов выяснил следующее:
закопипастил эти запросы (от connect до set autocommit=1)
в EMS MySQL Manager
и на выполнение запустил по одному.
Все до инсерта - сработало.
А вот инсерт - нет

Дает ошибку.
Добавил имя таблицы перед полем return - заработало!

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

З.Ы. Позвонил одинэсникам - запросами не пользуются. Создают объект (в разговоре упоминалось ODBC) и работают с таблицей как с объектом ( помню что при заполнении таблицы items БД стандартного импорта 4 им пришлось явно указывать ВСЕ поля, а я в запросе - только те, которые нужны). ВНИМАНИЕ: сии слова я пишу без понимания их

Примерно догадываюсь, но не уверен....

vdm · █ 26.02.2016 15:27

Таблицы этого конвертера наверняка MyISAM, т.е. commit/rollback им побоку, изменения фиксируются сразу. Возможно где-то проскакивает DELETE без условий.

Ошибка на имени поля return - а в обратные апострофы `return` заключить не помогает?

Mtirt · █ 26.02.2016 15:33

У меня нескромный вопрос: а зачем 1С-никам что-то делать в базе УКМ4?
Можно их отправить лесом?

УКМ_эксплуатант_2 · █ 29.02.2016 08:33

Дык это-ж таблицы конвертера обмена!
Все по правилам: поля с именем начинающиеся с "ext_" - для внешних программ и можно делать с ними что угодно.
По этому полю 1С-ка ориентируется: обработанна запись или нет (при появлении данных там NULL, после того как 1С обработала запись - 1. Почему так - не спрашивайте, НЕЗНАЮ. Дал одинэсникам описание конвертера - получил такие проблемы

)
Надо было давать Стандартный 2DBF. Хотя, не прокатило-бы - самая актуальная информация - в Стандартном экспорте 4 (ну не актуальная - полная)....