Вход | Регистрация

  1  2   
1С:Предприятие :: Администрирование

Как вы повышаете отказоустойчивость базы 1С и снижаете даунтайм?

Как вы повышаете отказоустойчивость базы 1С и снижаете даунтайм?
Я
   mrWatson
 
15.01.13 - 10:52
5. Другое57% (4)
1. Ежедневный бакап14% (1)
2. Зеркало14% (1)
4. Бубен14% (1)
3. Доставка логов0% (0)
Всего мнений: 7

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

Расскажите ваш опыт.

База 200Гигов + MS SQL 2005 SP4

Приходу к мысле что ежедневный бакап не достаточен.
 
 
   mrWatson
 
1 - 15.01.13 - 10:53
* прихожу к мысли
   ДенисЧ
 
2 - 15.01.13 - 10:53
"Бакап восстанавливается довольно долго до нескольких часов"
винты меняй. Делай разностные бекапы. Организовывай зеркалирование.
   Lama12
 
3 - 15.01.13 - 10:55
(0) А что хочет бизнес?
Можно зеркальные бэкапы делать. Только это дорогое удовольствие :)
   Lama12
 
4 - 15.01.13 - 10:56
(0)Бизнес готов платить за восстановление системы в течении 3 минут?
   Fragster
 
5 - 15.01.13 - 10:56
(0) сделай 2 базы в полный РИБ на разных серверах. одна отвалится - будут на другой работать.
   Fragster
 
6 - 15.01.13 - 10:56
вообще - нормальный дисковый массив - и все будет ОК.

2. Зеркало
   Fragster
 
7 - 15.01.13 - 10:57
все равно он не отменяет еженедельный + разностный по дням

1. Ежедневный бакап
   Fragster
 
8 - 15.01.13 - 10:57
(2) это не поможет, если база 1тб
   mrWatson
 
9 - 15.01.13 - 11:01
массив рейд, сервера стоечные всё как доктор прописал, но база засуспектилась к счастью это было не в рабочий день, был свежий бакап


DBCC CHECKDB
....
Table error: Object ID 1113471441, index ID 4, partition ID 72057686612705280, alloc unit ID 72057686504243200 (type In-row data). Parent node for page (1:29277942) was not encountered.
Msg 8978, Level 16, State 1, Line 1
Table error: Object ID 1113471441, index ID 4, partition ID 72057686612705280, alloc unit ID 72057686504243200 (type In-row data). Page (1:29277944) is missing a reference from previous page (1:28792043). Possible chain linkage problem.
Msg 8951, Level 16, State 1, Line 1
Table error: table '_AccumRg20041' (ID 1113471441). Data row does not have a matching index row in the index '_Accum20041_ByProperty20064_RTRN' (ID 5). Possible missing or invalid keys for the index row matching:
Msg 8955, Level 16, State 1, Line 1
Data row (1:2427358:19) identified by (_Period = '2012-01-31 23:59:59.000' and _RecorderTRef = 0x000001E9 and _RecorderRRef = 0x8AB318A905522C0811E14FB16253C15F and _LineNo = 1108890.) with index values '_Fld20059RRef = 0xAF8FD74FE72282924EBDCC337C30F511 and _Period = '2012-01-31 23:59:59.000' and _RecorderTRef = 0x000001E9 and _RecorderRRef = 0x8AB318A905522C0811E14FB16253C15F and _LineNo = 1108890.'.
There are 60595529 rows in 2634616 pages for object "_AccumRg20041".
   Lama12
 
10 - 15.01.13 - 11:02
(8) Почему же?
Можно же держать штук 20 полнофункциональных копий баз которые создаются автоматически через определенный промежуток времени (допустим раз в 3 минуты), и создаются только в момент завершения транзакции и до начала следующеей.
В случае аварии основной базы, система переключается автоматически на предыдущую копию базы. Займет это как раз около 1-2 минут.
Только если по хорошему делать, то это как минимум 3 географически разнесенных здания. Между ними широкий канал, и спец оборудование.
Дооорого....
 
 Рекламное место пустует
   acsent
 
11 - 15.01.13 - 11:03
для начала нужен кластер
   Нуф-Нуф
 
12 - 15.01.13 - 11:07
Больше денег -> Меньше времени на восстановление
Меньше денег -> Больше времени на восстановление

Выбор за бизнесом, епта
   fisher
 
13 - 15.01.13 - 11:41
(0) Единственное, что приходит в голову - репликация. Любые зеркала и супер-пупер рэйды - это снижение вероятности падения, а не сокращение даунтайма.
С другой стороны, организовать нормально репликацию на больших объемах и потоках и настроить "горячую замену" - задача не для бедных и слабых духом. Да и вообще - куча проблем.
Я бы всё-таки сосредоточился на минимизации вероятности падения и потерь данных. А даунтайм - разумными путями минимизировал насколько мог. Без фанатизма. Чай не ядерный реактор, чтобы падение раз в несколько лет на несколько часов было смертельным делом.
   MaxS
 
14 - 15.01.13 - 11:48
(0) Разработать процедуру бумажного документооборота, обучить пользователей способам ввода информации посредством ручки на бумагу.
После восстановления БД, пользователь должен суметь перенести данные с бумаги в БД.

Или если упало не всё, тоже самое организовать с использованием MS Office.
Руками вбивать данные и выводить на печать.
Должны быть заготовлены все необходимые формы и шабоны документов.

5. Другое
   rs_trade
 
15 - 15.01.13 - 11:50
(8) Изменений за день тоже на террабайт будет?
   rs_trade
 
16 - 15.01.13 - 11:55
(9) Если на восстановление 200 гиг уходит несколько часов, то явно у вас что то не так. Доктора так не прописывают.
   mrWatson
 
17 - 15.01.13 - 11:59
(16) из 7z распаковка минут 40 далее раскрытие bak файла около часа
   mrWatson
 
18 - 15.01.13 - 11:59
(16) но основной минус что бак будет по состоянию на утро и изменеия тек дня пропадут
   rs_trade
 
19 - 15.01.13 - 12:01
(17) Жмите встроенными средствами скуля.

(18) Стратегия резервирования данных какая?
   ptiz
 
20 - 15.01.13 - 12:01
(14) Хотел бы я посмотреть, как с помощью бумаги можно обработать электронные заявки клиентов :)
   mrWatson
 
21 - 15.01.13 - 12:02
(5) а РИБ умеет кидать большие движения? например от документа расчет себестоимости..на моей памяти была ошибка "Недостаточно памяти" платформа была тогда еще 8.2.13
   fisher
 
22 - 15.01.13 - 12:02
(9) А вот такая фигня требует тщательного расследования. С бухты-барахты такое имеет крайне малую вероятность. Как минимум - настрой ТЖ, если до сих пор не догадался. Настрой и анализируй все доступные логи.
ЗЫ. Кстати. Самый простой вариант репликации - можно бэкапить транзакции каждый час и на резервном сервере БД заскриптовать актуализацию резервной копии. Чтобы автоматом поднимался полный бэкап и накатывались бэкапы журнала транзакций. В любом случае нужно разоряться на резервный сервер БД если хочешь горячую замену. И резервный сервер 1С.
   rs_trade
 
23 - 15.01.13 - 12:03
(18) Гыы.. вы раз в сутки что ли фулл делаете и все?
   mrWatson
 
24 - 15.01.13 - 12:04
(19) у нас стратегия простая так как в SQL администрировании  шибко никто не шарит, делаем каждый вечер полный бакап зипуем и складываем на отдельный сервер
   rs_trade
 
25 - 15.01.13 - 12:05
(24) Тогда читайте книжки по ms sql и будет вам счастье в виде восстановления базы в течении минут 15.
   mrWatson
 
26 - 15.01.13 - 12:05
(22) да это и есть лог шиппинг или доставка логов, читал об этом но практики нет

сейчас модель записи логов симпл
   rs_trade
 
27 - 15.01.13 - 12:06
(24) Не гоже имея 200-гиговую базу не знать про разностные и бекапы лога транзакций.
   mrWatson
 
28 - 15.01.13 - 12:07
(25)(27) да, пробелы надо закрывать
если есть хорошие ссылки на статьи сообщите, спасибо
   artems
 
