Перевод 1С+PostgreSQL на х64- Территория 1С

Гость

0 - 20.02.2013 - 12:26

Добрый день.
На данный момент используем связку Win2008x64+ Сервер 1С х32 + PostgreSQL 8.4.3 х32. Баз около 10.

В настоящее время наблюдаются проблемы с быстродействием, а так же нет возможности бэкапить базы средствами PostgreSQL. Так же, некоторые базы, выгруженные в dt не загружаются на сервер, а только в файловый вариант (out of memory).

Планируем установить PostgreSQL 9.1.2-1.1C х64 и Сервер 1С х64.

Каким образом с наименьшими проблемами осуществить переход? Выгрузить все базы в dt, снести 32хбитные PostgreSQL и Сервер 1С, установить 64хбитные PostgreSQL и Сервер 1С? Или что то можно накатить сверху?

Просто опасаюсь, снеся всё словить ошибку загрузки из dt и остаться у разбитого корыта.

Гость

1 - 20.02.2013 - 13:37

на виртуалке попробовать сначала

Гость

2 - 20.02.2013 - 21:53

а почему из постгреса не бекапится?

Гость

3 - 21.02.2013 - 00:46

MS SQL Express, если размер баз позволяет.

Гость

4 - 21.02.2013 - 04:23

1-Jimbo > На виртуалке попробовать, это нужно пинкод истратить в программном ключе. А у нас уже один истрачен, один нужен для установки х64 сервера, плюс в ближайшее время будем винты добавлять в сервак - а значит ещё один заюзать нужно будет. Придётся на поклон к 1С идти за следующей порцией пинкодов.

Гость

5 - 21.02.2013 - 04:23

2-angro > Потому что базы - УПП. И там в таблице config есть запись размером больше 120Мб - конфигурация поставщика. Postgre при бэкапе выдаёт ошибку.

Гость

6 - 21.02.2013 - 04:32

3-Пудель > Не позволяет.

Гость

7 - 21.02.2013 - 12:09

А что за железяка на чем все это размещается? Я согласен Jimbo. Можно попробовать с виртуальной машинкой. В идеале поставить вмваре, конвертировать Уин2008Х32 в виртуальную среду. Развернуть вторую машинку на Уин2008Х64. Не самый простой способ, но потом будет более гибкий и надежный. И при расширении дисковой подсистемы в дальнейшем париться не будете. Если что то не пойдет, то можно и на 32 разряда вернуться. А на время тестов можно и другой ключик поискать. Только с майкрософтовской виртуалкой не связывайтесь.

Гость

8 - 21.02.2013 - 12:21

(4)ну пин код необязательно, куча ломалок сейчас

Гость

9 - 21.02.2013 - 12:27

на 2008R2 Hyper-V делали, тестили, всё норм

Гость

10 - 21.02.2013 - 12:40

То же делали, тестили, но вмваре с файловой одинэсиной пошустрее в работе оказалась. К нам в контору аудит от майкрософта приходил. Мы их озадачили что скорость работы с одинэской гораздо ниже чем у их главного конкурента. Их админы после недели веселухи с сервером обратное доказать несмогли. Сервер для тестов брали 2-х процессорный на Xeon E5-2690. Рейд на 12 винтов десятка.

Гость

11 - 21.02.2013 - 13:21

файловый вариант - несерьезно

Гость

12 - 21.02.2013 - 13:22

купите MS SQL, а не жоптьесь

Гость

13 - 21.02.2013 - 13:24

25 т.р. стандарт

Гость

14 - 21.02.2013 - 18:47

Купить УПП + ключь на сервер (молчу про 10 баз, надеюсь что это ОДНА организация) и зажатьь чуток для мс-скл.... нет слов.

oops!

15 - 22.02.2013 - 05:00

(14) +100500 к тому в (0) говориться и о 64-битном сервере тоже, впрочем стоимость 64x-сервера в сравнении со стоимостью УПП - ничто, но это оффтоп :)
----
ну а по теме - были у меня подобные траблы, причем по причине в (5) и в dt выгрузка базы тоже не шла (аналогично (0) база тоже была УПП). Чтобы поработать с базой "дома", приходилось паковать mdf+ldf (сервер был MSSQL 2K5 32бит) и цеплять их дома к 64-битному серверу.
А вот обратная операция (загрузка базы на 32-бит SQL) делалась след.образом:
1. Из "домашней" базы сначала сохранялся cf поставщика.
2. База данных полностью снималась с поддержки.
3. Выгрузка в dt.
4. Загрузка dt на исходный 32-битный SQL сервер.
5. Загрузка сохраненной конфигурации поставщика с восстановлением поддержки.
Вот и всё собственно.
Если есть необходимость сохранить в dt базу с 32-битного SQL сервера, то действия аналогичные:
Снять полностью с поддержки и сделать выгрузку (дальше потом так и делал, потому как все необходимые изменения/дописки делались на "домашнем" 64x SQL сервере).
Не знаю, как там на PostgreSQL 64x, но, на MSSQL 64x, проблемы, описанной в (5) точно нет, это проверено. Думаю, что на PostgreSQL 64x её тоже быть не должно.

