Как выполнять дефрагментирование RecID

[gefr]

Цитата:

Сообщение от Vadik

а что, кто-то уже с этим столкнулся?

select dataareaid, name, nextval from systemsequences order by nextval desc

давайте меряться максимальным значением NextVal

у меня 87'945'778

413'381'425

[TasmanianDevil]

Пара слов о стандартном SysRecIdRepair, точнее о надежности его использования ...
Автоинкремент в чистом неконтролируемом виде, используемый в данном классе для генерации новых значений RecId - есть зло, ибо рискуем с ним получить нарушение ссылочной целостности ввиду теоретической возможности совпадения в рамках одной таблицы старого и нового RecId, не являющегося заменой старому. Чем это чревато - можете представить сами
.
Новый RecId должен быть построен на автоинкременте с проверкой каждого нового значения на пересечение с подмножеством старых значенй по этой таблице. Это, конечно же, замедлит общий процесс дефрагментации и породит некоторые небольшие дырки в множестве новых RecId, но зато с подобной проверкой на душе спокойнее.

[Vadik]

Цитата:

Сообщение от TasmanianDevil

Автоинкремент в чистом неконтролируемом виде, используемый в данном классе для генерации новых значений RecId - есть зло, ибо рискуем с ним получить нарушение ссылочной целостности ввиду теоретической возможности совпадения в рамках одной таблицы старого и нового RecId, не являющегося заменой старому

А можно пример? Тяжело с утра понять, о чем идет речь

[kashperuk]

Цитата:

Сообщение от Vadik

А можно пример? Тяжело с утра понять, о чем идет речь

Насколько я понял, имеется ввиду, что в таблице соответствия старым RecId новых может случиться ситуация вида:

RecId (OLD) RecId (new)
124 1
45676 2
2 3

То есть произойдет замена уже замененного RecId.
Если неправильно понял, ТазманианДевил поправит.

Но такой ситуации не может быть, потому как RecId в таблице отсортированны по возрастанию. То есть таблица будет выглядеть так, на самом деле:

RecId (OLD) RecId (new)
2 1
124 2
45676 3

[TasmanianDevil]

Именно так , Иван , Вы правильно поняли ...

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

Спасибо, Иван, за наставление на путь истинный, а то уже я наладился свой генератор писать, который на моих 6 млн записей сутки бы генерил новые RecId
С автоинкремента обвинения снимаются

[glibs]

Даже если бы индекса не было, то к нарушению логической целостности это не привело бы. Вопрос был бы только в скорости.

[Vadik]

Коллеги, одна таблица обновляется одним оператором UPDATE
Эта операция атомарная, в ней нет промежуточного состояния "первую строку обновили, вторую еще нет"
Точно так же оператор

update ledgerTrans set RecId = RecId + 1

не приводит к нарушению уникального индекса по RecId вне зависимости от того, по возрастанию индекс построен или по убыванию или как сервер будет страницы для UPDATE выбирать
ACID это называется

[kashperuk]

Ой, да. Это я Сусанин, не посмотрев код, не в ту степь повел.

Почему-то подумал, что вместо обновления потабличного (что намного производительнее, причем) делается позаписное (по RecId, и для каждого пробежка по всем таблицам).

Посмотрел код, действительно, все записи обновляются одним запросом, поэтому проблема эта - вообще не проблема.

[Poseidon-topex]

Доброго утра!

Ввиду большого кол-ва операций достигли ситуации когда RecId пошел на второй круг и в таблице CustInvoiceTrans начала появляться ошибка "Запись уже существует". Собственно, одна две записи допавляются без проблем, а вот заказ на 100 строк уже не разносится.
Т.к на других операциях ошибок не замечено, решено провести дифрагментацию RecId но только для ОДНОЙ таблицы. Т.е. дефрагметировать RecId в таблице CustInvoiceTrans и при этом счетчик глобальный счетчик RecId не трагать, так как nextValue порядка 1 млрд, а записей в CustInvoiceTrans около 100 млн. Соответственно, если дефрагментировать RecId только в этой таблице то все последующие вставки в таблицу будут проходить безошибок.

Вопрос: проделывал ли кто подобное? Аксапта 3.0 SP5, MS SQL 2005

Спасибо.

[TasmanianDevil]

Poseidon-topex, вряд ли кто-то это делал .
Теоретически и физически оно можно, только своими самописными средствами, ибо стандартный класс дефрагментации RecId это не поддерживает. Но логические последствия будут - я Вас умоляю : это срыв башни стандартному дефрагментатору(наворотит так , мало не покажется) и никуда не ушедшая вероятность появления данных ошибок на других таблицах.

[kashperuk]

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

[glibs]

Поддерживаю TasmanianDevil. Испортите базу так, что потом уже вам ее никто не починит.

Рано или поздно поползут проблемы на других таблицах. А если на них есть ссылки по RecId, то такое надругательство база не стерпит. А стандартный алгоритм дефрагментации работать уже... ну скажем так... будет работать уже не так, как задумывалось.

Раз уж вы прощелкали момент запуска дефрагментации, то ее нужно запустить как можно быстрее (с учетом всего того, что писалось выше), чтобы иметь как можно меньше негативных последствий.

[TasmanianDevil]

Спасибо, glibs, что поддержали .
Единственное, что хотелось бы добавить - если позволяют ресурсы временные и человеческие, перед стандартной дефрагментацией на такой компании сделайте аналогичный стандартному проход по таблицам с накоплением данных по разрезу "таблица/RecID" для мониторинга дублей. Это позволит оценить масштабы и возможные последствия после дефрагментации, а то и вовсе устранить дубли , если их не так уж и много будет в результате или они находятся в малозначимых таблицах.

[anikulichev]