29 - 15.01.13 - 12:09
(0) 10 рейд из 8 ssd дисков. Восстановление БД (50 ГБ) занимает чуть более 1 минуты. На корзине из sas дисков эта же база восстанавливается не более 5 минут. Смотри свой массив дисковый :)
   Sorm
 
30 - 15.01.13 - 12:10
(0) 200 ГБ несколько часов?:) Меняй оборудование. 192 ГБ из ближайших ко мне баз - 20 минут.
   rs_trade
 
31 - 15.01.13 - 12:10
   prog0101
 
32 - 15.01.13 - 12:14
три задания 
лог часто
разностная реже
полная 1 раз в сутки
хранить там же чтобы не тащить несколько часов по сети
а в сеть класть чтобы мало ли что и осталось
можно ещё сжатие чек и прочее по мелочи добавить

Копирование UPP Log

declare @n varchar(1000)
select @n = 'G:\AVTOBACKUP\FULL\UPP\UPP_backup_log ' + REPLACE(convert(varchar, getdate()), ':', '') + '.bak' 
select @n = rtrim(@n)
BACKUP LOG [UPP] TO  DISK = @n
GO

declare @n varchar(1000)
select @n = 'G:\AVTOBACKUP\\FULL\ACC\ACC_backup_log ' + REPLACE(convert(varchar, getdate()), ':', '') + '.bak'
select @n = rtrim(@n)
BACKUP LOG [ACC] TO  DISK = @n
GO

declare @n varchar(1000)
select @n = 'G:\AVTOBACKUP\FULL\SunLightAcc\SunLightAcc_backup_log ' + REPLACE(convert(varchar, getdate()), ':', '') + '.bak'
 select @n = rtrim(@n)
BACKUP LOG [SunLightAcc] TO  DISK = @n
GO

declare @n varchar(1000)
select @n = 'G:\AVTOBACKUP\FULL\SunLightRetail\SunLightRetail_backup_log ' + REPLACE(convert(varchar, getdate()), ':', '') + '.bak'
 select @n = rtrim(@n)
BACKUP  LOG [SunLightRetail] TO  DISK = @n
GO



--Копирование разностное

declare @n varchar(1000)
select @n = 'G:\AVTOBACKUP\FULL\UPP\UPP_backup_diff ' + REPLACE(convert(varchar, getdate()), ':', '') + '.bak' 
select @n = rtrim(@n)
BACKUP DATABASE [UPP] TO  DISK = @n WITH  DIFFERENTIAL
GO

declare @n varchar(1000)
select @n = 'G:\AVTOBACKUP\\FULL\ACC\ACC_backup_diff ' + REPLACE(convert(varchar, getdate()), ':', '') + '.bak'
 select @n = rtrim(@n)
BACKUP DATABASE [ACC] TO  DISK = @n WITH  DIFFERENTIAL
GO

declare @n varchar(1000)
select @n = 'G:\AVTOBACKUP\FULL\SunLightAcc\SunLightAcc_backup_diff ' + REPLACE(convert(varchar, getdate()), ':', '') + '.bak'
 select @n = rtrim(@n)
BACKUP DATABASE [SunLightAcc] TO  DISK = @n WITH  DIFFERENTIAL
GO

declare @n varchar(1000)
select @n = 'G:\AVTOBACKUP\FULL\SunLightRetail\SunLightRetail_backup__diff ' + REPLACE(convert(varchar, getdate()), ':', '') + '.bak'
 select @n = rtrim(@n)
BACKUP DATABASE [SunLightRetail] TO  DISK = @n WITH  DIFFERENTIAL
GO

DBCC FREEPROCCACHE
go

-- полное


use [UPP]
go

--sp_msforeachtable N'DBCC INDEXDEFRAG (upp_prog1, ''?'')'
sp_msforeachtable N'DBCC DBREINDEX (''?'')'
go

exec sp_msforeachtable 'UPDATE STATISTICS ? WITH FULLSCAN'
go

DBCC SHRINKDATABASE(N'UPP' )
GO

DBCC SHRINKFILE (N'UPP' , 0, TRUNCATEONLY)
GO
--------------------------------------------------------------------------------------------------------------------------
use [ACC]
go

