@dba_ru

Страница 498 из 718

Vasiliy

05.05.2018
07:41:10

select table_name from information_schema.KEY_COLUMN_USAGE where table_schema = 'my_database' and referenced_table_name = 'my_table_here';

Вот таким запросом найдешь таблицы, которые ссылаются на твою. Дальше alter ... drop foreign key или что-то типа

вряд ли это разовый косяк. Какой объем таблицы после удаления в строках?

Evgeniy

05.05.2018
07:42:49

в моих таблицах просто "primary key" (один, у одной таблицы) и key(один, у второй таблицы)

Google

Evgeniy

05.05.2018
07:44:54

вряд ли это разовый косяк. Какой объем таблицы после удаления в строках?

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

Denis

05.05.2018
07:46:49

Лучше сосредоточиться на логике приложения и потратить время на поиск бага там

Evgeniy

05.05.2018
07:47:28

Лучше сосредоточиться на логике приложения и потратить время на поиск бага там

я не разраб

приложение не мое

обращаться в т.п. пока тоже не могу, надо обновиться до текущей версии хотябы

Vasiliy

05.05.2018
07:48:39

Удаление сейчас идет?

Evgeniy

05.05.2018
07:49:01

Удаление сейчас идет?

остановил, чтобы эти констрейны проверить и убрать индексы

Vasiliy

05.05.2018
07:49:43

Тогда заодно сделай select count(*) from table и select count(*) from table where <условие для удаления>

Evgeniy

05.05.2018
07:50:17

Тогда заодно сделай select count(*) from table и select count(*) from table where <условие для удаления>

всего там 1,5 млрд строк примерно.

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

можно запустить и посчитать, но что это даст?

Denis

05.05.2018
07:52:50

Удаляя индексы есть скрипты их создания ?

Evgeniy

05.05.2018
07:53:09

select table_name from information_schema.KEY_COLUMN_USAGE where table_schema = 'my_database' and referenced_table_name = 'my_table_here';

у меня нет referenced_table_name

Google

Evgeniy

05.05.2018
07:53:39

только: rehash relocation_ops relocation_time requested_lock_id requesting_trx_id result_message

Удаляя индексы есть скрипты их создания ?

KEY history_uint_1 (itemid,clock) - этого недостаточно для воссоздания?

Denis

05.05.2018
07:55:13

Если очевидные то да

Vasiliy

05.05.2018
07:55:41

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

Evgeniy

05.05.2018
07:55:50

Если очевидные то да

PRIMARY KEY (itemid,clock)

это второй. по одному на каждую из двух таблиц

Vasiliy

05.05.2018
07:57:31

это второй. по одному на каждую из двух таблиц

в принципе да, этого хватит, руками сделаешь их

Evgeniy

05.05.2018
07:57:41

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

Vasiliy

05.05.2018
07:58:19

да, похоже на то

Denis

05.05.2018
07:58:24

Скорее всего данные появляются по той причине что механизм ттл не работает

Evgeniy

05.05.2018
07:58:25

короче бэкап есть. попробую вариант с удалением индексов

Скорее всего данные появляются по той причине что механизм ттл не работает

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

а если я индексы уберу это не сделает хуже? не будет полного сканирования на каждый запрос удаления?

DaichiRyuu

05.05.2018
09:39:05

Всем привет. Помогите пожалуйста разобраться с блокировкой PREEMPTIVE_OS_PIPEOPS. Ситуация следующая: - Имеется новый Win Server 2016 - На него поставил SQL Server 2016 - Перенес БД и jobs из SQL Server 2014 - В jobах используется команда xp_cmdshell bcp При запуске jobы с такой командой она обязательно блокируется и висит в ожидании непонятно чего и убить её помогает только перезагрузки сервера. Может есть какие-то настройки которые я не сделал или пропустил?

Dmitrii

05.05.2018
18:52:55

Всем привет. Пишу запрос такого вида: select * from xxx INTO OUTFILE 'maps_23.csv' FIELDS TERMINATED BY ',' ENCLOSED BY '"' LINES TERMINATED BY '\n'; А мне ругается таким образом: Error Code: 1290. The MySQL server is running with the --secure-file-priv option so it cannot execute this statement MySQL 5.5, локальный инстанс, стоит на OS X. в MySQL я новенький, помогите плиз. Кучу всего уже перепробовал. Писал в my.cnf строку secure-file-priv = "" - не помогло. При вызове SHOW VARIABLES LIKE "secure_file_priv" получаю 'secure_file_priv','NULL'

Надо писать в mysql директорию, там где база, рядом будет что-то типа files

Ilia

05.05.2018
19:16:23

Тебе больше поможет удаление индексов и отключение констрейтов

Ну, удаление индексов может и очень сильно навредить...

Vasiliy

06.05.2018
04:25:06

Ну, удаление индексов может и очень сильно навредить...

Это если просто удалить. А если удалить, а потом пересоздать?

Ilia

06.05.2018
04:58:23

Ничего не изменится

Это если просто удалить. А если удалить, а потом пересоздать?

Если ты удалишь индексы, которые твой запрос на удаление использовал, то запрос будет работать сильно медленнее. Если удалишь индекс, который твой запрос не использовал, то запрос будет работать не сильно быстрее. Я это имел в виду

Google

Vasiliy

06.05.2018
06:04:48

Если ты удалишь индексы, которые твой запрос на удаление использовал, то запрос будет работать сильно медленнее. Если удалишь индекс, который твой запрос не использовал, то запрос будет работать не сильно быстрее. Я это имел в виду

Судя по тому, что писал человек, у него проблемы с вводом-выводом. Удаление индекса может позволить снизить нагрузку за счёт отсутствия необходимости обновлять его при удалении

