| [Форум] [Помощь] [Поиск] [Выйти] |
Добро пожаловать, ![[info]](userinfo.gif){kind=small} User
|
|
|
| ||
| Как ее избежать при обновлении метаданника? |
| ||
| а цель какова?.. ускорить процесс?... сохранить что то, что подверглось разрушению? |
| ||
| Никак.При работе с DBF обязательно. |
| ||
| Фигня. Переиндексация происходит только в случае изменения структуры данных. Ежели структуру не менял, то значит кто-то из пользователей некореектно выходил. |
| ||
| Пользователи выходят корректно, изменния касаются модуля формы или журнала. Я бы понял если бы действительнно как-то структуру трогал, а тут чисто текст. Под SQl она не быстрее происходит? |
| ||
| Под SQL все система(SQL Server) сама сделает, она под это заточена, рухнет база( ну там питание пропадет или еще что нить) отлетят последние транзакции и делов. Возмжно даже поднять из роллбаков, но сам не пробовал.:) |
| ||
| Локально база быстрее переиндексируется чем в сиквеле? |
| ||
| Нет, не быстрее ;) К тому же там придется забыть о ежеминутной (утрирую) переиндексации. Работа становится быстрой, удобной ;) И по сети плавает только то, что нужно ;) |
| ||
| Вот так рождаются слухи... :) |
| ||
| Поставим вопрос по другому :) При обновлении базы 1,3 Гб переиндексация идет 1ч 15-20 минут и это на двух-процессорной машине и гигом оперативки и рэйд-массивом. Что можно сделать в такой ситуации, что бы ускорить процесс. |
| ||
| Одной из причин является именно рэйд... при активном обмене информацией он такие тормоза заказывает...просто шляпа... кроме того при таких объемах базы все таки надо думать про СКЛ... это и сохранность.. и всё таки понятия реиндексация в классическом, ДБФном понимании там просто нет... |
| ||
| Ежели SQL версия, можно попробовать снести индексы(файлы)..... Пущай по новой создаст, думаю быстрее будет. |
| ||
| Не быстрее |
| ||
| Чего-чего снести, если это SQL-версия? :)))))))) Какие файлы???? |
| ||
| Виноват:))Сказал, не о том думал, пятница все-таки:)))) Это я о файлах, но снос индексов мне реально помогал. Это точно. Перестройка индексов занимала гораздо больше времени, чем их создание. |
| ||
| Быстрее не будет. И тут и там перестройка таблиц и индексов. Единственный путь - на SQL скорее, да машинку посерьезнее. |
| ||
| Охренеть... Переноси на sql хранилище твоей базы, а лучше оптимизировать конфигу и будет не 1.3 гига, а метров 400... :) Одно слово бухгалтерррр... :) |
| ||
| Ты пенсионер, :) это тебе не бананы с тампаксами два раза в день приходовать :) Сама по себе конфига быстро работает все траблы начинаются в момент проведения обновлений. Сворачивать ее можно только за год, т.к ключевые обороты считаются нарастающим с начала года. Короче полный 3,14здец :( Счас пойду еще на час завод остановлю :( |
| ||
| :) Шап, не смеши меня, сейчас умру... Если б у меня типовая конфа стоял база была бы не 1.3 гига, а 30. P.S. Не надо не останавливай завод, он скоро сам остановиться. К концу года у тебя бубет гига 2 dbf-ок вот и повеселишься... |
| ||
| Конечно тебе ПБУ соблюдать не надо. Короче, как всегда никто ничего путного не сказал, только подтвердили, что я поуши в дерьме. |
| ||
| Есть ли возможность руками поштучно пересоздать индексы? Или это не решает? |
| ||
| Руки для другого предназначены. |
| ||
| Ты ж, насколько знаю женат... P.S. А на счет путного, то лекарство одно ms sql, быстрее не станет работать (быстрее только отчеты), но без проблем держатся и работают большие объемы и кучка пользователей... Отчетиков можно порисовать через ado, чтоб побыстрей... Если что звони... |
| ||
| У меня в терминале все висят и все быстро работает, единственная проблемма в обновлениях. Точно с SQL переиндексация быстрее будет? |
| ||
| http://www.sql.ru/ |
| ||
| Быстрее станет работать только тогда, когда для версии SQL напишут нормальные оптимизированные SP, а не те, что там есть: select * from users_table Меня в свое время удивило то, что так сделано.. Проще, конечно, но... Кстати, люди, работающие с 1С, поинтересуюсь у вас - это уже переписано или пока так и осталось? |
| ||
| Дык 1совка sql server использует только как хранилище данных... Работает медленней (запись данных и проведение доков), отчеты токма работают быстрее (по регистрам)... В dbf отчетец (предположим) таскался по базе 2 ч 30 мнут, c sql базы спрашивает эти данные за 4.5 минуты... Кофига моя работает одна у меня в конторе (больше года) которая использует только sql server базу через ado, зато кривляется быстренько... хоть и объемы большие |
| ||
| Да, в версиях 7.5 и 7.7, SQL server используется только как хранилище данных, самое смешное, что вытаскивается вся таблица по select * from справочник, и выборка записыватеся локально в формате DBF, и в этих версиях принципиально ничего менять не будут. Вот в 8.0 вроде как движок переделали. |
| ||
| Притащили на завод 1С... Самый короткий анекдот. Ну не предназначено оно для такого. Да и сочетание 1C+MS-SQL+Citrix по деньгам выбивается далеко-далеко за допустимые для этой игрушки (1С) рамки. И живо оно до сих пор только потому что за Citrix денег никто не платит. |
| ||
| Вин2000 сервер - его цена удивительна ;) |
| ||
| Надо поставить Оракл набрать толпу программеров и ждать у моря погоды. |
| ||
| толпу программеров на ORACLE... Толпы не будет:) |
| ||
| Я понимаю, что ничего не будет, а только Оракл и программер. |
| ||
| Oracle и программер не имеет отношения к задаче, потому что оба нужны для поддержки работоспособности промышленной системы автоматизации от стороннего производителя. |
| ||
| А тебе надо молиться чтобы переиндексация быстрее шла и ругать админов, которые все идиоты потому что ругают 1С. Стандартный совет: Ставь на отдельный сервер MS-SQL и как можно быстрее на него переползай. 100 мегабит выделенные от него к терминальному серверу. На сервер с MS-SQL быстрые scsi-диски (10k) - 4 штуки. RAID 0+1 софтовый или аппаратный (никаких raid-5, потому что софтовый - тормоз, дешевые контроллеры - дрянь и тоже тормозные, дорогой контроллер обойдется дороже чем поставить кучу дисков и RAID 0+1). Если 100 мегабит не хватит заменить на гигабит, они уже достаточно дешевые. Никакого доступа к MS-SQL напрямую из 1С с клиентов, только через терминальный сервер. Отчеты большие писать целиком в MS-SQL как полагается, с хранимыми процедурами т.д. и вытаскивать их в 1С, а не пользоваться для обработки больших объемов данных 1С-ными средствами. Может и поживешь еще годик-другой, а там может и 1Совские программисты сотворят более-менее работающую версию под SQL. PS. Ну нельзя чтобы нахаляву волосы стали мягкими и шелковистыми. PPS. А Win2000 как терминальный сервер можно далеко не везде использовать ( если периферия к терминалам подключена без Citrix-а никак). |
| ||
| Хватит меня грузить насчет отчетов и.т.д Мне надо решить одну проблему ПЕРЕИНДЕКСАЦИЯ. Я так понял, что в SQL она быстрее не будет? |
| ||
| Тебе пытаются объяснить что ее не будет в принципе. |
| ||
| 2RH. проблемы не станет когда оптимизируешь конфигу. Ни какие sql сервера с терминалками и т.д. не помогут... p.s. у меня p-2 350, 128 памяти, два харда ide, 3 сетевушки и три свича,16 юзверей (11 очень активных) в сетке и ни каких тормозов и проблем с переиндесацией... |
| ||
| Ну как ты ее оптимизируешь, что бы меньше индексов было? |
| ||
| нву здрасте... графы отбора, спризнак сортировки и т.д. да просто длину поля покороче сделать уже ресурсов поменьше требует. да дохрена всего можно сделать (к т.ч. и базу уменьшить в размерах сильно) , ты б лучше позвонил, а то писать как конфу оптимизировать пальцы сотру... |
| ||
| Ну не будет ее и все. Не делает этого сервер. ну не рушит он базу, когда рухает клиент. Откатится транзакция - ты даже и не заметишь. |
| ||
| Переиндексация идет не когда падает база, а в момент изменения структуры метаданных. |
| ||
| Согласен Patrol-ом! |
Отправил