Очистить таблицу sql 1c
Ссылки на описание синтаксиса Transact-SQL для SQL Server 2014 и более ранних версий, см. в статье Документация по предыдущим версиям.
Аргументы
database_name | database_id | 0
База данных, которой принадлежит очищаемая таблица. Если указано значение 0, используется текущая база данных. Имена баз данных должны соответствовать правилам построения идентификаторов.
table_name | table_id | view_name | view_id
Очищаемая таблица или индексированное представление.
batch_size
Число строк, которые обрабатываются за одну транзакцию. Если не указано или указано значение 0, инструкция обрабатывает всю таблицу за одну транзакцию.
КБК. КВФО - Код вида финансового обеспечения (деятельности)
НПА: Приказ Минфина России от 01.12.2010 N 157н Письмо Минфина России от 18 января 2018 г. N 02-06-10/2715 В целях организации и ведения бухгалтерского учета, утверждения Рабочего плана счетов применяются следующие коды вида финансового обеспечения (деятельности): для государственных (муниципальных) учреждений, организаций, осуществляющих полномочия получателя бюджетных средств, финансовых органов соответствующих бюджетов и органов, осуществляющих их кассовое обслуживание: 1 - деятельность, осуществляемая за счет средств соответствующего бюджета бюджетной системы Российской Федерации (бюджетная деятельность); 2 - приносящая доход деятельность (собственные доходы учреждения); 3 - средства во временном распоряжении; 4 - субсидии на выполнение государственного (муниципального) задания; 5 - субсидии на иные цели; 6 - субсидии на цели осуществления капитальных вложений; 7 - средства по обязательному медицинскому страхованию; для отражения органами Федерального казн
Разрешения
Участник должен быть владельцем таблицы или индексированного представления либо членом предопределенной роли сервера sysadmin, предопределенной роли базы данных db_owner или предопределенной роли базы данных db_ddladmin.
Отказ от ответственности
Проверяйте, пожалуйста, текст скрипта перед выполнением. Понимайте, что делаете. Помните, что ответственность лежит целиком на Вас!
С особой внимательностью рекомендую проверять скрипт перед выполнением, если в Вашей базе есть случаи, когда период записей регистров отличается от даты регистратора.
Примеры
A. Использование инструкции DBCC CLEANTABLE для освобождения дискового пространства
В следующем примере выполняется инструкция DBCC CLEANTABLE для таблицы Production.Document в образце базы данных AdventureWorks2012.
Б. Использование инструкции DBCC CLEANTABLE и проверка результатов
В следующем примере создается таблица и заполняется несколькими столбцами переменной длины. Затем два столбца удаляются, а для освобождения неиспользуемого пространства выполняется инструкция DBCC CLEANTABLE. Запрос выполняется для проверки счетчиков страниц и пространства, используемого значениями до и после выполнения инструкции DBCC CLEANTABLE.
Remarks
Инструкция DBCC CLEANTABLE освобождает место на диске после удаления столбца переменной длины. Столбец переменной длины может иметь один из следующих типов данных: varchar, nvarchar, varchar(max) , nvarchar(max) , varbinary, varbinary(max) , text, ntext, image, sql_variant и xml. Дисковое пространство после удаления столбца фиксированной длины не освобождается. Если удаленные столбцы были сохранены в строке, инструкция DBCC CLEANTABLE освободит пространство из единицы распределения IN_ROW_DATA таблицы. Если столбцы были сохранены вне строк, пространство будет освобождено либо из единицы распределения ROW_OVERFLOW_DATA, либо из единицы распределения LOB_DATA, в зависимости от типа данных удаленного столбца. Если в результате освобождения пространства из страниц ROW_OVERFLOW_DATA или LOB_DATA была образована пустая страница, инструкция DBCC CLEANTABLE удалит эту страницу. Инструкция DBCC CLEANTABLE выполняется за одну или несколько транзакций. Если не указан размер пакета, команда обрабатывает всю таблицу за одну транзакцию, при этом на время обработки производится ее монопольная блокировка. Для некоторых больших таблиц длительности транзакции и необходимого размера журнала может оказаться недостаточно. Если указан размер пакета, команда выполняет серию транзакций, в каждой из которых обрабатывается указанное число строк. Инструкция DBCC CLEANTABLE не может выполняться в транзакции, вложенной в другую транзакцию. Эта операция выполняется с полной регистрацией. Инструкция DBCC CLEANTABLE не поддерживается для использования с системными таблицами, временными таблицами и с частью таблицы, относящейся к индексу columnstore с оптимизацией для памяти xVelocity.
Отказ от ответственности
Проверяйте, пожалуйста, текст скрипта перед выполнением. Понимайте, что делаете. Помните, что ответственность лежит целиком на Вас!
С особой внимательностью рекомендую проверять скрипт перед выполнением, если в Вашей базе есть случаи, когда период записей регистров отличается от даты регистратора.
ТФФ 33.0. Полный перечень документов альбома ТФФ (Таблица 2)
Особенности
- Доступна опция порционного удаления.
- На данный момент, обработка существует только для обычного приложения.
- Обработка сама не подключается в SQL и не запускает скрипт там на выполнение. Только формирует текст скрипта. Считаю, что скопировать-вставить нетрудно, а если нет навыков работы в SQL-студии, то и запускать подобное, возможно, рано.
- Исходный код открыт.
Устаревшая стратегия (альтернатива)
Первое решение, от которого я впоследствии отказался. Хотя вначале оно казалось более удобным и простым. А именно — очистить шапку. А потом все связанные таблицы поочередно, у кого нет "пары" в основной таблице (ссылка/регистратор = "битая" ссылка).
Данный вариант не работает для движений документа. Так как после удаления основной таблицы документа — IS NULL даёт истину после соединения таблицы движений регистра и основной таблицы документа в 2х случаях
- Когда действительно записи сделаны этим видом документа, и эти документы были удалены (тут всё хорошо)
- Когда записи были сделаны документами других видов, и в этом случае записи удаляются ошибочно (так нельзя!). Чтоб решить эту проблему надо связывать таблицу регистра со всеми возможными типами регистраторов, а это слишком сложно
Вобщем порядок был такой (отличия в пунктах 2 и 3)
- Удаляем записи регистров, которые двигает нужный вид документа, по связке с основной таблицей документа
- Удаляем основную таблицу документа
- Удаляем записи табличных частей документа, у которых Ссылка после соединения = IS NULL
- Остальное (как в основном варианте, журналы и регистрация изменений)
Но в процессе эксплуатации выяснилось, что удаление по пустой шапке на больших объёмах работает медленно, поэтому по умолчанию от данной стратегии пришлось отказаться (по крайней мере, на нашем примере), но эта опция по-прежнему доступна по соответствующей галочке на первой закладке.
Комментарии
Основная цель применения
Прикладная задача, в процессе решения которой родилась данная методика: свертка базы (ввод остатков, удаление документов и движений регистров в прошлых периодах). То есть: удаление документов (вместе с табличными частями, разумеется) до определённой даты, и их движений. Иногда обработка использовалась для удаления данных с более сложными условиями, но они менялись вручную уже в SQL-студии.
Порядок действий
При желании протестировать/посмотреть "что именно будет удаляться" предусмотрена соответствующая опция (галочка справа внизу), в этом случае скрипты будут формироваться с оператором SELECT, а не DELETE. Можно выделить нужный кусок, запустить на исполнение, посмотреть результаты, прежде чем запускать на удаление.
Самый простой способ (первый вариант) - выполнение оператора удаления записи. При его выполнении вы будете видеть результат (сколько записей удалено). Удобная штука когда необходимо точно знать и понимать правильные ли данные удалены. НО имеет недостатки перед другими вариантами решения поставленной задачи.
SQL> DELETE FROM msg WHERE date_create = '2019.02.01'; --Удалит все строки у которых дата создания "2019.02.01"
- Его нет в Firebird, поэтому пользуемся первым и третьим вариантом.
- После выполнения нельзя откатить транзакцию, так как это DML
- Ну и увидеть сколько реально записей было удалено не получится.
Ну и третий вариант, и он, пожалуй, самый жесткий быстрый - это удаление таблицы и повторное создание, с восстановлением всей структуры (PK, FK, index, и другое).
При необходимости, можно предварительно создать таблицу с данными которые нам нужны, после чего выполнить удаление:
- Получить ссылку
- Электронная почта
- Другие приложения
Теория
Варианты (операторы) удаления в SQL.
- DROP - полное удаление таблицы из структуры данных (вместе с данными). То есть очищаются не только данные, но и метаданные. Работает мгновенно.
- TRUNCATE - полная очистка таблицы с сохранением структуры таблицы (очищаются только строки таблицы, колонки остаются прежними). Работает мгновенно.
- DELETE - удаление записей в таблице по определенному условию. Занимает определенное время.
Оператором DROP на практике я почти не пользуюсь. TRUNCATE - иногда пригождается, когда по условию задачи возможно удалить всю таблицу (данные не нужны совсем, либо можно после удаления загрузить откуда-то только нужную часть). В остальных случаях (в том числе в рамках данной методики) используется DELETE.
Для того, чтоб удалить данные целостно по ряду связанных таблиц документа (шапка, ТЧ, движения) - сперва я рассматривал вариант честно отобрать данные документа по дате, а потом уже связать с другими таблицами через JOIN. То есть очистить поочередно все связанные таблицы, после чего удалить основную (так как только в ней есть реквизит, по которому решаем удалять объект или нет)
В итоге была выбрана и реализована следующая стратегия
- Удаляем движения регистров, которые двигает нужный вид документа, по связке с основной таблицей документа
- Удаляем строки табличных частей документа, по связке с основной таблицей документа
- Удаляем основную таблицу документа
- Очищаем целиком таблицы журналов, где участвует документ (нехорошо, но в нашем случае - не критично, можно и не трогать)
- Опционально можно очистить таблицы регистрации изменений для обмена
Таблиц много + названия неудобные + конструктора запросов нет = очень много рутины с высокой вероятностью ошибки и дороговизной ошибок. Поэтому был создан инструмент, берущий большую часть рутины на себя.
Результирующие наборы
Инструкция DBCC CLEANTABLE возвращает следующий результирующий набор.
Рекомендации
Инструкция DBCC CLEANTABLE не должна выполняться как задача регламентного обслуживания. Вместо этого используйте инструкцию DBCC CLEANTABLE после выполнения значительных изменений над столбцами переменной длины в таблице или индексированном представлении, если необходимо незамедлительно освободить неиспользуемое пространство. Кроме того, можно выполнить перестроение индексов таблицы или представления, однако это более ресурсоемкая операция.
Оператор DELETE стр. 1
Оператор DELETE удаляет строки из временных или постоянных базовых таблиц, представлений или курсоров, причем в двух последних случаях действие оператора распространяется на те базовые таблицы, из которых извлекались данные в эти представления или курсоры. Оператор удаления имеет простой синтаксис:
Если предложение WHERE отсутствует, удаляются все строки из таблицы или представления (представление должно быть обновляемым). Более быстро эту операцию (удаление всех строк из таблицы) можно в Transact-SQL (T-SQL) — процедурное расширение языка SQL, используемое для программирования на стороне сервера в Microsoft SQL Server и Sybase ASE. Transact-SQL также выполнить с помощью команды
Однако есть ряд особенностей в реализации команды TRUNCATE TABLE , которые следует иметь в виду:
- не журнализируется удаление отдельных строк таблицы; в журнал записывается только освобождение страниц, которые были заняты данными таблицы;
- не отрабатывают триггеры, в частности, триггер на удаление;
- команда неприменима, если на данную таблицу имеется ссылка по внешнему ключу, и даже если внешний ключ имеет опцию каскадного удаления.
- значение счетчика ( IDENTITY ) сбрасывается в начальное значение.
Требуется удалить из таблицы Laptop все портативные компьютеры с размером экрана менее 12 дюймов.
Все блокноты можно удалить с помощью оператора
Transact-SQL расширяет синтаксис оператора DELETE , вводя дополнительное предложение FROM :
При помощи источника табличного типа можно конкретизировать данные, удаляемые из таблицы в первом предложении FROM .
При помощи этого предложения можно выполнять соединения таблиц, что логически заменяет использование подзапросов в предложении WHERE для идентификации удаляемых строк. Поясним сказанное на примере.
Пусть требуется удалить те модели ПК из таблицы Product, для которых нет соответствующих строк в таблице PC.
Используя стандартный синтаксис, эту задачу можно решить следующим запросом:
Заметим, что предикат type = ‘pc’ необходим здесь, чтобы не были удалены также модели принтеров и портативных компьютеров.
Эту же задачу можно решить с помощью дополнительного предложения FROM следующим образом:
Особенности
- Доступна опция порционного удаления.
- На данный момент, обработка существует только для обычного приложения.
- Обработка сама не подключается в SQL и не запускает скрипт там на выполнение. Только формирует текст скрипта. Считаю, что скопировать-вставить нетрудно, а если нет навыков работы в SQL-студии, то и запускать подобное, возможно, рано.
- Исходный код открыт.
Предыстория
Проблема: свертка стандартными средствами происходила неприлично долго. Точней, именно этап удаления старых данных. Остатки вводятся быстро, а вот удаление движений регистров, пометка на удаление документов, само удаление — по нашим оценкам на наших объёмах (500ГБ) заняло бы недели.
Решение: удалить данные средствами SQL, чтоб миновать механизмы платформы 1С, ненужные при данной операции, но отнимающие драгоценное (в рамках данной задачи) время.
Препятствия: Данные в SQL хранятся в разных таблицах. Таблиц много, как их связать — не всегда понятно. То есть мало очистить сам документ (шапку), надо очистить также данные табличных частей, и движений документа. Движения по разным регистрам. Для одного документа регистров может быть много. Каждый регистр в свою очередь хранит данные также в нескольких таблицах. Наименования таблиц — неосмысленные.
Предыстория
Проблема: свертка стандартными средствами происходила неприлично долго. Точней, именно этап удаления старых данных. Остатки вводятся быстро, а вот удаление движений регистров, пометка на удаление документов, само удаление - по нашим оценкам на наших объёмах (500ГБ) заняло бы недели.
Решение: удалить данные средствами SQL, чтоб миновать механизмы платформы 1С, ненужные при данной операции, но отнимающие драгоценное (в рамках данной задачи) время.
Препятствия: Данные в SQL хранятся в разных таблицах. Таблиц много, как их связать - не всегда понятно. То есть мало очистить сам документ (шапку), надо очистить также данные табличных частей, и движений документа. Движения по разным регистрам. Для одного документа регистров может быть много. Каждый регистр в свою очередь хранит данные также в нескольких таблицах. Наименования таблиц - неосмысленные.
Теория
Варианты (операторы) удаления в SQL.
- DROP — полное удаление таблицы из структуры данных (вместе с данными). То есть очищаются не только данные, но и метаданные. Работает мгновенно.
- TRUNCATE — полная очистка таблицы с сохранением структуры таблицы (очищаются только строки таблицы, колонки остаются прежними). Работает мгновенно.
- DELETE — удаление записей в таблице по определенному условию. Занимает определенное время.
Оператором DROP на практике я почти не пользуюсь. TRUNCATE — иногда пригождается, когда по условию задачи возможно удалить всю таблицу (данные не нужны совсем, либо можно после удаления загрузить откуда-то только нужную часть). В остальных случаях (в том числе в рамках данной методики) используется DELETE.
Для того, чтоб удалить данные целостно по ряду связанных таблиц документа (шапка, ТЧ, движения) — сперва я рассматривал вариант честно отобрать данные документа по дате, а потом уже связать с другими таблицами через JOIN. То есть очистить поочередно все связанные таблицы, после чего удалить основную (так как только в ней есть реквизит, по которому решаем удалять объект или нет)
В итоге была выбрана и реализована следующая стратегия
- Удаляем движения регистров, которые двигает нужный вид документа, по связке с основной таблицей документа
- Удаляем строки табличных частей документа, по связке с основной таблицей документа
- Удаляем основную таблицу документа
- Очищаем целиком таблицы журналов, где участвует документ (нехорошо, но в нашем случае — не критично, можно и не трогать)
- Опционально можно очистить таблицы регистрации изменений для обмена
Таблиц много + названия неудобные + конструктора запросов нет = очень много рутины с высокой вероятностью ошибки и дороговизной ошибок. Поэтому был создан инструмент, берущий большую часть рутины на себя.
Как проверить содержимое таблицы
Если вы хотите убедиться, что в таблице не осталось данных, воспользуйтесь командой:
Вместо db_name введите имя базы данных, а вместо table_name введите имя таблицы.
В данной статье будет рассмотрена методика удаления данных запросом в MSSQL-студии.
Разница между TRUNCATE и DELETE
Команда TRUNCATE является оператором DDL. DDL (Data Definition Language) — это язык определения данных. Операторы языка DDL управляют объектами баз данных: удаляют, создают или переименовывают объекты БД.
Команда DELETE является DML-оператором. DML (Data Manipulation Language) — это язык манипуляции данными. Операторы языка DML позволяют вставить, удалить, изменить, извлечь или обновить данные в базе.
Сравним работу команд:
TRUNCATE | DELETE |
---|---|
Удаляет все данные из таблицы | Может удалить часть данных в соответствии с условием WHERE |
Удаляет все строки из таблицы освобождением страниц | Удаляет строки по одной |
Записывает в журнал транзакций сведения о каждой удалённой странице, а не строке | Делает запись в журнал транзакций при удалении каждой строки |
Работает быстрее | Работает медленнее |
Нужны привилегии ALTER | Нужны привилегии DELETE |
Сбрасывает идентификаторы | Не сбрасывает идентификаторы |
Блокирует таблицу и страницу перед удалением | Блокирует строку перед её удалением |
Выбор команды зависит от конкретного случая. Если нужно удалить некоторые строки по условию, подойдёт только DELETE. Если нужно полностью очистить таблицу и сбросить идентификаторы, используйте TRUNCATE.
Понять разницу между командами и определиться с их выбором поможет таблица с операторами каждого языка:
DDL | DML |
---|---|
CREATE | SELECT |
ALTER | INSERT |
DROP | UPDATE |
TRUNCATE | DELETE |
COMMENT | MERGE |
RENAME | CALL |
EXPLAIN PLAN | |
LOCK TABLE |
Таким образом, операторы DDL управляют структурой, а операторы DML — её содержимым.
Основная цель применения
Прикладная задача, в процессе решения которой родилась данная методика: свертка базы (ввод остатков, удаление документов и движений регистров в прошлых периодах). То есть: удаление документов (вместе с табличными частями, разумеется) до определённой даты, и их движений. Иногда обработка использовалась для удаления данных с более сложными условиями, но они менялись вручную уже в SQL-студии.
Устаревшая стратегия (альтернатива)
Первое решение, от которого я впоследствии отказался. Хотя вначале оно казалось более удобным и простым. А именно - очистить шапку. А потом все связанные таблицы поочередно, у кого нет "пары" в основной таблице (ссылка/регистратор = "битая" ссылка).
Данный вариант не работает для движений документа. Так как после удаления основной таблицы документа - IS NULL даёт истину после соединения таблицы движений регистра и основной таблицы документа в 2х случаях
- Когда действительно записи сделаны этим видом документа, и эти документы были удалены (тут всё хорошо)
- Когда записи были сделаны документами других видов, и в этом случае записи удаляются ошибочно (так нельзя!). Чтоб решить эту проблему надо связывать таблицу регистра со всеми возможными типами регистраторов, а это слишком сложно
Вобщем порядок был такой (отличия в пунктах 2 и 3)
- Удаляем записи регистров, которые двигает нужный вид документа, по связке с основной таблицей документа
- Удаляем основную таблицу документа
- Удаляем записи табличных частей документа, у которых Ссылка после соединения = IS NULL
- Остальное (как в основном варианте, журналы и регистрация изменений)
Но в процессе эксплуатации выяснилось, что удаление по пустой шапке на больших объёмах работает медленно, поэтому по умолчанию от данной стратегии пришлось отказаться (по крайней мере, на нашем примере), но эта опция по-прежнему доступна по соответствующей галочке на первой закладке.
Таблицы в Oracle. Количество записей, размер таблицы
-- **************************************************************** -- выводим количество записей по таблицам -- **************************************************************** -- Требуется выполнить сначала скрипт с Set , после чего отдельно выполнить Declare Set serveroutput on format wraped; Declare Cou Integer; Begin For Rec in (select a.Table_Name from all_tables a where (a.OWNER = '<Имя_схемы>') ) loop Execute immediate('Select count(*) from '||Rec.Table_name) Into Cou; -- ************************************* dbms_output.put_line(' <Имя_схемы>'||Rec.Table_Name||';'||Cou); End Loop; End; Для того чтобы узнать размер таблицы в БД, требуется выполнить скрипт: select segment_name table_name, ceil(sum(bytes) / 1024) table_size from dba_segments where owner = ' <Имя_схемы>' aИмя_схемы>
VNC Viewer. Использование буфера обмена между Linux и Windows
Проблема: При работе на сервере через VNC Viewer не получается копировать куски текста, кода. Поэтому приходится вводить вручную. Решение: Первое решение, которое пока нормально работает. (возможно нужно найти возможность включения какой-либо настройки, но это потом в других вариантах). Необходимо выполнить следующую команду в терминале: [oracle@dbserver38 bin]$ vncconfig -display :1 В результате откроется окно, в котором (при необходимости необходимо поставить чекбоксы) После это можно копировать текст Для удобства, запихал данную команду в sh-файл на рабочем столе - VNC_copy_file.sh
Платформа 1С 8.2, в базе есть примерно 68 млн. документов одного вида, без табличных частей, около 35 млн. из них надо удалить с отбором по дате меньше определенной, ссылочная целостность не важна. Время простоя базы ограничено. Понятно, что средствами 1С быстро это сделать нереально. Как сделать это максимально быстро? Удалять в одной транзакции или бить на несколько, если на несколько, то как определить оптимальный с точки зрения скорости размер порции?
(4) Один из вариантов, да. Но и тут можно либо одной транзакцией сделать, либо несколькими. Как быстрее, вот в чем вопрос.
(10) Значит уменьшайте до 50-30-20-10-5-1 тысяч и опытным путем находите подходящий размер порции.
Индексы именно для такого удаления есть? Или просто "какие-то индексы" есть? План запроса на удаление смотрели?
(11) Это я про средствами 1С, такто через ADODB одной транзакцией за 2 часа удалилось, но хочется еще быстрее :) Индексы специальные для этого разового удаления делать както не очень хочется.
(14) Точно быстрее будет, чем одной транзакцией? По месяцам это будет 15 транзакций, запустил на тестовой, сравню время с удалением одной транзакцией. Но интересно не только из опыта, но и теоретически понять как быстрее всего решить такую задачу.
(13)Если хочется быстрее, то надо нарисовать процедуру по удалению порциями с транзакциями для каждой порции. В которой, может быть, и создавать временно нужный индекс. Если нет подходящего. И размер порции подобрать эмпирически. И эту процедуру запускать через ADO.
(15) когда в одной транзакции - не знаешь умер процесс или шевелится и ресурсов много надо.
а когда квантами - сразу видно, что процесс идет:)
а движения почему не удаляешь ?
(17) Конфигурация нетиповая, движения только по одному регистру накопления с одним регистратором, почистил раньше уже.
в рабочей базе - truncate table, а потом из копии в нее bulk insert нужного
(0) Быстрое в ы б о р о ч н о е удаление большого количества записей из раздутого регистра!? Нет сынок, это фантастика - намучились вволю уже. Если подскажете по-настоящему быстрый способ буду благодарен. (20) точно не быстро.
(24) delete - фигня по скорости, пробовал уже. Я бы (19) попробовал - вот bulk insert может ускорить.
(30) Ну в теории можно выгрузить в файл - из файла bulk insert, только не факт, что по времени это быстрее будет.
Вариант - ПодключитьОбработчикОжидания. Интервал вызова и количество документов на удаление обработка читает каждый раз из регистра сведений - можно подбирать нагрузку, чтоб и процесс шел, и пользователи работали. Иногда только так выкручиваемся, когда надо изменять большие объемы в фоновом режиме.
(0) Поставь платформу 8.3 ))) попробуй как удаляет. (офигеешь от разницы в скорости)
Попробуй грохнуть в файловом варианте.
1. Выгрузка данных в промежуточную таблицу (те что надо оставить) truncate потом таблицы. и те что оставил заливаешь обратно
2. delete from tab where tab.date < date
(39) Фоновый режим не вариант, есть 3-4 часа допустимого простоя системы, надо в них уложиться. Пока укладываюсь, но на грани, что-то пойдет не так и проблемы обеспечены.
(43) Можно, но в этой задаче не нужно :) Да и потом статистики всеравно пересчитывать, можно словить тормоза на неактуальных статистиках.
(47) Да, рабочий сервер на SSD да и памяти на скуле побольше, надеюсь раза в 2 быстрее, чем на тестовом будет. Но нет пределов совершенству :)
(10)если эти 68 млн Г копились столько лет и никому не мешали - ничего не мешает их так же потихоньку удалять.
каждый день по 100 тыс и все .
(49) Ну да, если при работе пользователей удалять много записей, кривая статистика на работе этих пользователей может сказаться отрицательно.
теперь запускаем это периодично, когда нагрузка на систему ниже определенной психологической отметки.
Если пользователи не работают, то можно грохнуть перед удалением все лишние индексы ( сильно ускорит, так как в индексах так же проставляется пометка удаления ), оставить только нужный для отбора.
(59) А вот это интересно, попробую. Там еще хинт TABLOCK попробовать советуют. А SET NO_BROWSETABLE ON можно через ADODB сделать, или только в менеджмент студии?
(0)
Выбери во временную таблицу, те документы, которые нужно оставить, сделай truncate основной, вставь из временной таблицы обратно.
(64) Выборка может быть медленной ( если объём ), а потом ещё и вставка ( индекс так же будет вставляться ). Проще как я описал. И после удаления пересоздать удалённые индексы ( можно уже руками, предварительно сделав дефрагментацию ).
>2 млн записей удаляется 8 минут.
(70) Ты все индексы удалил кроме одного где Дата + Ссылка ( Дата в индексе должна быть первой )?
Можно ещё статистику подсобрать после удаления индексов приблизительную. И сообщи какие у тебя условия в where. И зачем тебе транзакция в этом действии ( ты хочешь чтобы пользователи в этот момент работали? )
(15) "2 млн записей удаляется 8 минут.
нормальный результат 15 летней давности когда запись 20 МБ/сек была нормальной. сейчас ~30 сукунд.
(71) Не, индексы не удалял. Транзакция для надежности, вдруг что-нибудь пойдет не так. Хотя, наверное можно и без транзакции, если подумать. Кстати, в менеджмент студии Delete выполняется по умолчанию в транзакции или нет?
(72) Замедление из-за перестроения индексов в общем нормальное предположение, склонен с ним согласится.
Что касается ресурсов вопрос интересный конечно, недостатка ресурсов нет однозначно, насчет избытка не уверен.
(75) Нужно удалить индексы. Они удаляются пометкой удаления без физического удаления. Транзакция создаёт лишний объём работы, да и не нужна она в общем-то ( актуально для oracle с его undotablespace. Скорее всего для M$ так же хотя и не уверен, так как M$ всё равно в лог всё запишет и восстановление идёт из него если что. Транзакция влияет на блокировки ). DELETE работает без транзакции но в лог попадает разумеется, возможно режим логирования SIMPLE уменьшит объём логов ( не уверен. Надеюсь log файл на отдельном диске ). После удаления просто командой DML - CREATE INDEX создаёшь удалённые индексы. Время должно уменьшиться серьёзно, особенно если индексов много, да и индексные файлы сами по себе большие из-за большой таблицы. При относительно маленьком объёме оперативки может происходить много I/O.
(76) из Ваших вопросов ясно, что у Вас не понимания эксплуатации субд.
поэтому пользуйтесь простыми методами. Вам тут не расскажут
главы из руководства субд про массовые вставки , удаления обновления.
уточню (74) если с таблицами не работают реальные
много пользователей (olap) то одни варианты , иначе - другие.
(77) + Приведи что в конструкции после WHERE. Если удаление диапазонами, то оставь 1 индекс, где поле Дата будет первым полем и количество полей в индексе минимально.
(83) в (0) Время простоя базы ограничено
в (41) есть 3-4 часа допустимого простоя системы, надо в них уложиться.
(82) OLAP это аналитика, для неё обычно данные переносятся в другое хранилище, да и нагрузка не такая как на OLTP, так как данные в OLAP обычно агрегируются.
И да после удаления такого объёма нужно как минимум перестраивать индексы данной таблицы + статистику для ускорения доступа ( запросы )
(77) Да, удаление индексов помогло - оставил только кластерный и по периоду, и вместо 8 минут удаление прошло за минуту примерно. Скрипты на удаление и создание индексов очень просто делаются из менеджмент студии, создание индексов делается достаточно быстро.
(79) Да, вы правы, эксплуатацией СУБД занимается отдельный человек, просто для себя интересно чуть глубже понимать механизмы. Главы пересказывать не надо, надо просто подтолкнуть в правильном направлении :)
(89) Можно, но и так вроде неплохо. Сейчас протестирую удаление одним запросом, замерю время создания индексов, и будет понятно стоит ли дальше оптимизировать.
(90) Только что делать, если таблиц - десяток. Руками с ума сойдешь индексы удалять/пересоздавать :(
А то мне предстоит скоро таблицы на сотни миллионов записей чистить.
(91) Да скрипт готовишь используя SQL Server Management Studio. Можно ещё программно из 1С скрипт подготовить, используя ПолучитьСтруктуруХраненияБазыДанных
(90) По итогу - 30 млн записей удалились за 16 минут, 28 минут на пересоздание индексов. Дальше оптимизировать смысла не вижу.
(92) Ну да, для одного индекса получить скрипт на drop/create, дальше по аналогии для всех нужных индексов делаешь, и через ADODB запускаешь итоговый скрипт.
В данной статье будет рассмотрена методика удаления данных запросом в MSSQL-студии.
Порядок действий
При желании протестировать/посмотреть "что именно будет удаляться" предусмотрена соответствующая опция (галочка справа внизу), в этом случае скрипты будут формироваться с оператором SELECT, а не DELETE. Можно выделить нужный кусок, запустить на исполнение, посмотреть результаты, прежде чем запускать на удаление.
Как в MySQL очистить таблицу
Подключитесь к серверу по SSH. Затем подключитесь к MySQL при помощи команды:
Вместо username введите имя пользователя, вместо password — пароль.
Если вы не знаете пароль, попробуйте войти без него при помощи команды:
Если подключение без пароля не настроено, возникнет ошибка:
В этом случае сбросьте пароль от root-пользователя MySQL по инструкции.
TRUNCATE
TRUNCATE полностью очищает таблицу без возможности указать дополнительные условия. Для этого:
Выберите базу данных, в которой находится таблица, которую вы хотите очистить:
Вместо db_name введите имя базы данных.
Очистите таблицу при помощи команды:
TRUNCATE позволяет указать название БД и название таблицы в одном запросе. Для этого используйте команду:
Вместо db_name введите имя базы данных, а вместо table_name введите имя таблицы.
Готово, вы очистили таблицу.
DELETE
Выберите базу данных, в которой находится таблица, которую вы хотите очистить:
Вместо db_name введите имя базы данных.
Очистите таблицу при помощи команды:
Вы можете указать название БД и таблицы в одном запросе:
Вместо db_name введите имя базы данных, а вместо table_name введите имя таблицы.
Готово, вы очистили таблицу при помощи DELETE.
DELETE позволяет использовать условие WHERE, чтобы удалить некоторые строки из таблицы:
DELETE FROM table_name WHERE condition;
Где condition — это условие.
Пример команды, в котором будут удалены все строки, значение столбца, id которых больше 1000:
DELETE FROM table_name WHERE id > 1000;
Как очистить таблицу в MySQL
В статье мы расскажем, как в MySQL очистить таблицу. Мы покажем два способа и объясним разницу между ними.
Очистить таблицу можно при помощи одной из команд:
Аргументы
database_name | database_id | 0
База данных, которой принадлежит очищаемая таблица. Если указано значение 0, используется текущая база данных. Имена баз данных должны соответствовать правилам построения идентификаторов.
table_name | table_id | view_name | view_id
Очищаемая таблица или индексированное представление.
batch_size
Число строк, которые обрабатываются за одну транзакцию. Если не указано или указано значение 0, инструкция обрабатывает всю таблицу за одну транзакцию.
Читайте также: