А как сейчас с работой?
В смысле drop и create заново?
-----
Почти.
Ожидается развернутый ответ - какие условия надо соблюсти для дропа и с какими параметрами надо креатить.
Если это есть,то уже не безнадежно... чаще, увы, нету...
Чаще случается делете...
И DBA на это не ответил?
-----
Не-а... там молоденькая девочка просто дремала на стульчике для создания видимости массовки... да и шеф был сильно в загоне...
А может быть, что ваши предположения неправильные?
------
Может.
А от того что будет выяснено, что они не правильные, имплементация станет соответствовать спецификации?
Тут разговаривать надо с заказчиком
-----
И кто тебя туда пустит?
А может быть, что ваши предположения неправильные? Тут разговаривать надо с заказчиком, а не сразу бросаться выполнять все требования. И может даже дать посмотреть, действительно ли "перехватывается триггер".
Мурр не умеет разговаривать, он начинает визжать как баба. Или не как.
В смысле drop и create заново?
вроде для этого есть команда truncate table
Я бы побоялся делать drop и create
Вдруг какой constraint потом забуду
Да и в оракле drop+create не обернуть в транзакцию вроде, то есть в какой-то момент времени таблица вообще не будет существовать и где-то что-то может обвалиться.
Я бы побоялся
-----
Вопрос был - Как сделать быстро? - а не какие фобии у тебя имеются... 
в какой-то момент времени
-----
Ну так ожидаемо что ДБА скажет об условиях дропа и креата. Это же его прямая работа... если он об этом знает...
Затем и вопрос задается чтобы понять с каких позиций (уровня знаний, понимания) будет подход к решению.
есть команда truncate table
-----
Есть.
Мало того - правильно будет использовать именно ее.
Но! - будет медленнее чем дроп/креате - а спрашивалось - Как сделать быстро?
Если есть... то...
------
...не получится - не дадут дропать пока реляции не пусты.
Смотря какие реляции. Если там лишь внешние ключи - можно дропать. А если на саму таблицу ссылаются, то вопрос уже не просто в удалении таблицы, а в перегруппировке данных - нужны ли данные, которые ссылаются на удаляемую таблицу? Если нет - то удаляем сперва их. Если нужны - куда теперь их относить?
Т.е. опять всё сводится к тому, что вы не указали всех условий и добавляете понемногу в каждом ответе.
При условии, что база в монопольном режиме. Иначе лок можешь поймать.
Значит, нужно либо отключить базу на время проведения "ремонтных работ", либо должен быть механизм изоляции мест проведения ремонтных работ. Иногда целые сайты и даже системы мирового уровня отключают на перерыв ради подобных вещей. Чем мы хуже ФААНГов?
Вы к чему пытаетесь подвести? Что задача невыполнима в принципе, или нужно знать какой-то секрет, недоступный большинству, чтобы выполнить эту задачу? ))
Вариант не без недостатков - частности потом тайауты полезут - но в рамках поставленных условий - годный.
А вопрос по таймаутам идет вторым - Какие проблемы и почему надо ожидать после пересоздания таблицы?
Я не ДБА, ответил просто исходя из своих скудных знаний и чисто по логике вещей. Если там какие-то сложные индексы-хрениндыксы и прочие механизмы оптимизации, зависящие от наличия-отсутствия разных таблиц, то конечно удаление одной из них может повлиять на производительность. Но это тонкости каждой конкретной СУБД. Обычному даже "помидорчику без амбиций" знать это не особо надо - в крайнем случае просто зовётся ДБА или заказывается сторонняя консультация-экспертиза. Ну а чаще всего помидорчик просто углубляется в вопрос, а работодатель терпит, что чел, получающий по 80к в год ("без амбиций" же), неделю втыкает в тьюториалы без гарантии успеха.
Постоянно отслеживаете
------
Они - стабильны. И используются уже очень давно. Кое-что аж с 70-х...
И что, никто с фиксами туда не лезет, обновить чего-то, поправить, фичей добавить? - Скриптизёров бы вам туда заслать... ))
Ожидается развернутый ответ - какие условия надо соблюсти для дропа и с какими параметрами надо креатить.
Как "какими"? С точно такими же, с какими она была создана. Вам же нужна такая же таблица, но пустая? Берёте скрипт её создания и выполняете.
Только не надо щас про кучу специальных условий и костылей, описанных для данной СУБД и данной БД в примечаниях мелким шрифтом "как оно на самом деле работает". Для мудацких условий и решения будут соответствующие.
Тут разговаривать надо с заказчиком
-----
И кто тебя туда пустит?
Тогда костылим!.. Или надеемся на удачу нахождения "изящных решений". Выбор не велик.
А может быть, что ваши предположения неправильные? Тут разговаривать надо с заказчиком, а не сразу бросаться выполнять все требования. И может даже дать посмотреть, действительно ли "перехватывается триггер".Мурр не умеет разговаривать, он начинает визжать как баба. Или не как.
Нет, он сразу бросается выполнять требования заказчика, даже если они тупые странные. И ладно я - я никто и звать меня никак, на меня никто толком внимания не обращает - кодь себе и кодь. Правда, ожидают почему-то, что я буду довольно много самостоятельных решений принимать. Но то издержки... А тут - помидор помидоров, семизнак, глыба! А его тоже никто не слушает и никуда не пускает. Как с паршивым куском джуна обходятся! Мол, наши архитекторы-гении навалили дерьма, а твоё дело
за ними прибирать, костылики подставлять... Надо хотя бы пытаться вклиниться. Я вот пытался, меня три раза "послали", тогда я успокоился. Попробовал сам самостоятельно свой вариант - работает. Но им не надо быстро и просто. Ну и ... с ними. Главное, бабки платят. ))
не указали всех условий
-----
А должен?
Мне нужен не ответ - я его и так знаю.
К тому же ты не прав - я не меняю изначальных условий, а вот окружение отвечающий должен знать...
Вы к чему пытаетесь подвести?
-----
К тому что мне нужен - ответ от ДБА - т.е. ответ с указанием условий применимости в той мере в какой он их понимает.
Просто для того чтобы понять с кем предстоит взаимодействовать.
в крайнем случае просто зовётся ДБА
-----
Хи-хи...Вопрос и был адресован к тамошнему ДБА.
Я не ДБА
-----
Ну Я же тебе не задаю вопросов по базам...
И... если ты не заметил...то и по всему остальному чисто в порядке трепа общаюсь... хотя информацию "куда копать" иногда даю...
А уж как ты ее пользуешься - это уже чисто твое дело.
углубляется в вопрос
-----
Базы - вопрос достаточно специфический.
На уровне круд'а там все достаточно просто... но круд это менее 10% от серьезной базы и остаток надо изучать не неделю...
То, что я могу "поймать" в результате анализа лога... а еще надо вспомнить как его получить... нормальный ДБА сделает чуть ли не по словесному описанию проблемы от бабы Маши.
Но, блин, это же именно нормальный ДБА - его надо профильно учить в уни лет 5 и практиковать в экстремальных условиях лет 10-ть...при этом способных пройти обучение в уни порядка 3% от популяции, из них на ДБА пойдет учится и закончат какая-то тысячная процента, а на практике отсеются еще процентиков 95-97... Остальные будут стукать себя пяткой в грудь - Я ДБА - и сыпаться на элементарных, для сениоров кодеров или начинающих ДБА, вопросах - Как быстрее всего удалить все записи из большой таблицы?
никто с фиксами туда не лезет
-----
Не-а...
Хотя новые имплементации иногда создаются... недавно работал с досовским ФАТ из микроконтроллера.
С точно такими же, с какими она была создана.
-----
Ты снова демонстрируешь непонимание баз - дропаемая таблица может быть сильно далека от той которая создавалась.
Берёте скрипт её создания и выполняете.
-----
Можно, конечно, объяснить в деталях в чем будет разница, но... лучше ты об этом сам почитаешь когда оно тебе надо будет.
А простое пересоздание таблицы по начальному скрипту, если это не скрипт создания большой таблицы, вызовет проблемы - таймауты будут.
А со скриптом для большой таблицы - можешь и с местом можешь не угадать... у тебя ведь базы до сих пор однофайловые (в смысле - двухфайловые, но об втором ты не знаешь)... а у ДБА они должны быть сегментированы по физ.устройствам изначально...
Ну да это не критично...
Ну всё, старик взобрался на броневичок... Не обязательно на все посты отвечать )))
это не создаст полную копию схемы таблицы?
-----
Схему - да, но не таблицу. Какие будут проблемы тебе уже сказано - когда возникнут - вспомнишь и обдумаешь.
Так-то там ещё и лог где-то затесался.
-----
Да, второй файлик... можно на отдельный физ.диск вместе с виндовым свопом скинуть... немного быстрее будет...
Это и надёжность повысит, и скорость операций.
------
Когда сделаешь и все получится - приходи, расскажешь.
Не понял, вам нужно просто пустую таблицу сделать, аналогичную полной по схеме - дроп-криейт по скрипту создания текущей схемы. Плюс исходная ещё без связей.
Логи вообще имеют свойство разрастаться - это не только ДБ касается. Некоторые их просто дропают раз в месяц, скажем.
Это и надёжность повысит, и скорость операций.
------
Когда сделаешь и все получится - приходи, расскажешь.
Я не хочу быть ДБА. И мастером на все руки не хочу быть. Семь знаков мне всё равно за это не заплатят, а голова не резиновая и нервы не железные, чтобы всё это дерьмо помнить и разгребать. ))
А джойны с юнинами - там и кодеры справятся...
оно и видно, как ты на этом вопросе стал щёчки надувать.
Ну так ожидаемо что ДБА скажет об условиях дропа и креата. Это же его прямая работа... если он об этом знает...
это ты уже ходу придумываешь.
Не было указано, что операцию будет проводить ДБА в оговорённый downtime.
Есть.Мало того - правильно будет использовать именно ее.Но! - будет медленнее чем дроп/креате
с чего это Truncate вдруг стал медленнее?
на этом вопросе стал
-----
При этом надо бы указать где была допущена неточность...
Или хули лакли сойдет?
указано, что
-----
Опять - Я где-то это требую? - не-а...
А ожидаю Я ответа, который позволит оценить уровень навыков ДБА.
Мне годится любой ответ. Вообще любой. Даже классическое сельскохохлятское - ГА!?.
Так что если ДБА посчитал нужным родить делете в качестве ответа - меня ответ устроит, но с позиции ДБА чел будет помещен на уровень мид-левел девелопер и надо будет решать идти ли к нему в подчиненные... Но раз уж принято решение не связываться с шарагой принято до задания вопроса, то последний вопрос отпал.
с чего это Truncate вдруг стал медленнее?
-----
Проверь... и результат замеров в студию.