|
1C v8.0 и SQL 2005
|
|||
---|---|---|---|
#18+
Здравствуйте уважаемые господа! Заметил рост базы 1С v8.0 и нашел ошибку в настройке базы под SQL 2005. У этой базы в свойствах стояла галочка "Use full-text indexing", соответственно имено поэтому и обуславливался такой рост базы. Все понятно. Нашел выход из данной ситуации: 1) Создал новую базу в SQL без этой галочки; 2) Выгрузил базу средствами 1С (Выгрузить ИБ); 3) Загрузил эту базу в новую (Также средствами 1С); Все вроде хорошо, размер базы уменьшился в разы. Но через неделю она опять распухла до размеров предыдущей. Не могу понять в чем дело, откуда появились эти индексы опять если в настроках базы не стоит полнотекстовый поиск. Ведь с точки зрения SQL это уже совсем другая база, с другой структурой. Распухла база после перестроения индексов (запланированный job на каждую неделю) ... |
|||
:
Нравится:
Не нравится:
|
|||
14.07.2008, 10:27 |
|
1C v8.0 и SQL 2005
|
|||
---|---|---|---|
#18+
Журнал транзакций обрезаете? ... |
|||
:
Нравится:
Не нравится:
|
|||
14.07.2008, 23:59 |
|
1C v8.0 и SQL 2005
|
|||
---|---|---|---|
#18+
Если распухает файл лога, то следует приводить в соответствие установленной для БД Recovery Model реальную практику архивирования (например, выполнять архивирование журналов транзакций, после чего файл лога сам очистится от закомиченных и сархивированных транзакций). Если распухает файл БД после перестроения индексов... Ну что ж, для размещения индексов тоже место нужно. Если уж так не хватает места на диске, можно в JOB добавить DBCC SHRINKDATABASE. Желательно эту операцию выполнять ночью, чтобы не создавать взаимных помех. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.07.2008, 09:13 |
|
|
start [/forum/topic.php?fid=28&msg=35427797&tid=1524601]: |
0ms |
get settings: |
11ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
83ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
46ms |
get tp. blocked users: |
1ms |
others: | 13ms |
total: | 189ms |
0 / 0 |