Просто интересно, какие процессы у вас, ребята, для передачи производственных данных для анализа?
Я прочитал некоторую литературу, но не уверен в накладных расходах и процессах настройки.
К вашему сведению, я использую SQL Server 2008 с Windows Server 2008 R2. МОЯ БД около 36 гигов. Меня интересуют только данные.
Другие методы приветствуются!
*РЕДАКТИРОВАТЬ Дополнительная информация: я не против того, чтобы база данных была доступна только для чтения, и я хочу запускать этот процесс один раз в неделю.
Вы можете посмотреть на доставку журналов, очень похожую на ваш «ручной» подход, но с использованием встроенных компонентов SQL для выполнения работы и работы с резервными копиями журналов транзакций.
Отличное объяснение и сравнение зеркалирования базы данных можно увидеть на http://blogs.technet.com/josebda/archive/2009/04/02/sql-server-2008-log-shipping.aspx
В качестве простого предложения вы говорите, что ваш db составляет 36 гигов. В зависимости от степени сжатия и скорости передачи вам может быть проще выгрузить его на USB-накопитель и отправить по почте. Более того, некоторые ftp никогда не разрешают файлы размером> 4 ГБ. Возможно, вам подойдут добавочные push-уведомления, но опять же рассмотрим худший случай: что произойдет, если ваши данные изменятся быстрее, чем ваша база данных сможет отправить их в репликатор?
У меня есть клиент, которому нужна именно эта вещь. Они не могли принять, что база данных недоступна при восстановлении журналов, поэтому доставка журналов отсутствовала. Репликация была невозможна, потому что их схема была бы слишком хлопотной. Зеркальное отображение не будет работать, потому что оно доступно только для чтения, и им нужна была база данных с возможностью записи ... но эти записи сделали не нужно вернуться на главный сервер.
Я закончил тем, что написал план обслуживания и несколько скриптов, которые делают полную резервную копию рассматриваемого db (120 ГБ), затем используют xp_cmdshell для копирования файла в сетевой ресурс на другом сервере SQL, а затем, наконец, выполняет задание удаленно (вы можете указать, на каком сервере выполнять операцию на этапе планирования), чтобы выполнить восстановление базы данных.
Вы можете попробовать скрипт isp_Restore Тары Кизер, который может вам в этом помочь. http://weblogs.sqlteam.com/tarad/archive/2005/11/08/8262.aspx Я закончил тем, что написал свой собственный сценарий, потому что ее сценарий не делал именно то, что мне нужно, но он должен, по крайней мере, помочь вам начать.
Доставка журналов отлично подходит для анализа, но будьте готовы к высоким накладным расходам при первоначальном резервном копировании и передаче данных на другой сервер / экземпляр. Кроме того, доставка журналов подразумевает задержку между оперативными данными и данными анализа. После этого вы перемещаете только резервные копии журналов транзакций, которые теоретически меньше.
В нашей среде мы регистрируем доставку каждую ночь, потому что руководство создает отчеты, когда они приходят в офис утром, и эти отчеты обычно требуют значительного количества сводок.
У нас была база данных размером 4 ГБ, и нам нечасто требовалась резервная копия для анализа проблем. База данных была слишком большой, чтобы делать резервную копию в течение дня во время работы производства. Итак, нашим решением было запускать резервное копирование ночью, когда наша производственная система не работала, и хранить самые последние резервные копии (я думаю, что мы держали одну неделю).
Одно из наших требований заключалось в том, что базу данных нужно было отправлять в разные отделы в зависимости от проблемы. Другая причина заключалась в том, что мы могли сделать файлы резервных копий доступными для менеджеров проектов, у которых не было прямого доступа к какому-либо серверу SQL, и они отвечали за отправку резервных копий соответствующим получателям. Им не нужно было привлекать администраторов для получения резервных копий.
Ежедневное резервное копирование планировалось с помощью стандартных инструментов сервера SQL.
Предполагая, что ваша целевая аналитическая база данных является той же платформой, что и ваша производственная база данных, самое простое решение - делать еженедельное инкрементное резервное копирование, а затем применять его к своей аналитической базе данных. Если ваша база данных не растет очень быстро, инкрементный файл должен быть передан в течение разумного периода времени.
Если вы передаете данные в базу данных другого типа, отличную от той, которую вы сейчас используете в производстве, инструмент ETL, например Интеграция данных Pentaho может быть лучше. Инструмент ETL - еще лучшее решение, если вас интересуют только некоторые таблицы, а не все.