Вообщем изменил я в конфигураторе один реквизит в регистре (строку на 50 символов уменьшил) и попытался обновить БД. База задумалась на неделю... Не тороплюсь конечно. Но в какой то момент база перестала расти и как бы зависла. Вообщем есть у кого советы сделать реструктуризацию побыстрее?

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

А в целом мне просто интересно. Неужели 40гб прям таки таблица занебесная... Что аж на неделю работы...

1c её не запросом реструктуризует, а сама насколько я помню, еще криво и тормознуто.. Неделя работы может быть, а железо какое?

(1) да обычное, локальный комп. тут главная загвоздка винт. он шуршит на полную. так что проц и т.д. не так важно должно быть.

может быть полезно
v8: Реструктуризация таблицы с большим количеством документов

2Гб памяти. но боюсь хоть 16гб ставь ничего особо не измениться. даже если в 4 раза ускорить

(2) локальный комп
т.е. SQL сервер под 2ГБайт памяти ?

(5) ну да ) ну нет пока под рукой другого

при всем при это попадание к кэш и т.д. все ништяк в пределах

сделать копию таблицы и очистить скулем, провести реструктуризацию 1ской, занести данные из копии (с обработкой) скулем?

(3) так и прийдется походу делать

(0) если дисковая подсистема дохлая.. если мало памяти и идёт свопинг на диск, если диск сильно дефрагментирован - у тебя и месяц это может считать

(10) если только сервер приложений или клиент 1с себе скушивает лишнее. скуль юзает 1гб и ему пофигу.

(11) Наивный чукотский мальчик :-)

Ничего личного.. ничего личного...

Это Винде (экспихе или обычному серверу) пофик ОЗУ более 4 Гб, а вот сиквел (энтерпрайз) - весьма доп. память любит и довольно сильно повышает быстродействие

проблема в том, что операция практически сводится к копированию данных. во времена скоростей даже 10мегабайт в сек (жесткий). 40гб, максимум 1.5 часа. процу в таком запросе делать надо только одно при строгой структуре таблицы. а если скуль или 1с требует объема памяти равного размеру таблицы, то как то это выглядит странно... тип 38 гб в свопе, а 2гб в памяти )

Автор шутник: реструктуризирует такую большую базу на таком слабеньком компьютере. Такую работу делают на быстром сервере.

(13) это тебе кажеться что "копирование данных с сектора в сектор" - там охренительная работа по тому же перестроению индексов

(15) если всё по умному, то индексы в этом случае вообще трогать не надо )

(16) хи-хи.. а скуль про это откуда знает?

По уму - индексы дропаются, затем делается изменение таблицы и затем индексы опять креетятся

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

вот бы ещё запросиков для сиквела под эту тему накинули...

(19) Какие?

копирование в другую таблицу... SELECT (UPDATE?) INTO База2 * FROM База1 и т.д. ) по реструктуризации вообще не понятно как писать.

(21) глупостями занимаешься

мне из перекрестной ссылки ясно только Allows NULLS )))

(22) варианты?!

(21) Все до вас придумано

Поднять нормальные железяки и сделать штатными средствами :-)

(21) Правой кнопкой по базе.
Tasks->Export data

(26) да есть нормальные железяки. там правда с местом есть траблы. но дело даже не в этом. запусти такую обработку на день, на два и это будет уже критично. баз много, много разных обработок 24/7. вот и хочется подход найти, чтоб убрать загрузку.

insert into table_copy (select * from table)
go
truncate table
go
реструктуризация
insert into table (select * from table_copy)
go

я вот книгу сча по сиквелу изучаю, юзаю конструкторы запросов скуля. но не допетрю что есть "go"? ) запуск описанного ниже запроса?

(29) Без всяких извращений делается.

(31) а где ты у меня извращение увидел?

(31) помоему в (29) будет работать побыстрее

(30) у мс скуля - выполнение команды пакетного запроса

(30) Go -  выполнение батча

+34 и после каждого go кажись результат в окне сообщения можно увидеть

Правой кнопкой по Таблице.
Scripts->Drop&Create->New Query Edit Window

Execute

Для нуба графические команды - самое то.

ну ещё реструктуризацию покажи примером. когда поле на чуть поменьше сделать ) я представляю это как создание колонки, присвоение значений от предыдущей и её удаление.

(38) а это уже через пофигуратор

38, а просто параметры колонки поменять не судьба?)

(39) ааа, понял.

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

ну вообщем я так понимаю изменение размера будет скрытое в виде преобразования при обратном копировании данных в исходную таблицу

(29) +  сразу обрезать строку
insert into table_copy (select
...
SUBSTRING(field1,1,100)
...
...
* from table)

А зачем вообще уменьшать строковый реквизит, он фиксированной длины чтоли?

Можно просче.

(44) только придется все поля перечислять в селекте

1)Зайти в SQL
2) Переименовать исх. таблицу
3) На ее основе создать исходную пустую через
Scripts->Create
4) Реструктуризовать в 1С
5) В переименованную таб. SQL тупо добавить новую колонку
6) Если надо - заполнить ее из SQL
7) Обратно переименовать таблицу

(45) дадада, его вообще надо нормализовывать... ну до этого сча пока далеко... )

(48) давай команду добавить в скуле в виде запроса и с заполнением и будет вообще красота ) попробую правда завтра наверное только...

(48) в переименованой таблице можно скулем изменить длину Поля varchar. и установить в параметрах время выполнения команды больше 30 секунд

Ааа, блин.
Не вкурил тему.
Там не новый реквизит, там модификация существующего

Не надо колонок добавлять

1C-у - 1С-ово на пустой таблице,
SQL-у - SQL-элево, как сказал автор (51).

