|
07.08.2007, 13:47 | #1 |
Модератор
|
Коллеги, одна таблица обновляется одним оператором UPDATE
Эта операция атомарная, в ней нет промежуточного состояния "первую строку обновили, вторую еще нет" Точно так же оператор X++: update ledgerTrans set RecId = RecId + 1 ACID это называется
__________________
-ТСЯ или -ТЬСЯ ? |
|
|
За это сообщение автора поблагодарили: kashperuk (3). |
07.08.2007, 14:41 | #2 |
Участник
|
Ой, да. Это я Сусанин, не посмотрев код, не в ту степь повел.
Почему-то подумал, что вместо обновления потабличного (что намного производительнее, причем) делается позаписное (по RecId, и для каждого пробежка по всем таблицам). Посмотрел код, действительно, все записи обновляются одним запросом, поэтому проблема эта - вообще не проблема. |
|
07.08.2007, 10:23 | #3 |
Мрачный тип
|
Именно так , Иван , Вы правильно поняли ...
Блин , не обратил внимание на последнюю строку в создании таблицы соответствия, где индекс по старому значению создавался. Спасибо, Иван, за наставление на путь истинный, а то уже я наладился свой генератор писать, который на моих 6 млн записей сутки бы генерил новые RecId С автоинкремента обвинения снимаются |
|
07.08.2007, 10:31 | #4 |
Member
|
Даже если бы индекса не было, то к нарушению логической целостности это не привело бы. Вопрос был бы только в скорости.
__________________
С уважением, glibs® |
|
28.05.2008, 13:10 | #5 |
Мрачный тип
|
Poseidon-topex, вряд ли кто-то это делал .
Теоретически и физически оно можно, только своими самописными средствами, ибо стандартный класс дефрагментации RecId это не поддерживает. Но логические последствия будут - я Вас умоляю : это срыв башни стандартному дефрагментатору(наворотит так , мало не покажется) и никуда не ушедшая вероятность появления данных ошибок на других таблицах.
__________________
Мы летаем, кружимся, нагоняем ужасы ... |
|
28.05.2008, 17:14 | #6 |
Участник
|
Ну, технически думаю никаких проблем нет.
Если вы исследуете класс SysRecIdRepair, то увидите, что там все довольно просто. То есть не сложно наложить фильтр для просмотра только одной таблицы, а не всех сразу. Никаких негативных последствий от этого быть не должно. |
|
28.05.2008, 20:37 | #7 |
Member
|
Поддерживаю TasmanianDevil. Испортите базу так, что потом уже вам ее никто не починит.
Рано или поздно поползут проблемы на других таблицах. А если на них есть ссылки по RecId, то такое надругательство база не стерпит. А стандартный алгоритм дефрагментации работать уже... ну скажем так... будет работать уже не так, как задумывалось. Раз уж вы прощелкали момент запуска дефрагментации, то ее нужно запустить как можно быстрее (с учетом всего того, что писалось выше), чтобы иметь как можно меньше негативных последствий.
__________________
С уважением, glibs® |
|
29.05.2008, 06:23 | #8 |
Мрачный тип
|
Спасибо, glibs, что поддержали .
Единственное, что хотелось бы добавить - если позволяют ресурсы временные и человеческие, перед стандартной дефрагментацией на такой компании сделайте аналогичный стандартному проход по таблицам с накоплением данных по разрезу "таблица/RecID" для мониторинга дублей. Это позволит оценить масштабы и возможные последствия после дефрагментации, а то и вовсе устранить дубли , если их не так уж и много будет в результате или они находятся в малозначимых таблицах.
__________________
Мы летаем, кружимся, нагоняем ужасы ... |
|
17.07.2008, 18:02 | #9 |
Участник
|
Все добрый день!
Дефрагментацию пока не делали, но чувствует мое сердце, что скоро придется . База 54ГБ (правда это сейчас, перед дефрагментацией планирую немножко почистить ) Пробовал запускать Проверку кодов записей на тестовой базе - колбасилось трое суток, нагрузка на сервере БД: ввод/вывод на пределе, загрузка проца 10-30% процедура не завершилась . Сервак висел капитально
__________________
Жить все веселей!.. AX3SP3CU1 |
|
17.07.2008, 18:07 | #10 |
Участник
|
Цитата:
Сообщение от Didukh84
Все добрый день!
Дефрагментацию пока не делали, но чувствует мое сердце, что скоро придется . База 54ГБ (правда это сейчас, перед дефрагментацией планирую немножко почистить ) Пробовал запускать Проверку кодов записей на тестовой базе - колбасилось трое суток, нагрузка на сервере БД: ввод/вывод на пределе, загрузка проца 10-30% процедура не завершилась . Сервак висел капитально Можете привести данные отчета "Disk usage by top tables" или аналогичного? сюда смотрели? http://axapta.mazzy.ru/lib/dbgrowthsolution/ дефрагментация recid очень тяжелая операция. ну и дополнительные советы: сразу выделяйте много (очень много) места под transaction log, установите шаг роста файла достаточно большим (не 1мб), сразу выделяйте место под базу (чтобы еще гигов 50 было свободно в базе). скорее всего у вас не аксапта работала а СКЛ тратил все время на рост базы. |
|
23.07.2008, 16:10 | #11 |
Участник
|
привожу
__________________
Жить все веселей!.. AX3SP3CU1 |
|
14.10.2008, 11:49 | #12 |
Участник
|
LedgerTrans.BondBatchTrans_RU
У меня вопрос знатокам по поводу поля LedgerTrans.BondBatchTrans_RU. У поля тип RefRecId, но как я понял ни на какой живой RecId он не ссылается. Вопрос, что будет с содержимым этого поля при выполнении дефрагментации RecId? Ведь новые номера в таблице AXOLDTONEWRECIDS сгенерятся не для всех его значений, а апдейт будет все равно запускаться.
|
|
18.07.2008, 09:47 | #13 |
Участник
|
Добрый день!
Цитата:
привести данные отчета "Disk usage by top tables" или аналогичного
на счет выделения места, то я уже на эти грабли наступил Цитата:
СКЛ тратил все время на рост базы
__________________
Жить все веселей!.. AX3SP3CU1 |
|
21.07.2008, 21:27 | #14 |
Участник
|
Давным-давно заморачивался этим вопросом, в ходе поиска по тырнету нашел скрипт для Ms SQL, который выдает полезную информацию по таблицам, используя то, что сообщает хранимка sp_spaceused. Все данные о размере, выдаваемые ей, выводятся в kb, но подстрока " KB" удаляется, чтоб удобней было обрабатывать выхлоп в том же Excel.
Вот немного доработанный мною вариант скрипта (авторские комментарии сохранены): PHP код:
|
|
|
За это сообщение автора поблагодарили: Denicce (1), aidsua (1), MikeR (1), Didukh84 (1). |
21.07.2008, 22:45 | #15 |
Модератор
|
Цитата:
Сообщение от gl00mie
Давным-давно заморачивался этим вопросом, в ходе поиска по тырнету нашел скрипт для Ms SQL, который выдает полезную информацию по таблицам, используя то, что сообщает хранимка sp_spaceused. Все данные о размере, выдаваемые ей, выводятся в kb, но подстрока " KB" удаляется, чтоб удобней было обрабатывать выхлоп в том же Excel
Цитата:
Сообщение от Didukh84
а где можно его можно найти
для 2000 - см. выше Только вот.. Didukh84, Вы УВЕРЕНЫ, что Вам надо запускать эту процедуру? У Вас RecId перескочил за maxint() или Вы таким образом пытаетесь решить какие-то другие проблемы?
__________________
-ТСЯ или -ТЬСЯ ? |
|
23.07.2008, 15:34 | #16 |
Участник
|
Цитата:
Да, запустил еще раз проверку кодов то через 4-о суток оно сделалось!!! Значение RecId стало "140568244" :-) (правда я запускал перед этим еще реиндексацию зачем-то :-( )
__________________
Жить все веселей!.. AX3SP3CU1 |
|
18.07.2008, 09:51 | #17 |
Участник
|
Цитата:
сюда смотрели? http://axapta.mazzy.ru/lib/dbgrowthsolution/
__________________
Жить все веселей!.. AX3SP3CU1 |
|
14.10.2008, 13:35 | #18 |
Member
|
С ними будет то же самое, что будет в полях, которые таки ссылаются на другие записи по RecId. Т.е. если у вас запись ссылается на другую запись по RecId, но записи с таким RecId не существует, то ссылка по RecId не обновляется. После реиндексации она может начать ссылаться на какую-то другую (уже существующую) запись. Тут будет точно так же. Но в данном конкретном случае, по-моему, это не страшно.
__________________
С уважением, glibs® |
|
14.10.2008, 14:17 | #19 |
Участник
|
Цитата:
Смотрим код. Там в частности для оракла генерится оператор вида: UPDATE table set field = NEWRECID FROM AXOLDTONEWRECIDS WHERE OLDRECID=table.field Допустим, в AXOLDTONEWRECIDS не всегда есть подходящая запись, UPDATE вообще не отработает или запишет пусто? Версия 3. |
|
14.10.2008, 14:32 | #20 |
Участник
|
Для table.field, которым нет соответствия в AXOLDTONEWRECIDS, ничего не изменится
__________________
Axapta v.3.0 sp5 kr2 |
|
|
За это сообщение автора поблагодарили: coolibin (1). |