--sp_msforeachtable N'DBCC INDEXDEFRAG (upp_prog1, ''?'')'
sp_msforeachtable N'DBCC DBREINDEX (''?'')'
go

exec sp_msforeachtable 'UPDATE STATISTICS ? WITH FULLSCAN'
go

DBCC SHRINKDATABASE(N'ACC' )
GO

DBCC SHRINKFILE (N'ACC' , 0, TRUNCATEONLY)
GO
--------------------------------------------------------------------------------------------------------------------------
DBCC FREEPROCCACHE
go

---------------------------------------------------------------------------------------------------------------------------------

declare @n varchar(1000)
select @n = 'G:\AVTOBACKUP\FULL\UPP\UPP_backup_FULL ' + REPLACE(convert(varchar, getdate()), ':', '') + '.bak'
select @n = rtrim(@n)
BACKUP DATABASE [UPP] TO  DISK = @n
GO

declare @n varchar(1000)
select @n = 'G:\AVTOBACKUP\\FULL\ACC\ACC_backup_FULL ' + REPLACE(convert(varchar, getdate()), ':', '') + '.bak'
select @n = rtrim(@n)
BACKUP DATABASE [ACC] TO  DISK = @n
GO

declare @n varchar(1000)
select @n = 'G:\AVTOBACKUP\FULL\SunLightAcc\SunLightAcc_backup_FULL ' + REPLACE(convert(varchar, getdate()), ':', '') + '.bak'
select @n = rtrim(@n)
BACKUP DATABASE [SunLightAcc] TO  DISK = @n
GO

declare @n varchar(1000)
select @n = 'G:\AVTOBACKUP\FULL\SunLightRetail\SunLightRetail_backup_FULL ' + REPLACE(convert(varchar, getdate()), ':', '') + '.bak'
 select @n = rtrim(@n)
BACKUP DATABASE [SunLightRetail] TO  DISK = @n
GO
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 xp_cmdshell 'del G:\AVTOBACKUP\*log*.* /q /s'
go
xp_cmdshell 'del G:\AVTOBACKUP\*diff*.* /q /s'
go
   prog0101
 
33 - 15.01.13 - 12:15
удаление спецом не писал чтобы удаляя ручками удостовериваться тому что копии делаются
 
 
   Sorm
 
34 - 15.01.13 - 12:17
(32)+ "DBCC FREEPROCCACHE" - а он есть в случае 1с?:)
   prog0101
 
35 - 15.01.13 - 12:18
(9)(22)"А вот такая фигня требует тщательного расследования"
+100500
думайте пока база не развалилась
причем что хуже всего развалиться она может задолго до того как учетчики поднимут тревогу по причине того что поплывут данные
   prog0101
 
36 - 15.01.13 - 12:19
(34)на самом деле кешей ещё больше
только рекомендаций нет для их чистки 
а этот реально есть и реально глючит при изменении базы
   Галахад
 
37 - 15.01.13 - 12:25
Я за зеркалирование баз данных на MS SQL.
В другой сервеной комнате, в другом здании.
Туда же продублировать терминальники.
   ЧеловекДуши
 
38 - 15.01.13 - 12:25
Без магии ни куда :)

4. Бубен
   Fragster
 
39 - 15.01.13 - 12:25
я понял. автор в .dt бэкапит
   ЧеловекДуши
 
40 - 15.01.13 - 12:26
(39)Хм... похожу так оно и есть :)
   mrWatson
 
41 - 15.01.13 - 12:27
(39) нет, не в dt
   prog0101
 
42 - 15.01.13 - 12:27
(41)не знаешь что такое дт? )))
   Fragster
 
43 - 15.01.13 - 12:30
(41) у нас база 500 гиг восстанавливается 30 минут средствами скуля. а вот с .dt - да, несколько часов.
   prog0101
 
44 - 15.01.13 - 12:31
(37)если не допустима потеря даже 15 минут тогда да конечно
   mrWatson
 
45 - 15.01.13 - 12:33
(42) а логи которые ты бакапишь, ты их где-то восстанвливаешь на копии? или как? как они помогут ускорить восстановление из бакапа?
   mrWatson
 
