CR_UNKNOWN_ERROR
Моя программа сохраняет в базу некоторые данные. При возникновении ошибки, я сохраняю инфу в лог файл (запрос и тип ошибки). И я стал замечать, что чем больше база, чем больше интенсивность запросов, тем больше появляется ошибок и в следствие чего меньше данных попадает в базу. Кончик лог-файла:
Err: Произошла неизвестная ошибка.
Req: SELECT `key` FROM `equip` WHERE `weapon_id`=4737 AND `weapon_ench` LIKE '+0' AND `body_id`=5942 AND `body_ench` LIKE '+0' AND `hands_id`=6675 AND `hands_ench` LIKE '+3' AND `lags_id`=5942 AND `lags_ench` LIKE '+0' AND `feet_id`=5942 AND `feet_ench` LIKE '+0' AND `head_id`=6675 AND `head_ench` LIKE '+3' AND `shield_id`=-1 AND `shield_ench` LIKE '+0' AND `antik_id`=-1 AND `antik_ench` LIKE '+0';
Err: Произошла неизвестная ошибка.
Req: INSERT INTO `rf_cheats2_bash`.`equip` SET weapon_id=9460, weapon_ench='+0', body_id=7173, body_ench='+0', hands_id=7173, hands_ench='+0', lags_id=7173, lags_ench='+0', feet_id=7173, feet_ench='+0', head_id=7488, head_ench='+0', shield_id=403, shield_ench='+0', antik_id=11, antik_ench='+0';
Err: Произошла неизвестная ошибка.
Req: SELECT `key` FROM `equip` WHERE `weapon_id`=9460 AND `weapon_ench` LIKE '+0' AND `body_id`=7173 AND `body_ench` LIKE '+0' AND `hands_id`=7173 AND `hands_ench` LIKE '+0' AND `lags_id`=7173 AND `lags_ench` LIKE '+0' AND `feet_id`=7173 AND `feet_ench` LIKE '+0' AND `head_id`=7488 AND `head_ench` LIKE '+0' AND `shield_id`=403 AND `shield_ench` LIKE '+0' AND `antik_id`=11 AND `antik_ench` LIKE '+0';
Err: Произошла неизвестная ошибка.
Req: INSERT INTO `rf_cheats2_bash`.`guilds` SET id=1295, name='Invasion', server=48;
Err: Произошла неизвестная ошибка.
Req: INSERT INTO `rf_cheats2_bash`.`equip` SET weapon_id=8412, weapon_ench='+0', body_id=6679, body_ench='+3', hands_id=4672, hands_ench='+0', lags_id=4672, lags_ench='+0', feet_id=6679, feet_ench='+0', head_id=4635, head_ench='+2', shield_id=415, shield_ench='+2', antik_id=0, antik_ench='+0';
Err: Произошла неизвестная ошибка.
Req: SELECT `key` FROM `equip` WHERE `weapon_id`=8412 AND `weapon_ench` LIKE '+0' AND `body_id`=6679 AND `body_ench` LIKE '+3' AND `hands_id`=4672 AND `hands_ench` LIKE '+0' AND `lags_id`=4672 AND `lags_ench` LIKE '+0' AND `feet_id`=6679 AND `feet_ench` LIKE '+0' AND `head_id`=4635 AND `head_ench` LIKE '+2' AND `shield_id`=415 AND `shield_ench` LIKE '+2' AND `antik_id`=0 AND `antik_ench` LIKE '+0';
Код ошибки - CR_UNKNOWN_ERROR
Все запросы совершенно правильные. Каждый из них я пробовал использовать вручную через phpmyadmin и они успешно выполнялись. А тут с разными данные разные запросы возвращают одинаковую ошибку периодически (всё чаще и чаще по мере увеличения базы).
Так вот вопрос:
1. какие вероятные причины могут быть?
2. как можно узнать причину? Как-то расшифровать точнее что за ошибка?
Err: Произошла неизвестная ошибка.
Req: SELECT `key` FROM `equip` WHERE `weapon_id`=4737 AND `weapon_ench` LIKE '+0' AND `body_id`=5942 AND `body_ench` LIKE '+0' AND `hands_id`=6675 AND `hands_ench` LIKE '+3' AND `lags_id`=5942 AND `lags_ench` LIKE '+0' AND `feet_id`=5942 AND `feet_ench` LIKE '+0' AND `head_id`=6675 AND `head_ench` LIKE '+3' AND `shield_id`=-1 AND `shield_ench` LIKE '+0' AND `antik_id`=-1 AND `antik_ench` LIKE '+0';
Err: Произошла неизвестная ошибка.
Req: INSERT INTO `rf_cheats2_bash`.`equip` SET weapon_id=9460, weapon_ench='+0', body_id=7173, body_ench='+0', hands_id=7173, hands_ench='+0', lags_id=7173, lags_ench='+0', feet_id=7173, feet_ench='+0', head_id=7488, head_ench='+0', shield_id=403, shield_ench='+0', antik_id=11, antik_ench='+0';
Err: Произошла неизвестная ошибка.
Req: SELECT `key` FROM `equip` WHERE `weapon_id`=9460 AND `weapon_ench` LIKE '+0' AND `body_id`=7173 AND `body_ench` LIKE '+0' AND `hands_id`=7173 AND `hands_ench` LIKE '+0' AND `lags_id`=7173 AND `lags_ench` LIKE '+0' AND `feet_id`=7173 AND `feet_ench` LIKE '+0' AND `head_id`=7488 AND `head_ench` LIKE '+0' AND `shield_id`=403 AND `shield_ench` LIKE '+0' AND `antik_id`=11 AND `antik_ench` LIKE '+0';
Err: Произошла неизвестная ошибка.
Req: INSERT INTO `rf_cheats2_bash`.`guilds` SET id=1295, name='Invasion', server=48;
Err: Произошла неизвестная ошибка.
Req: INSERT INTO `rf_cheats2_bash`.`equip` SET weapon_id=8412, weapon_ench='+0', body_id=6679, body_ench='+3', hands_id=4672, hands_ench='+0', lags_id=4672, lags_ench='+0', feet_id=6679, feet_ench='+0', head_id=4635, head_ench='+2', shield_id=415, shield_ench='+2', antik_id=0, antik_ench='+0';
Err: Произошла неизвестная ошибка.
Req: SELECT `key` FROM `equip` WHERE `weapon_id`=8412 AND `weapon_ench` LIKE '+0' AND `body_id`=6679 AND `body_ench` LIKE '+3' AND `hands_id`=4672 AND `hands_ench` LIKE '+0' AND `lags_id`=4672 AND `lags_ench` LIKE '+0' AND `feet_id`=6679 AND `feet_ench` LIKE '+0' AND `head_id`=4635 AND `head_ench` LIKE '+2' AND `shield_id`=415 AND `shield_ench` LIKE '+2' AND `antik_id`=0 AND `antik_ench` LIKE '+0';
Код ошибки - CR_UNKNOWN_ERROR
Все запросы совершенно правильные. Каждый из них я пробовал использовать вручную через phpmyadmin и они успешно выполнялись. А тут с разными данные разные запросы возвращают одинаковую ошибку периодически (всё чаще и чаще по мере увеличения базы).
Так вот вопрос:
1. какие вероятные причины могут быть?
2. как можно узнать причину? Как-то расшифровать точнее что за ошибка?
Раз phpmyadmin то субд по-видимому MySQL?
В нем я к сожалению не специалист, но, первое что приходит в голову, если количество ошибок возрастает пропорционально нагрузке, это взаимоблокировки... Ну и конечно если база интенсивно растет, то я бы посмотрел, справляется ли железо с этим.
В нем я к сожалению не специалист, но, первое что приходит в голову, если количество ошибок возрастает пропорционально нагрузке, это взаимоблокировки... Ну и конечно если база интенсивно растет, то я бы посмотрел, справляется ли железо с этим.
Цитата: SomewherSomehow
Раз phpmyadmin то субд по-видимому MySQL?
В нем я к сожалению не специалист, но, первое что приходит в голову, если количество ошибок возрастает пропорционально нагрузке, это взаимоблокировки... Ну и конечно если база интенсивно растет, то я бы посмотрел, справляется ли железо с этим.
В нем я к сожалению не специалист, но, первое что приходит в голову, если количество ошибок возрастает пропорционально нагрузке, это взаимоблокировки... Ну и конечно если база интенсивно растет, то я бы посмотрел, справляется ли железо с этим.
у меня вебхостинг и база относительно небольшая (на этом же хостинге висит база в 700мб и всё ок). Может быть проблема в том, что я часто запросы шлю? Ну в смысле между ними может какой-нибудь sleep воткнуть?
Есть ещё другая версия.. дело в том, что я впервые работаю с базой. Исходя из того, что ВСЕ ЭТИ запросы вручную отлично прокатывают, может проблема в коде или логике работы моей программы? Отсюда следующие вопросы:
1. между рядом запросов нужно ставить какие-то задержки? слипы? У меня идёт INSERT новых данных в таблицу, после чего их SELECT с целью получить номер этой записи. Затем новый инсерт в другую таблицу с полученным номером. Может паузу какую-то делать между каждым запросом?
2. далее моя программа, которая общается с базой, после запуска подключается к базе и так и висит подключённая к ней. Может надо реконнекты делать периодически? Или реконнектиться после возникновения таких ошибок? Или какие команды периодически надо посылать?
3. для всех столбцов таблицы 'equip' создан unique индекс, потому что не может быть двух записей с одинаковыми ячейками. Такое ощущение, что ошибка возникает при добавлении уже существующей записи... но не понятно ,почему после ошибки также ошибка возникает при запросе SELECT. Как вообще индексы на это влиять могут?
1. между рядом запросов нужно ставить какие-то задержки? слипы? У меня идёт INSERT новых данных в таблицу, после чего их SELECT с целью получить номер этой записи. Затем новый инсерт в другую таблицу с полученным номером. Может паузу какую-то делать между каждым запросом?
2. далее моя программа, которая общается с базой, после запуска подключается к базе и так и висит подключённая к ней. Может надо реконнекты делать периодически? Или реконнектиться после возникновения таких ошибок? Или какие команды периодически надо посылать?
3. для всех столбцов таблицы 'equip' создан unique индекс, потому что не может быть двух записей с одинаковыми ячейками. Такое ощущение, что ошибка возникает при добавлении уже существующей записи... но не понятно ,почему после ошибки также ошибка возникает при запросе SELECT. Как вообще индексы на это влиять могут?
Вообще, для взаимоблокировки достаточно и двух неудачно написанных запросов.
Но взаимоблокировки - это просто моя гипотеза, которая первая пришла в голову, когда вы упомянули о зависимости количества ошибок от интенсивности использования. На самом деле причина преспокойно может быть и в другом.
1. слипы ставить не надо. Вы же не хотите намеренно замедлить работу пользователям? Все должно работать и так. Нет ничего страшного делать вставку и потом выборку сразу. Если конечно у вас не происходит при этом одновременный доступ к одной таблице разных запросов и как следствие блокировка. Если приложение написано хорошо - этого быть не должно.
2. Я обычно использую прицип "доступ к отсоединенным данным" копипаста с PDF самоучителя подготовик к сертификационным экзаменам microsoft
Но взаимоблокировки - это просто моя гипотеза, которая первая пришла в голову, когда вы упомянули о зависимости количества ошибок от интенсивности использования. На самом деле причина преспокойно может быть и в другом.
1. слипы ставить не надо. Вы же не хотите намеренно замедлить работу пользователям? Все должно работать и так. Нет ничего страшного делать вставку и потом выборку сразу. Если конечно у вас не происходит при этом одновременный доступ к одной таблице разных запросов и как следствие блокировка. Если приложение написано хорошо - этого быть не должно.
2. Я обычно использую прицип "доступ к отсоединенным данным" копипаста с PDF самоучителя подготовик к сертификационным экзаменам microsoft
Цитата:
Прежние технологии доступа к данным по умолчанию обеспечивали доступ к дан-
ным через постоянное соединение с источником. В подобной модели приложение
открывает соединение с БД и не закрывает его до завершения работы приложения
или по крайней мере до завершения работы с источником данных. По мере роста
сложности приложений число клиентов, обслуживаемых БД, неуклонно возраста-
ет, при этом технология доступа к данным, использующая постоянное соединение,
становится неудобной в силу следующих причин:
• поддержание соединения с БД «накладно» с точки зрения использования сис-
темных ресурсов: чем больше открытых соединений приходится поддерживать,
тем ниже производительность системы;
• приложения, использующие доступ к данным через постоянное соединение,
очень плохо масштабируются. Такое приложение хорошо обслуживает соеди-
нения с двумя клиентами, с трудом справляется с 10 и совершенно не годится
для 100.
В ADO.NET эти проблемы решаются использованием по умолчанию модели до-
ступа на основе отсоединенных данных. В этой модели соединение с источником
данных открыто только до завершения необходимых действий над данными. На-
пример, если приложение запрашивает данные из БД, соединение устанавливается
только на время загрузки данных, после чего сразу же закрывается, Аналогично при
обновлении БД соединение открывается на время исполнения команды UPDATE,
а затем закрывается. Поддерживая соединения открытыми в течение минимально
необходимого времени, ADO.NET экономно использует системные ресурсы и по-
зволяет масштабировать инфраструктуру доступа к данным —производительность
снижается при этом незначительно.
ным через постоянное соединение с источником. В подобной модели приложение
открывает соединение с БД и не закрывает его до завершения работы приложения
или по крайней мере до завершения работы с источником данных. По мере роста
сложности приложений число клиентов, обслуживаемых БД, неуклонно возраста-
ет, при этом технология доступа к данным, использующая постоянное соединение,
становится неудобной в силу следующих причин:
• поддержание соединения с БД «накладно» с точки зрения использования сис-
темных ресурсов: чем больше открытых соединений приходится поддерживать,
тем ниже производительность системы;
• приложения, использующие доступ к данным через постоянное соединение,
очень плохо масштабируются. Такое приложение хорошо обслуживает соеди-
нения с двумя клиентами, с трудом справляется с 10 и совершенно не годится
для 100.
В ADO.NET эти проблемы решаются использованием по умолчанию модели до-
ступа на основе отсоединенных данных. В этой модели соединение с источником
данных открыто только до завершения необходимых действий над данными. На-
пример, если приложение запрашивает данные из БД, соединение устанавливается
только на время загрузки данных, после чего сразу же закрывается, Аналогично при
обновлении БД соединение открывается на время исполнения команды UPDATE,
а затем закрывается. Поддерживая соединения открытыми в течение минимально
необходимого времени, ADO.NET экономно использует системные ресурсы и по-
зволяет масштабировать инфраструктуру доступа к данным —производительность
снижается при этом незначительно.
Но это ADO.NET с MySql ситуация может быть и другая...но мне кажется всерно не очень правильным держать соединение постоянно открытым. Если конечно работает только один экземпляр программы, то может и ничего страшного...
3. Я бы вообще посоветовал присмотреться к ошибке поподробнее. Воспользоваться для этого профилировщиком. Если база на веб-хостинге и нет возможности использовать профилировщик, то может быть развернуть у себя на машине тестовую базу и на ней попытаться воспроизвести?.. Если это база выдает такую ошибку - это одно (я так думаю если б это было из-за уже добавленной записи, мускуль прям так бы об этом и сказал?), а если эта ошибка просто маскирует какую-то ошибку базы - другое. Короче, подробностей не хватает, имхо.
Спасибо за помощь. Вроде исправил проблему, но не понял её сути.
Программа была устроена так:
1. она через INSERT добавляла данные в базу, которые заведомо в ней уже могут быть (при этом все элементы данной таблицы имеют общий unique индекс, чтобы дублей не было)
2. затем через SELECT из этой таблицы вытаскивет номер добавленной записи
3. дальше уже ошибки не возникали..
Так вот я перед первым пунктом добавил проверку на существование добавляемой записи.. т.е. не стал надеятся на индексы. Ну и вроде как ошибка пропала. Соответственно её вызывают мои попытки добавить уже существующую запись. И мало того, если ошибка возникает, то и остальные запросы (даже SELECT) тоже начинают её возвращать. Непонятный глюк, но репцепт нашёл. Спасибо!
Программа была устроена так:
1. она через INSERT добавляла данные в базу, которые заведомо в ней уже могут быть (при этом все элементы данной таблицы имеют общий unique индекс, чтобы дублей не было)
2. затем через SELECT из этой таблицы вытаскивет номер добавленной записи
3. дальше уже ошибки не возникали..
Так вот я перед первым пунктом добавил проверку на существование добавляемой записи.. т.е. не стал надеятся на индексы. Ну и вроде как ошибка пропала. Соответственно её вызывают мои попытки добавить уже существующую запись. И мало того, если ошибка возникает, то и остальные запросы (даже SELECT) тоже начинают её возвращать. Непонятный глюк, но репцепт нашёл. Спасибо!
Совсем некрасивое решение. Начиная с того, что у вас получается идет select к таблице, чтобы проверить существование дубля, затем insert к ней, затем опять select, чтобы получить id только что вставленной записи. И заканчивая, что в многопользовательской среде между 1-м select и insert кто-то другой вставит запись и вы опять получите, то что получали. Я бы обернул все в хранимую процедуру. Тогда бы все взаимодействие свелось к вызову этой ХП, которая бы возвращала идентификатор вставленной записи или ошибку, что есть дубликат, если СУБД сформировало исключение нарушения уникального ключа.