Гость

16 - 22.02.2013 - 05:17

7-Фокусник > Xenon 2.4GHz, 32 Гб оперативы
Винда и так уже х64. Виртуализация в планах, но не в ближайшем времени.
> Только с майкрософтовской виртуалкой не связывайтесь.
Всё так плохо?

8-angro >На боевом серваке с ломалками связываться - ну его нафиг.

13-Jimbo >Нуда, нуда... А лицензии на клиентов покупать как бы и не обязательно, да? Выйдет несколько больше 25тр, нес па?

14-Viking >Организация одна, юрлица разные, в чём проблемы?
Если у вас нет слов, то можно было бы и промолчать. Были заданы конкретные вопросы, сентенции о смысле жизни идут лесом.

Гость

17 - 22.02.2013 - 05:24

15-oops! >Да, уже попробовал, воткнул PostgeSQL х64 на другой сервак, подключил базу к x32 Серверу предприятия, всё работает нормально, база бэкапится и загружается из dt без проблем.

Гость

18 - 22.02.2013 - 09:38

(5)
Нечто подобное было у меня. Решилось переходом на связку Linux+1С+PostgreSQL. Позже выяснилось, что было еще одно решение - обновление версии PostgreSQL, но почему-то на тот момент ни в одной из документаций от 1С я не нашел четкого указания на минимальную версию PostgreSQL и в ответах на заданный мной вопрос такие рекомендации отсутствовали.
(16)
>> Виртуализация в планах, но не в ближайшем времени.
А зря. В числе многих прочих достаточно серьезных вопросов успешно решается вопрос подъема "небоевого" сервера без покупки доп.железа.
>> Организация одна, юрлица разные, в чём проблемы?
Сам-то понял, что сказал? :)
Проблема в том, что:
- либо часть "разных юр.лиц" - те, у кого нет соответствующих документов, использует ПО незаконно
- либо владельцы ПО оказывают услуги по ведению учета/сдают софт/софт+хард в аренду не-владельцам и для законности такого способа нужны соответствующие записи в соответствующих документах, а также платежки и акты, соответственно уплаченные налоги и протчая и протчая.
Так или инаяе таких вот умных и берут за теплое вымя компетентные органы.
Это я не к тому, что нада покупать MS SQL, мой выбор в ситуации - PostgreSQL.

Гость

19 - 22.02.2013 - 10:26

18-СоболиныйГлаз > - либо часть "разных юр.лиц" - те, у кого нет соответствующих документов, использует ПО незаконно

А вот фирма 1С другого мнения:
5. В одной Организации деятельность ведется от двух юридических лиц с разным режимом налогообложения в двух информационных базах. Все пользователи работают в одной локальной сети. Сколько основных поставок обязана приобрести организация?
Ответ: Поскольку компьютеры связаны в локальную сеть, то по правилам Лицензионного соглашения достаточно приобрести одну основную поставку и клиентские лицензии на рабочие места. Число основных поставок не зависит от числа информационных баз и числа юридических лиц.
http://v8.1c.ru/predpriyatie/questions_licence.htm

Гость

20 - 23.02.2013 - 19:49

(19)Ню-ню. Только попробуй попытать юристов - сам ты в этих вопросах явно не рубишь - что такое "организация" если не "юр.лицо".
Одно юр.лицо может купить 1 поставку и законно обслуживать хоть миллион других юр.лиц прямо или сдавать в аренду рабочие места с ПО, в т.ч. и от 1С. Но при этом нужны соответствующие документы. В случае типичных "одной организации и нескольких юр.лиц" это не так.
И еще один момент - дело тебе, в случае чего, будет "шить" не фирма 1С и тем, кто это будет делать, на мнение фирмы 1С, по большому счету, наплевать. И ты можешь спорить с этими ребятами хоть до усрачки - тебя попросту задавят положениями законов, которые ты, судя по "одна организация - много юр.лиц", понимаешь не совсем так, как понимают компетентные органы.
На этом заканчиваю - спорить с полуграмотными школярами не доставляет мне особого удовольствия.

Гость

21 - 24.02.2013 - 12:31

(20) ППКС.... ну и до кучи http://yandex.ru/yandsearch?text=%D1...61&lr=35&msp=1
2-х первых пунктов достаточно чтобы сделать выбор между постгре и мс...