46 - 15.01.13 - 12:34
(42) можешь рассказть методику аварийного восстанволения по твоей методе резервного копирования (не в виде скрипта, а просто словами).
   IamAlexy
 
47 - 15.01.13 - 12:34
(0) даунтайм в офисах у работников 1Сне снижается.. как правило даунтайм у них 7/24/365
   Галахад
 
48 - 15.01.13 - 12:35
Не понимаю обсуждения развертывания бекапа на тот же SQL сервер.

Думаю стоит обсудить ситуации:
- потеря нескольких дисков массива
- выход из строя RAID контроллера
- отказ SQL сервера
   mrWatson
 
49 - 15.01.13 - 12:35
реально большинство 1Сников я уверен умеют только делать бакап рестор в MsSQL ну и детач аттач. если мы тут подробнее осветим проблему, то это поможет многим.
 
 Рекламное место пустует
   prog0101
 
50 - 15.01.13 - 12:38
(48)копия делается сразу быстро туда же
а потом в фоне тащи куда хочешь на случай форсмажора железа
(45)(46)
http://msdn.microsoft.com/ru-ru/library/ms189275(v=SQL.90).aspx
   prog0101
 
51 - 15.01.13 - 12:39
   Mikeware
 
52 - 15.01.13 - 12:39
(49) может, тем, кто "умеют только делать бакап рестор в MsSQL ну и детач аттач." - сходить поучиться, или как минимум почитать вполне доступную документацию, книжки?
   prog0101
 
53 - 15.01.13 - 12:41
(46)произошел сбой
пытешся забекапить лог в добавок к цепочке ранее сделанного копирования
потом не важно вышло или нет забекапить лог
восстанавливашь базу из цепочки
всё
   mrWatson
 
54 - 15.01.13 - 12:42
(52) я тоже так считаю... хотя если придираться, то MSSQL DB Admin это отдельная вакуха и тоже от 100 тыр
   prog0101
 
55 - 15.01.13 - 12:43
к (53) реально попыток забекапить лог после аварии не пришлось делать
а вот восстановление из цепочки в другую базу проходило успешно
   rs_trade
 
56 - 15.01.13 - 12:43
(49) Эта тема в интернетах освещена уже 100500 раз. Надо читать книжки от издательства Мелкософта. Ну и msdn никто не отменял.
   mrWatson
 
57 - 15.01.13 - 12:44
(55) ну да тестовые учения надо проводить это тоже важно, бакапы то могут и не восстановиться
   prog0101
 
58 - 15.01.13 - 12:45
(54)а потом окажется что админ считает что достаточно там фулл выставить чтобы потом если что всё хорошо восстановилось на сервак тебя не пустит так как он для этого а то что 1с тормозить так этож 1С будет там деньги тратить на дисковые массивы вместо того чтобы собрать десятый райд и воткнуть несколько дисков где-то в сети на форсмажор
   prog0101
 
59 - 15.01.13 - 12:46
(57)точно, особенно дт )))
(56)только вменяемых скриптов для фулл не так уж и часто нарыть можно
мне например по материалам инета самому писать пришлось
   mrWatson
 
60 - 15.01.13 - 12:47
(58) у вас в санлайт модель симпл?
   prog0101
 
61 - 15.01.13 - 12:51
(60)санлайт это случайным образом сгенеренное имя для примера
там где это использовалось модель стала фулл
   КонецЦикла
 
62 - 15.01.13 - 12:53
(0) Резервный сервер в другом здании
   mrWatson
 
63 - 15.01.13 - 12:55
(62) зеркальный mssql?
   prog0101
 
64 - 15.01.13 - 12:57
вообще правильно было бы пригласить архитектора корпоративных информационных систем из крупного системного интегратора с опытом внедрения сапа в крупных британских компаниях для эффективного отжима бабла на процессное управление развитием корпоративной информационной системы
а то что я пишу это "зачем вам в цирке программист спросила говорящая лошадь"
   Hazer79
 
65 - 15.01.13 - 13:00
Не 1С, но..

1. кластеризация сервера БД.
2. Файлы баз данных на отдельном СХД в 10 рейде на SAS винтах enterprise класса.
3. Ежедневный бэкап на отдельное железо
4. Постоянный мониторинг производительности всех компонентов.