Shamil

06.05.2018
06:08:17

SET autocommit=0; SET unique_checks=0; SET foreign_key_checks=0; START TRANSACTION; ALTER TABLE db.my_table DISABLE KEYS; DELETE FROM... ALTER TABLE db.my_table ENABLE KEYS; COMMIT

Попробуй

Ilia

06.05.2018
06:20:15

DDL вне транзакций работает, что пробовать?

Dmitrii

06.05.2018
17:48:42

Обнаружил прикольную фичу в DataGrip. Работает по крайней мере с PostgreSQL с колонкой UUID. Если добавлять строку, и выделить курсором ячейку где должен быть UUID и просто нажать Ctrl+V (вставка) то оно сгенерирует в ячейку случайный UUID.

lost

06.05.2018
18:22:13

это определенно важная информация

Al

06.05.2018
18:44:18

это определенно важная информация

Ну так раньше то ты через запрос приложения это делал. А теперь можешь просто тыкать мышой в каждую строчку. Прогресс

lost

06.05.2018
18:45:11

оооо, осталось только начать использовать uuid в бд, ну и datagrip

Vladislav

06.05.2018
19:01:10

Датагрип прикольный

Чем больше его узнаю, тем больше он мне нравится

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

lost

06.05.2018
19:04:09

у него долгая синхронизация объектов и нет отладчика

Vladislav

06.05.2018
20:39:08

Отладчик, это вообще фантастика

lost

06.05.2018
20:40:00

Ну, он нужен. Иногда)

Vladislav

06.05.2018
20:40:34

Так он есть в паре приложений

lost

06.05.2018
20:41:09

Даа, есть, и обычно эти приложухи платформозависимые

А судя по роадмапу jetbrains для них этот пунктик далеко неприоритетный

Это просто немного разросшийся кусок intelij, который решили вынести в отдеьную ide

Anton

06.05.2018
20:43:04

Отладчик ещё ладно - не так много людей, которые используют. Но через такую жопу загрузку БД и синхрон написать - это ещё постараться надо

lost

06.05.2018
20:44:11

Кстати да, снимали slow_log на синхронизации схем datagrip - запрос на каждый объект бд. Это жепь.

Google

Vladislav

06.05.2018
20:56:44

Это вообще не понятно, зачем

Admin

ERROR: S client not available

Vladislav

06.05.2018
20:57:02

От этой синхронизации никакого толку

Anton

06.05.2018
20:58:45

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

lost

06.05.2018
21:08:56

От этой синхронизации никакого толку

Когда ты перезатираешь чей-то код неактуальным - это немного грустна

Vladislav

06.05.2018
21:09:13

Когда ты перезатираешь чей-то код неактуальным - это немного грустна

Датагрип не причем

Нефиг в прод лазить руками

lost

06.05.2018
21:10:43

Так это может быть и в тестовом энве :) но датагрип не виноват, инфа 146%)

Vladislav

06.05.2018
21:11:50

Ну как бы да

Просто надо уметь выстраивать процесс и использовать VCS

lost

06.05.2018
21:15:44

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

Anton

06.05.2018
21:15:53

Не все иде вы него умеют. @acromegale Успокойся, в этом чате сплошь идеалисты, у которых всё чётко, миграции, вся херня. Никогда нет необходимости отладки на проде и пр.

lost

06.05.2018
21:16:54

Только вот у пацанов из devart получилось написать нормальный инкрементальный синк, а у jetbrains нет. Я не хочу ждать по 10 минут чтобы получить актуальную схему бд. Пичалька.

Vladislav

06.05.2018
21:39:42

Не все иде вы него умеют. @acromegale Успокойся, в этом чате сплошь идеалисты, у которых всё чётко, миграции, вся херня. Никогда нет необходимости отладки на проде и пр.

Почему идеалисты. Я про реальный опыт говорю

Anton

06.05.2018
21:41:48

ну вот я тоже про реальный. Есть переросшие в нечто большее проекты с древней и написаной не под те задачи, которыми она сейчас занимается, архитектурой. И на таких вещах всякие VCS уже фиг применишь.. Непрерывную разработку кода в БД встречал?

Vladislav

06.05.2018
21:43:14

Встречал, рефактор и перевод проекта в нормальное русло. Если отказываетесь это делать, значит просто еще не дошли до точки кипения

Anton

06.05.2018
21:46:10

Полный рефактор - это полный отказ от развития продукта на катастрофически долгое время. Все ли могут это себе позволить в условия жёсткой конкуренции?

Да и "точка кипения" у всех разная. У кого-то уже скилл "Анархия - мать порядка" прокачен так, что по-другому себе ничего не представляет

Vladislav

06.05.2018
21:47:03

Как я сказал, вы не дошли до точки, когда поддерживать сложнее, чем разрабатывать

Anton

06.05.2018
21:48:13

"Сложнее" - вопрос скилла. И если скилл разработки в БД на фирме прокачан здоровски, почему это не использовать, захватывая долю рынка вместо приведения в порядок, пока возможно?

Google

Vladislav

06.05.2018
21:50:52

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

Отличное развитие бизнеса

Anton

06.05.2018
21:56:46

Ну, я про тчо изначально говорил выше. Тут у многих есть только 2 мнения "моё и неправильное". А на самом деле подходов к архитектуре может быть много, всё зависит от конкретной ситуации и стратегии развития

Evgeniy

07.05.2018
02:48:13

Ну, удаление индексов может и очень сильно навредить...

оно и навредило. удаление использовало индекс

а что будет, если я запрос напишу типа так: autocommit=0; delete from table where indexed_field<some_value; autocommit=1;

без commit после delete

Roma