| Автор | Сообщение | ||||
|---|---|---|---|---|---|
| Удалён Гость |
Добавлено: 05.05.2005 16:31 Заголовок сообщения: проблема "порванных" проводок и переход на iScala Собрались переходить со Scala 5.1 на iScala 2.2. Решена ли в iScala проблема порванных проводок, когда аналитика по SL,PL записывается в таблицу, а проводка в журнал нет? И еще вопрос тем, кто делал конвертацию 5.1 -> 2.2. |
||||
| aav Администратор 
Зарегистрирован: 14.09.2004 |
Добавлено: 05.05.2005 16:53 Заголовок сообщения: Re: проблема "порванных" проводок и переход на iSc
|
||||
| Удалён Гость |
Добавлено: 05.05.2005 17:06 Заголовок сообщения: 750 Gb — это размер базы scalaDB на SQL Server 2000 64-bit. Основной размер его составляет таблицы SL03xx00, SL21xx00, т.е. аналитика по счетам и платежам клиентов, которая годонезависима и подлежит обязательной конвертации. По поводу отдельной конвертации по годам и компаниям, на тренинге в Scala было сказано что хотя конвертор и позволяет выбрать отдельные компании для конвертации, процесс идет по всем компаниям. По времени что-нибудь можете сказать и как еще изменится размер базы, т.к. в iScala varchar поля unecode? |
||||
| vome Народный форумщик 
Зарегистрирован: 17.09.2004 |
Добавлено: 05.05.2005 17:26 Заголовок сообщения:
У нас при конвертации в начале 2004г., на двухпроцессорном P III 1000 SCSI Raid 5 с 2Gb Ram 6-ти Гигабитная база конвертилась около 5-6 часов ночью, размер увеличился на 15-18% |
||||
| Jugulator Главный форумщик Зарегистрирован: 08.10.2004 |
Добавлено: 05.05.2005 18:32 Заголовок сообщения: 1. Если много фин. лет, то нужно использовать версии конвертера, где исправлен баг #65154, когда годы для конвертации берутся из SY150000, а не все имеющиеся в базе. Баг описал Taras Reshetilov — так написано, исправлено в конце 2004 г. 2. Время конвертации у нас было 4Gb базы данных за 2 часа, но при объеме базы в 750Gb это ни о чем не говорит. Я бы попробовал засунуть в тестовую базу необходимый набор таблиц SY (можно просто создать пустую скальскую базу и завести компанию-год) и самую большую таблицу из живой базы и натравил бы на эту мини-базу конвертер. Поскольку конвертер обрабатывает таблицы последовательно, то на этом примере хоть как-то можно сориентироваться, что ожидать. 3. Рост базы не более 30-40%. |
||||
| aav Администратор
Зарегистрирован: 14.09.2004 |
Добавлено: 06.05.2005 07:59 Заголовок сообщения: Кто о чем, а я все про анализ размеров У нас рабочая (без ScaSystemDB) база 9 GB (и близко не "лежала" с Вашей), и это уже 2.2 Однако это, если смотреть ее свойства "целиком". Более подробный анализ показывает, что часть этого пространства занимает Transaction Log, который при определенных параметрах базы может разрастаться до невероятных размеров, в свое время, когда мы экспериментировали с различными параметрами возможного интервала восстановления (уже пройденный период) он достигал десятков (а может и сотен, уже не помню) GB. А если посмотреть на сами таблицы, то и здесь можно обнаружить интересные примеры того, что таблица занимает много больше места, чем реальные данные в ней, ну, например:
Но в итоге я согласен с предыдущим оратором, что без эксперимента не обойтись. В любом случае задачка Вам предстоит интересная, особенно в связи с тем, что у Вас, наверное, все online |
||||
| Удалён Гость |
Добавлено: 06.05.2005 09:25 Заголовок сообщения: Объем базы MS SQL, как я уже писал, 750 Gb и каждый месяц увеличивается на ~20Gb, размер лога базы небольшой, т.к. база бекапится каждый час и лог шринкится. Каждый месяц делается шринк всей базы, т.е. свободного места в ней практически нет. Количество записей в таблицах SL03, SL21, GL06 >100 млн. Так что оптимизировать базу на уровне SQL уже некуда. Работа с базой 24×7. Из-за большого объема пришлось отказаться от многих возможностей Скалы, из-за их длительности. А где можно взять последнюю версию конвертера на iScala 2.2? |
||||
| aav Администратор
Зарегистрирован: 14.09.2004 |
Добавлено: 06.05.2005 09:47 Заголовок сообщения: Тут надо искать какие-то обходные пути Не знаю, насколько это для Вас приемлемо, но мне видится, что возможным выходом из ситуации было бы «обрезание» SL03, SL21. GL06 он сам по себе стандартным путем «режется» по годам. Если поступить аналогичным образом с SL03 и SL21, перенеся историю в другую базу, это, может быть, чуть-чуть упростило бы задачу. |
||||
| Удалён Гость |
Добавлено: 06.05.2005 09:55 Заголовок сообщения: Если перенести аналитику SL03 и SL21 в другие таблицы как тогда стоить отчеты по задолженностям клиентов? Для них нужна вся история счетов и платежей. А GL06 и так по годам разбита, просто в одном году порядка ~200 млн. записей в GL06xx04. |
||||
| aav Администратор
Зарегистрирован: 14.09.2004 |
Добавлено: 06.05.2005 10:09 Заголовок сообщения:
|
||||
| Удалён Гость |
Добавлено: 06.05.2005 10:29 Заголовок сообщения: Нет конечно, стандартные скальские отчеты уже в текущей работе давно не используются. Но для аудиторов нужно чтобы некоторые отчеты печатались из скалы (требование SOX 404). Поэтому отчеты из скалы должны полностью совпадать с внешними. |
||||
| aav Администратор
Зарегистрирован: 14.09.2004 |
Добавлено: 06.05.2005 11:12 Заголовок сообщения: ну, аудитор, погоди…
Весело Вам живется. |
||||
| Удалён Гость |
Добавлено: 06.05.2005 11:20 Заголовок сообщения: Возможно если перейдем на iScala, что-нибудь придумаем… Так все таки, где взять последнюю версию конвертера scala 5.1-> iScala 2.2? |
||||
| Jugulator Главный форумщик Зарегистрирован: 08.10.2004 |
Добавлено: 06.05.2005 16:18 Заголовок сообщения: Конвертер находится в папке Tools\ScaDBConv после установки iScala 2.2. Нужно установить iScala 2.2 SR1, потом установить один из последних хотфиксов (последний был iScala 2.2 SR1 Hot Fix 2351, 17 Apr 2005). |
||||
| Удалён Гость |
Добавлено: 13.05.2005 18:03 Заголовок сообщения:
|
||||
| Удалён Гость |
Добавлено: 14.05.2005 09:16 Заголовок сообщения: у нас поле GL06016 содержит значение ‘000000’, т.к. большинство записей в GL06 кладутся внешними процедурами, в частности обновление журналов GL07, SL04, SL05 и пр.. Внешние процедуры обновления приходится использовать,т.к. скала за 1 сек обновляет не более 3-5 проводок (использует курсор), и ежедневное обновление нескольких тысяч проводок занимает очень много времени. Первичниый ключ на поле GL06016 убит. |
пользователям ERP систем Scala 5.1, iScala 2.2, iScala 2.3, iScala 3.0, iScala 3.1, iScala 3.2, iScala 3.3, iScala 3.4, iScala 3.5
А это размер базы, размер данных или размер файла SQL’ного журнала транзакций? Потом, Вы собираетесь переносить все компании и все финансовые года? Достаточно часто бывает куча тренировочных данных в тренировочной компании, которую вовсе не обязательно переносить. А кроме того данные за предыдущие годы, которые Вы не собираетесь корректировать можно и не переносить, оставив их в том виде, в каком они есть сейчас, только для использования во внешних отчетах.
С ними лучше не спорить.
|
|
|