5. Другое
   Sorm
 
66 - 15.01.13 - 13:01
(0) "Постоянный мониторинг производительности всех компонентов." Ну уж:)...
   Hazer79
 
67 - 15.01.13 - 13:03
(66) Что не так ?
   Fragster
 
68 - 15.01.13 - 13:04
всякие "заркалирования" не спасаю когда у буха открыта массовая обработка и слышишь вдруг "оймля!"
   Sammo
 
69 - 15.01.13 - 13:04
Переходите на 2008 скуль
Архивы можно сжимать средствами самого скуля + существенный выигрыш по времени на сжатие и восстановление.
   Fragster
 
70 - 15.01.13 - 13:05
(68)+ а ведь бухи иногда и на ночь обработки оставляют
   Sorm
 
71 - 15.01.13 - 13:07
(67) Постоянный мониторинг - избыточно, имхо. По расписанию.
   aspirant
 
72 - 15.01.13 - 13:07
2 разных железных сервера SQL - с распределенной базой. Обмен каждые 10 минут в обе стороны.
2 разных железных сервера предприятия
2 терминала

время простоя за почти 1,5 года было пару раз минут по 10 - когда мне все позвонили и уточнили, надо ли уходить на вторую линию. Все просто и работает. База 40 гиг УПП пользователей более 45 в базе не бывает.

5. Другое
   aspirant
 
73 - 15.01.13 - 13:09
самое важное во всей этой истории - чтобы люди могли работать без сисадмина и программиста. чтоб рейды сами ребилдились,  чтоб линии вторые сами поднимались, пока не появятся айтишники.
   aspirant
 
74 - 15.01.13 - 13:10
сейчас рассматриваю вопрос размещения "теневой" копии для бекапа в облаке. чтоб даже пожар не мог помешать нашим планам порабощения мира...
   mrWatson
 
75 - 15.01.13 - 13:11
+(0) в лога SQL было такое

01/12/2013 01:04:17,spid53,Unknown,SQL Server detected a logical consistency-based I/O error: incorrect checksum (expected: 0x7dcf9c24; actual: 0x7dcf1c24). It occurred during a read of page (1:28792043) in database ID 5 at offset 0x000036ea9d6000 in file 'C:\sql_data\MyBase.mdf'.  Additional messages in the SQL Server error log or system event log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information<c/> see SQL Server Books Online.
   Sorm
 
76 - 15.01.13 - 13:11
(74) Как красиво компетентные органы изымут оттуда теневую копию...
   mrWatson
 
77 - 15.01.13 - 13:12
(76) админ-обортень быстрее спионерит данные
   aspirant
 
78 - 15.01.13 - 13:12
(76) да пусть два раза в день вынимают. все пушисто.
   Sorm
 
79 - 15.01.13 - 13:16
(77) Тоже верно
(78) пушисто... пушисто-то оно пушисто, а список контрагентов, а договоры, а цены, а скидки, а клиенты?
   aspirant
 
80 - 15.01.13 - 13:19
(79) чаще всего в туалете на подоконники расчетные листочки с зарплатами лежат. а не через Компетентные органы утечка случается. У нас 50 торговых представителей с КПК бегают по 3 областям - там у них у клиенты и цены и скидки и договоры. Каналов утечки информации, более вероятных к использованию, гораздо больше.
   aspirant
 
81 - 15.01.13 - 13:22
(79) у Вас кстати сайт за неуплату остановили. совсем наверное плохи дела финансовые.
   Hazer79
 
82 - 15.01.13 - 13:24
(80) На месте твоего работодателя, я бы тебя уволил за такой образ мыслей в отношении политики безопасности
   aspirant
 
83 - 15.01.13 - 13:25
(82) Да нет у меня работодателя. Уволили уже. Давно. 1.5 года назад.
   Sorm
 
84 - 15.01.13 - 13:26
(81) С ходу переход на личности?:)...Я не понял такого сильного аргумента.
   aspirant
 
85 - 15.01.13 - 13:26
(82) ну а если предметно - выколоть глаза торговым представителям? У них там помимо всего, что перечислил (79) есть более важная инфа - сверки, долги, объемы и т.д.
   aspirant
 
