AnnaGL пишет:

> Таблица содержит порядка 150 млн. записей. Основной объем данных
> хранится в столбце типа varchar(255) и строка реально занимает около
> 200-255 симвлов, а теперь его необходимо очистить, но не все строки, а
> по условию, которое в столбце типа bit этой же таблицы.

При таких объёмах уже главное -- не скорость, а чтобы ненароком
не переполнить журнал транзакций. Поэтому по кускам напр. по 1000
записей в транзакции.

> Примерно вот так:
> над таблицей ATable(AKey indentity, aSome1,aSome2,aSomeN, A_STRING
> varchar(255), A_FIELD bit)
> выполнить update ATable set A_STRING="" where A_FIELD=0

Лучше
update ATable set A_STRING=null where A_FIELD=0

> Запрос настолько громадный, что вызывает переполнение журнала
> транзакций,а расширять журнал некуда,

Говорю же , кусками....

Либо просто ставишь rowcount 1000, либо отбираешь ключи нужных
записей заранее в промежут. табличку, пачками по 1000-10000, и
уже из них -- update/

> и неуверена, что это поможет. Пробовала разбить по ключу по 1млн,
> выполняется днями..... на таблице висит много индексов, но индексы со
> столбцом A_STRING удалены. Может есть какие-то хитрые приемы для таких
> случаев?

Кроме всего, что перечислил, нет.

А, не, есть, можно ещё сделать select ... c учётом этого
критерия формирования поля A_STRING, сделать по нему VIEW,
view сделать BCP OUT, потом таблицу TRUNCATE, и потом уже
BCP IN обратно. Но это тоже не быстро при таких объёмах, и ,
что плохо, off-line: БД будет всё это время простаивать.
Posted via ActualForum NNTP Server 1.4

SQLMantis пишет:
> Автор: "SQLMantis"
> Ex_Soft,
> Ммм, у меня 12.5.4
> Ну тогда курсором, примерно так

Да просто можно

set rowcount 1000
update Atable set A_STRING="" where ..
Posted via ActualForum NNTP Server 1.4

komrad пишет:

> ну кто-то же должен расплачиваться за чьи-то ошибки...

Какие ошибки ? На VLDB -- это обычное дело, ничего страшного нет.
Главное -- чтобы процессы поддержки базы шли незаметно для остальных
пользователей. Тогда их можно запускать на постоянной основе,
чтобы всегда работали. И всё.
Posted via ActualForum NNTP Server 1.4

SQLMantis пишет:

> А разве делать всякий раз большое количество запросов (в условиях
> статистики никак не связанной с реальными данными) быстрее чем просто
> пройтись по курсору?
> По моему опыту, курсор в таких задачах на порядок быстрее.

Курсоры или не курсоры ?

Задача любого UPDATE-а делится на 2 основные части:
найти подлежащие изменению строки таблицы

собственно произвести изменения (запись в таблицу,
запись в лог и т.п.)

Во второй части что с курсором, что без курсора -- разницы
не будет.

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

Но если условие WHERE в UPDATE или курсоре отрабатывает по индексу,
то хоть O(log N), хоть O(k*log N) -- не большая разница, если
k много меньше N (к - количество порций изменения таблицы,
N - количество строк в таблице).

Так что курсор будет быстрее, только если условие
в WHERE работает без индекса.
Posted via ActualForum NNTP Server 1.4

SQLMantis wrote:

> Хм. Все это конечно верно, но какое отношение имеет к конкретному курсору?

А какое отношение имеет конкретный курсор к обсуждаемой теме ?

> В случае с rowcount или top мы вынуждены всякий раз учитывать в запросе,
> кроме прямого условия A_FIELD=0, уже измененные строки с помощью
> A_STRING != "".

Вовсе не обязательно, если UPDATE-ом условие также устанавливается в обратное.

> Я же в курсор достаю PK (надеюсь :) ) и делаю update с учетом его и только.

Это не сильно помогат.

> Что позволяет мне сделать один раз выборку только по A_FIELD=0. После
> чего пройтись по PK. Так быстрее, проверено.

Да не факт. Ты просто смотрел свой конкретный случай.
Posted via ActualForum NNTP Server 1.4

iLLer пишет:
> прозвучало: объем таблицы 150млн, условие по полю битового типа,
> селективность не указана. Значит, можно предположить по теории
> вероятности, что 50% записей имеет в A_FIELD=0, другая половина =1.
> Индексы хвататься не будут, значит перебор таблицы. В таком случае, один
> курсор будет однозначно быстрее, чем Х операций, включающих точно такой
> же перебор.

Да, согласен.
Posted via ActualForum NNTP Server 1.4