Добрый день.
Дефрагментацию recId выполняли уже несколько раз. На форуме уже писали, что и где надо подправить для ускорения. Вся операция на 80 gb базе занимает около 3.5 часов.
Поддерживаю glibs и TasmanianDevil.

[Didukh84]

Все добрый день!
Дефрагментацию пока не делали, но чувствует мое сердце, что скоро придется . База 54ГБ (правда это сейчас, перед дефрагментацией планирую немножко почистить ) Пробовал запускать Проверку кодов записей на тестовой базе - колбасилось трое суток, нагрузка на сервере БД: ввод/вывод на пределе, загрузка проца 10-30% процедура не завершилась . Сервак висел капитально

[mazzy]

Цитата:

Сообщение от Didukh84

Все добрый день!
Дефрагментацию пока не делали, но чувствует мое сердце, что скоро придется . База 54ГБ (правда это сейчас, перед дефрагментацией планирую немножко почистить ) Пробовал запускать Проверку кодов записей на тестовой базе - колбасилось трое суток, нагрузка на сервере БД: ввод/вывод на пределе, загрузка проца 10-30% процедура не завершилась . Сервак висел капитально

Какие таблицы самые большие?
Можете привести данные отчета "Disk usage by top tables" или аналогичного?
сюда смотрели? http://axapta.mazzy.ru/lib/dbgrowthsolution/

дефрагментация recid очень тяжелая операция.

ну и дополнительные советы: сразу выделяйте много (очень много) места под transaction log, установите шаг роста файла достаточно большим (не 1мб), сразу выделяйте место под базу (чтобы еще гигов 50 было свободно в базе).

скорее всего у вас не аксапта работала а СКЛ тратил все время на рост базы.

[Didukh84]

Добрый день!

Цитата:

привести данные отчета "Disk usage by top tables" или аналогичного

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

Цитата:

СКЛ тратил все время на рост базы

так оно и было, при этом загрузка проца была несущественной, а вот дисковая система - под завязку (в обычные дни такой я за 1 год (который более-менее мониторю нагрузку) еще не видел )

[Didukh84]

Цитата:

сюда смотрели? http://axapta.mazzy.ru/lib/dbgrowthsolution/

да, видел. Правда я пока данные не чистил (хотел попробовать за минимум затрат). И у нас самые объемные таблицы (SalesLine, PurchLine и т.д.) чистить нельзя (некоторые нужные отчеты базируются на этих таблицах)

[gl00mie]

Цитата:

Сообщение от Didukh84

а где можно его можно найти

Давным-давно заморачивался этим вопросом, в ходе поиска по тырнету нашел скрипт для Ms SQL, который выдает полезную информацию по таблицам, используя то, что сообщает хранимка sp_spaceused. Все данные о размере, выдаваемые ей, выводятся в kb, но подстрока " KB" удаляется, чтоб удобней было обрабатывать выхлоп в том же Excel.
Вот немного доработанный мною вариант скрипта (авторские комментарии сохранены):

PHP код:

set nocount on
/*
DATABASE TABLE SPY SCRIPT
 Micheal Soelter
 1/24/03
DESCRIPTION
 returns table size information
SORTING USAGE
 @sort bit values
 0 = alphabetically by table name
 1 = sorted by total space used by table
*/
declare @cmdstr varchar(100)
declare @Sort bit
select @sort = 1 /* edit this value for sorting options */
/* DO NOT EDIT ANY CODE BELOW THIS LINE */
--create temporary table
if object_id('tempdb..#temptable') is not null drop table #temptable
create table #temptable
 (  table_name varchar(100),
    row_count int,
    table_size_str char(15),
    data_space_used_str char(15),
    idx_space_used_str char(15),
    unused_space_str char(15),
    table_size int,
    data_space_used int,
    idx_space_used int,
    unused_space int
 )
--create stored procedure string
select @cmdstr = 'sp_msforeachtable ''sp_spaceused "?"'''
--populate tempoary table
insert into #temptable (table_name, row_count, table_size_str, data_space_used_str,
                        idx_space_used_str, unused_space_str)
    exec(@cmdstr)
--determine sorting method
update #temptable
    set table_size      = cast(replace(table_size_str,      ' KB', '') as int),
        data_space_used = cast(replace(data_space_used_str, ' KB', '') as int),
        idx_space_used  = cast(replace(idx_space_used_str,  ' KB', '') as int),
        unused_space    = cast(replace(unused_space_str,    ' KB', '') as int)
if @sort = 0
    begin
        --retrieve table data and sort alphabetically
        select table_name, row_count, table_size, data_space_used, idx_space_used, unused_space
        from #temptable order by table_name
    end
else
    begin
        --retrieve table data and sort by the size of the table
        select table_name, row_count, table_size, data_space_used, idx_space_used, unused_space
        from #temptable order by table_size desc
    end
--delete temporay table
drop table #temptable 


[Vadik]

Цитата:

Сообщение от gl00mie

Давным-давно заморачивался этим вопросом, в ходе поиска по тырнету нашел скрипт для Ms SQL, который выдает полезную информацию по таблицам, используя то, что сообщает хранимка sp_spaceused. Все данные о размере, выдаваемые ей, выводятся в kb, но подстрока " KB" удаляется, чтоб удобней было обрабатывать выхлоп в том же Excel

см. А "потянет" ли Axapta такой объем данных ?

Цитата:

Сообщение от Didukh84

а где можно его можно найти

для 2005 и выше - в Management Studio
для 2000 - см. выше

Только вот.. Didukh84, Вы УВЕРЕНЫ, что Вам надо запускать эту процедуру? У Вас RecId перескочил за maxint() или Вы таким образом пытаетесь решить какие-то другие проблемы?