разбить базу sql в 1С на несколько файлов #539952

есть база на sql2005, хочу разбить один файлик *.mdf на несколько. Допустим в самом скуле понятно. делаю файловые группы, прописываю файлы базы. а в 1Ске что надо сделать? как мне задать, чтобы этот справочник находился в одном файле .mdf, а другой справочник в другом .mdf, а все документы - в третьем .mdf?

Где такую забористую траву берешь?

отсыпать?

разбиение на файлы mdf не мухаморчики, нужная штука

Может и нужная, но при чем тут 1С? Какое вообще дело 1С до того, какая таблица в каком файле лежит? Разве это не уровень самой СУБД? Или я чего-то не понимаю?

конечно уровень СУБД и если есть возможность принудительно распределить объекты 1С по файлам, то такая возможность нам нужна

я так понимаю, что логическое имя файла должно совпадать с именем таблицы? так?

возможно надо перетащить нужные таблицы в нужный файл после создания файликов

для 1С это будет одна таблица

так я не понял. это не возможно чтоли?

а разве не подходит?

а еще есть секционирование....

может тогда на 7.7 файловую перейти ))

А в дело написано! Регистры бухии в одну фйловую группу, справочники в другую, доки в третью.

а вопросец можно? Нафига?

Ну может скорость i/o вырастет?

Мда.... до такой степени оптимизацией заниматься... А код конфигурации уже вычищен?

Не знаю, надо у ТС спрашивать.

если в конфигурации есть гигантский Рг сведений, под который нет места на SSD, то порезав на 2 файлы получишь значимое ускорение

можно на скуле базу проанализировать, простейший запрос по размеру таблиц, и смотреть как лучше разделить. в 1с, в конце концов, ПолучитьСтруктуруХраненияБазыДанных

Ускорение в чем в поиске? в записи?

во всем

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

конечно на отдельных, желательно рэйдах

А как правильно разнести 1. справочники отдельно, документы отдельно, регистры отдельно 2. Или например справочники и документы вместе, а их индексы в другой массив. Мне кажется нужно смотреть в сторону 2 способа т.к. справочники - это условно-постоянная информация, а надо распределять часто обновляемую, т.е документы и регистры и их индексы

[а надо распределять часто обновляемую] а если для ТС важна скорость построения отчетов, а документов мало ?

Вопросов нет, естественно что каждый случай надо рассматривать отдельно.

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

наткнулся тут на базу, доставшуюся мне в наследство, там есть такое разделение. вот хочу попробовать, а как это сделали

ну сделай... Только ведро вазелину купи, а то ведь просто так, на халяву, не выдадут

а почему вы думаете, что там объекты (справочники, доки, регистры) рассованы по отдельным файлам, а не просто несколько файлов данных?

а причем тут вазелин? что такого сложного здесь? После разделения какие могут быть проблемы? я не знаю как именно там поделено. Есть несколько фалов данных, но что именно находится в каждом - непонятно. но там база около 250Гб, так что им видимо пришлось улучшаться. А можно как нить узнать, что находится в каждом файле? Понятно, что я могу просмотреть в сиквеле содержимое таблицы. Но там зачастую только уникальные идентификаторы увидишь

проблемы будут обязательно. Особенно, если ты не знаешь, что делаешь.

если не попробую - то и не узнаю.

делай, рецепт со вчера висит, упадет - расскажешь

блин, злодеи :) чей то она упасть должна?

кончай флюдить - начни работать, mov-нуть можно было за ночь

рано еще работать, я кофе еще не пил

А таблицы - получаешь штатными средствами, потом sp_help на имя таблицы и смотришь, в какой файл-группе она сидит

помнится в какой то версии мс-скуля обещали, что можно будет раскидывать данные по мдф частями таблиц, типа данные до такой то даты - на медленный диск, остальное - на быстрый или я замечтался?

давно уже есть.

с 2005 получается? ибо в 2000 не было такого...

Например, для справочников: 1. Создание доп. файловой группы; 2. Убиение индексов (всех, PK обязательно) на целевой таблице; 3. Воссоздание PK целевой таблицы на новой файловой группе; 4. Воссоздание индексов остальных, но это можно доверить самой 1с; Все - таблица переехала в новую файловую группу.

ну здрасьте.. <=2000 делалось секционирование на основе представлений; >2000 есть штатное секционирование, поддерживаемое самой СУБД;