Гость

22 - 24.02.2013 - 12:41

21-Viking > Между постгрес и мс я выбираю IBM :ь

Гость

23 - 24.02.2013 - 14:04

(21)Недостаточно. Если ты в том или ином виде используешь "левый" MS SQL, то для тебя всё равно, сколько стоит полностью легальный комплект лицензий.
Но если это не так, то для варианта на 50 пользователей, а если УПП применяется по назначению, то это совсем немного, минимальные затраты на MS SQL сервер - под 200 тысяч. В варианте, когда используется несколько SQL-серверов - больше.
Кстати, сразу возникает вопрос о том, использует-ли и если да, то насколько хорошо, УПП управляемые блокировки.
Если же учесть, что использованеи MS Windows Server само по себе тоже стоит немалых денег(лицензии на сервер и CAL ), то разница между связкой MS Win + MS SQL и Linux + PostgreSQL в деньгах возрастает еще существеннее.
Да, мне сейчас скажут, что для Linux нужен пингвиновод-гуру. Согласен, но на самом деле не всё обстоит так плохо, особенно в случае использования виртуализации и нормальном резервном копировании.
Более того, разницу в деньгах вполне можно направить на более шустрое железо.
Кроме того, PostgreSQL - хотя и бесплатен, но далеко не явялется "несерьезным" продуктом, каким его могут представить неосведомленные люди. К примеру, для него существуют решения, позволяющие создавать кластеры SQL-серверов.
Честно говоря, используя PostgreSQL сам, не заметил его какой-то особенной, по сравнению с MS SQL, геморройности.
(22)Ограничения "халявного" IBM-овского решения не забыл? До 2 ядер и до 2 ГБ оперативки. Что это значит в приложении к УПП, надеюсь уж тебе-то объяснять не надо? :)
Если же берем не "халявное" решение, то получаем в полный профиль те же ценовые яйца, что и для MS + проблемы с тем, что спецов по DB2 на 2-3 порядка меньше, чем по MS SQL и, ИМХО, меньше, чем по PostgreSQL.

Гость

24 - 24.02.2013 - 14:12

Цитата:

Сообщение от СоболиныйГлаз

Если же берем не "халявное" решение, то получаем в полный профиль те же ценовые яйца, что и для MS

Вообще то IBM дороже, причем значительно ;)

Гость

25 - 25.02.2013 - 08:04

(24)Говоря "те же ценовые яйца" я подразумевал дороговизну, а не близость цен :)

Гость

26 - 25.02.2013 - 08:06

ребята, оракл кто юзал-покупал ?

Гость

27 - 25.02.2013 - 09:10

Цитата:

Сообщение от СоболиныйГлаз

Так или инаяе таких вот умных и берут за теплое вымя компетентные органы.

в серьезные конторы с такой ерундой не приходят. а кто знает, что могут прийти - разумеется страхуется, делая все соответствующие договора и акты вовремя.

Гость

28 - 25.02.2013 - 09:23

20-СоболиныйГлаз >Может не стоит огульно ярлыки навешивать?
>И еще один момент - дело тебе, в случае чего, будет "шить" не фирма 1С и тем, кто это будет делать, на мнение фирмы 1С, по большому счету, наплевать. И ты можешь спорить с этими ребятами хоть до усрачки - тебя попросту задавят положениями законов, которые ты, судя по "одна организация - много юр.лиц", понимаешь не совсем так, как понимают компетентные органы.
Мне никто и ничего шить не будет, и уж тем более я ни с какими "ребятами" спорить не буду. Есть ЮрОтдел, которому в свое время был поставлен вопрос о правомочности использования одной поставки на несколько юридических лиц. Ответ получен положительный. Всё, у меня голова на этот счет не болит. Есть начальник отдела, есть руководитель организации - это зона их ответственности.
А по поводу договоров - естественно они есть между юрлицами. И налоги все платятся, от которых увильнуть не получается ;)

Гость

29 - 25.02.2013 - 09:33

18-СоболиныйГлаз > А в связке Linux+1С+PostgreSQL версия PostgreSQL была той же, но проблема исчезла?

А как переносили базы на другой сервер СУБД? Через .dt? А то у меня на этом этапе всё застопорилось. Через dt переносить боязно, судя по всему, есть шанс что не всё перенесётся, а через Postgre не удаётся бэкапить.

Гость

30 - 27.02.2013 - 07:36

(29)Да. Исчезла. Переносил через dt.

Гость

31 - 27.02.2013 - 07:39

(29)Ни разу не слышал о случае, когда бы через dt перенеслось не всё. Разве что dt делался с базы, где уже были проблемы.