изменение типа поля name в таблице tt так делается если чо:
alter table tt alter column name nchar(200) not null

(55)+ в примере тип поля будет соответствовать 1С типу: Строка длиной 200 фиксированной длины

(56) это понятно. спасибо за (55)
(54) угу

если это поле входит в какой нибудь индекс, то его желательно бы сначала прибить, потом alter, потом индекс снова создать, так будет быстрее.

а сколько записей в этой таблице?

(0) Может проще "налету" создать ещё одну таблицу с конвертацией, затем удалить старую и переименовать созданную?

Типа вот так:

SELECT  CAST(Sales.TYPE AS nvarchar(50))    
INTO            Sales_New
FROM         Sales

(59) как посмотреть без перебора? ) select count from табл?

а нашел в свойствах 61 546 843

Это регистр сведений? или чё это ваще такое?

(63) это любопытство ради стеба или какие то есть мысли? )

(64) Мне тоже любопытно

(64) с РН или РБ могут возникнуть проблемы а вообще просто итнересно

да всё как всегда. ваяли и всем пофиг. пытаюсь поменять ситуацию в корни.

а может не надо? подумаешь 50 символов?)

(68) да подумаешь две таблицы по 40гб в базе 150гб )

61 546 843(записей) * 50(символов) =  3 077 342 150 (байт) ~ 3 гб экономии.
надобы еще что-то грохнуть, или вынести эти данные в отдельную базу

(69) Автор, ты реально думаешь, что уменьшив таблицу на 3 гб ты "в корне изменишь ситуацию"?

50 символов мне показалось весят больше 50байт. unicode? ) но и там больше на самом деле, 300 всего чтоли...

(72) Тебе ВООБЩЕ неправильно показалось

(72) Строка фиксированная или переменной длины?

(71) автор видел проблему, реальную. и видит их ещё много. но на данный момент даже сверку просто нереально сделать.
(74) скорее всего переменной

но ограниченная.

(75) Рекомендую тогда почитать про SQL подробнее.

http://msdn.microsoft.com/ru-ru/library/ms186939.aspx

nvarchar [ ( n | max ) ]

   Символьные данные в Юникоде переменной длины. Аргумент n может принимать значение от 1 до 4 000. Аргумент max указывает, что максимальный размер хранилища равен 2^31-1 байт. Размер хранилища в байтах вдвое больше числа введенных символов + 2 байта. Введенные данные могут иметь длину в 0 символов. Синонимами по стандарту ISO для типа nvarchar являются типы national char varying и national character varying.

(77) шо, случайно ненормализованная база это уже хорошо? nvarchar

вот тут навели на мысль. если ещё и переменной длины, то такая таблица не только объемна. но и перебор особо долгий должен быть.

но одно верно, бесполезно размер уменьшать...

(75) я к тому, что на решение не той проблемы вы силы тратите.. Пусть даже 6 гб, если юникод - была база 150, станет 144. Смысл? Если это реквизит (а не измерение), то ни в каких индексах он по умолчанию не участвует. Лежит и никому, в принципе, не мешает.

(83)
<<Если это реквизит (а не измерение), то ни в каких индексах он по умолчанию не участвует.>>
А не по умолчанию?

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

(85) Случайно база - не наследница Акцапты?

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

(85) нене, типовая ухреначенная.

(87) ошибка не (85), а (86)

Приведи структуру и имя регистра, который 40 гектарр

регистр партий. выкладывать не стоит. тут ещё своя политика.

А shrink делается?

база гружена из дт. ушел, до завтра )

(84) ну если ручками поставили галочку, то будет здооооооровый такой индекс
(85) если измерение - тогда да, надо уменьшать. Делать как можно меньше.. Посмотрите на SQL Server какие поля (и сколько) попадают в индексы по этой таблице. Если это измерение стоит еще и где-то в начале - это довольно-таки печально..
(91) Про shrink лучше бы вообще забыть.. Слишком много проблем и только один плюс (место), да и тот весьма сомнительный

вообщем результаты извращения в SQL. таблицу переформировал в течении 1.5 часов. делал это созданием второй колонки и заполнением на основе первой (150 > 100). делаю это только ради прочувствовать скорость SQL Server'а. но таблицу то я изменил быстро. но вот индексы. они все испортили ) в индексах меняю колонку с одной на другую (новую). 4 часа прошло, индекс все меняется. походу надо было его не менять, а создать новый... короче не всё так просто...

А я так понял, у вас был план выгрузить все данные из таблицы в копию (в копии уже обрезать строку), очистить существую таблицу, провести реструктуризацию на пустой таблице и вернуть все данные обратно.. Ну и индексы можно было бы удалять\создавать заново, при необходимости..

(95) обрезать строку не дает скуль. он ругается, что надо копировать таблицу и в ней типа изменять. но ответа да на сообщение нету и скопировать это таже байда не нужная мне. вообщем просто обрезать нельзя.

мдя...
А если просто
update table set strField = Left(strField, 100)
а потом менять стурктуру?

alter table ... alter column ?

(97) сомневаюсь что поможет и не выругнется как при правке через интерфейс. но сча уже не важно, наизвращался ))) кстати что значит Left(?) - определение типа?

и продолжение темы в v8: Замена строки в таблице MSSQL на ссылки из другой таблицы

(99) а понял. слева 100 символов. туплю )

(99) left - это аналог Лев() ...

(101) ну тогда это вообще не то что нужно. в (97) обрезка поля которого делать не нужно, точно известно что поле содержит менее 100 символов изначально. требуется изменить структуры таблицы. которая не меняется через интерфейс скуля по какой то непонятной причине. скорее всего прицепленные индексы мешают.