86 - 15.01.13 - 13:27
(84) да не ничего личного, не огорчайся, если задел.
   aspirant
 
87 - 15.01.13 - 13:30
(82) Я ведь не против безопасности, но только от реальности не надо отходить - а то ворота с охранником будут, а забора не будет. Речь идет о простоях и безотказности - я привел свой вариант.
   Sorm
 
88 - 15.01.13 - 13:32
(87) Казалось бы, причем тут чужие сайты:):) О торговых представителях - если у него в планшете " клиенты и цены и скидки и договоры." а не номенклатура и заказы - возникает вопрос - кто такую систему придумал:)
   ptiz
 
89 - 15.01.13 - 13:38
А к у нас сделано - мне не очень нравится.
Бэкап дважды в сутки + 1 раз бэкап лога (с начала недели копится).
По-уму, надо зеркало или хотя бы логшиппинг.
   aspirant
 
90 - 15.01.13 - 13:39
(88) видимо, у Вас нет торгашей с кпк. Я, конечно не разработчик сей системы, но вощникает логичный вопрос: ну как он наберет заказ без КЛИЕНТА, без СУММЫ заказа, без отчетов по долгам всевозможных, без отчетов по отгрузкам, истории заказов, возвратов и т.д.?
   Hazer79
 
91 - 15.01.13 - 13:39
(85) Не об этом речь. А о том что если уж думать о защите информации, то думать масштабно, по всему периметру. А не так что "А, если конкуренты захотят, то и через ТП всё узнают, поэтому и сервак с БД нет надобности защищать. Чё париться-то?"
Я лично такую философию в (80) увидел.

(88) +1
   Lexusss
 
92 - 15.01.13 - 13:39
100+ баз в десятки и сотни гигов, десятки серверов, 7 лет с 1С. Ни разу не приходилось поднимать для работы основную промышленно используемую рабочую базу из бекапа. Что за железо используете, что у вас валится железо боевых SQL серверов?
Да и про какие "несколько часов" для базы в 200 гигов говорится? Дисковый массив из 2х дисков SATA 7.2к 250Гб на софтрейде у вас что ли?
Со стримера такое счастие поднимается едва ли за полчаса.

Для отказоустойчивости и надежности используем ежедневный бекап на стримеры в другом здании + RAID массив.

5. Другое
   Sorm
 
93 - 15.01.13 - 13:41
(90) :):):) "Без отчетов по долгам всевозможных, без отчетов по отгрузкам, истории заказов, возвратов и т.д.?"... Мда. У нас в качестве торговых агентов - таджики. Хватает как-то.
   Hazer79
 
94 - 15.01.13 - 13:41
(90) Отчёты, истории, возвраты и прочее, ЧТО БЫЛО - нафиг не надо ТП на кпк. Нужна только номенклатура и её цена.
   prog0101
 
95 - 15.01.13 - 13:42
(95)однажды один архитектор с опытом в крупных британских компаниях ощутил что стример не лепится на юсб под варей )))
   prog0101
 
96 - 15.01.13 - 13:42
к (95) и так и бросили этот стример валяться пылиться )))
   aspirant
 
97 - 15.01.13 - 13:55
(93) (94) вы не путайте пожалуйста простых сборщиков заявок с торговым представителем, который занимается заключением договоров, сбором денег, организаций работый мерчей в торговой точке и т.д.
   aspirant
 
98 - 15.01.13 - 13:56
(93) только не принимай на личный счет: таджики хоть без знания русского я языка? а то разболтают цены на номенклатуру.
   Hazer79
 
99 - 15.01.13 - 13:58
(97) Это у тебя супервайзер тогда получается
   Sorm
 
100 - 15.01.13 - 14:00
(98) Все как один - без. Они только цифры понимают, а как продукцию идентифицируют - вообще непонятно. Но не ошибаются.
(99) Вот-вот, только хотел написать...
  1  2   

Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Тема не обновлялась длительное время, и была помечена как архивная. Добавление сообщений невозможно.
Но вы можете создать новую ветку и вам обязательно ответят!
Каждый час на Волшебном форуме бывает более 2000 человек.
Рекламное место пустует