1. SQL Server в Microsoft
Windows Azure -
платформа для современных бизнес
приложений "1С"
Maksim Lemeshko, Community Leader

2. 2
Общее содержание
Концепция Windows Azure
Или почему мы поговорим сегодня об этом?
SQL Server в Windows Azure
Что предлагает MSSQL Server для современных бизнес приложений?
Бизнес-приложение «1С»
Требования платформы, особенности архитектуры, нюансы использования MSSQL
Server, рекомендации, обслуживание, резервное копирование и восстановление.
2

3. 3
Почему Windows Azure,
функциональность
 WA – для всех!
 600 SaaS приложений.
 Лояльная ценовая политика.
 Совместимость с on-premise решениями.
 Высокая безопасность.
 Изоляция ОС от изменений вносимых в
конфигурацию.
 Готовые пакеты образов ОС: Windows, Unix,
собственные образа.
 Мониторинг, POSH, соадминистратор.
3

4. 4
Почему Windows Azure,
технологичность
 Восемь регионов платформы для размещения
приложений, сервисов и инфраструктуры.
 Понятный SLA.
 Гео-избыточность.
 Балансировка нагрузки.
 Сервис обеспечения защиты и восстановления
локальной инфраструктуры (HRM).
 Высокопроизводительные системы.
 Резервное копирование.
 ExpressRoute*.
4

5. SQL Server at
Windows Azure VM
The Whole Truth and Nothing But the Truth!

6. 6
Windows Azure SQL Database and
SQL Server*
Производительность!
Масштабируемость!
Различия!
Статья: http://msdn.microsoft.com/en-us/library/windowsazure/jj879332.aspx
* - Windows Azure SQL Database, ранее SQL Azure
6

7. 7
Техническое
описание
Указания по
оптимизации
производительности
SQL Server в
виртуальных машинах
Windows Azure
Опубликовано: июнь 2013
Ссылка для скачивания:
http://go.microsoft.com/fwlink/
?LinkId=306266
7

8. 8
Производительность
 Ключевые принципы настройки SQL Server
 Характеристики Windows Azure IaaS
 Рекомендации
 Мониторинг
 Поиск неисправностей
8

9. 9
Ключевые принципы настройки SQL
Server
 Пропускная способность
 Время отклика (latency)
9
Метрики OLTP DW Transaction Log
Смешанная нагрузка
Read/Write
• Большое количество
малых транзакций
• Ограниченное (малое)
количество типов
транзакций
• Баланс в сторону
чтения
• Интенсивное
сканирование, Большие
порции данных за раз
• Bulk loading
• Только запись
• Требуется низкая
latency
IO размер и тип • Между 8 и 64K
• Обычно random
• От 64KB до 512KB reads
• Обычно sequential
• MB/s критическая
метрика
• Последовательный
# users высокая низкая n/a

10. 10
Характеристики Windows Azure VM*
10
Архитектура Задержки
Изменчивость
Конфигурационные
опции
VM – Virtual Machine (Виртуальная машина)

11. Опции настройки Виртуальных машин
11
Размер
виртуальной
машины
Пропускная
способность сети
Типы дисков и
геометрия
Дисковый
кэш

12. 12
Windows Azure VM Size
12
Размер
VM
Ядер CPU Память
Размер
OS Disk
Временны
й диск
Скорость(
Mbps)
Максимал
ьное
количеств
о дисков
(1 TB
каждый)
Максимум
IOPS
(макс 500
на диск)
ExtraSmall Shared 768 MB 127 GB 20 GB 5 1 1x500
Small 1 1.75 GB 127 GB 70 GB 100 2 2x500
Medium 2 3.5 GB 127 GB 135 GB 200 4 4x500
Large 4 7 GB 127 GB 285 GB 400 8 8x500
ExtraLarge 8 14 GB 127 GB 605 GB 800 16 16x500
A6 4 28 GB 127 GB 285 GB 1,000 8 8x500
A7 8 56 GB 127 GB 605 GB 2,000 16 16x500
A8
8 56 GB ? ? ? ? ?
A9
16 112 GB ? ? ? ? ?

13. 13
Типы дисков VM и конфигурации
OS disk (постоянный)
 Динамический 127GB диск, оптимизированный для OS типа нагрузки
(загрузка OS)
 Не рекомендуется использовать для SQL Server
Data disk (постоянный)
 VHD, который может быть присоединен к VM для хранения данных
 до 1TB
 до 16 дисков для XL и А7 VM
Temporary local disk (непостоянный)
 Используется для временных (например, OS page files)
 Располагается на «внутренних» дисках физического хоста
 Обнуляется в случае сбоя VM или обновления хоста
 Физический диск, разделяемый между несколькими VMs на одном хосте
 Не рекомендуется для пользовательских или системных баз данных
13

14. 14
Общие сведения
Windows Azure VMs
 VMs расположены в инфраструктуре Windows Azure
(“IaaS”)
 Образы VM от Microsoft или «самодельные» (VHDs)
 Быстрый provisioning (10 minutes)
 Pay per use
 VM: стоимость за минуту
 Зависит от размера и лицензий (например, SQL)
 Сеть: только входящий траффик
 Storage: только используемое (а не зарезервированное)
 Эластичность
 1 core / 2GB RAM / 1TB 8 cores / 56GB RAM / 16TB
 «Собственное» управление VM
 Security, patching, monitoring, etc
14

15. 15
Хранилище
Windows Azure VMs
 Каждый диск данных в VM – BLOB в Azure Storage
 3 синхронные локальные копии
 Нет потери данных
 Высокая доступность (прозрачно для VM)
 3 дополнительных асинхронных копии, если geo-replication включена
 Для восстановления в случае глобального сбоя (управляется Microsoft)
15

16. 16
Поддержка высокой доступности
и восстановления от сбоев
 Высокая доступность
 SLA: Никакой потери данных
 Если VM недоступна, старт на другом узле
 SLA: 1 из 2 VMs в Availability Set:
 99.95% (<22 минуты downtime в месяц)
 Включает:
 Запланированный downtime (в месяц) для сервисов на хосте
 Незапланированный downtime из-за «железных» проблем
 Не включает сервис гостевой OS
 Восстановление
 <30 минут (SLA отсутствует)
 Azure Ops восстанавливают VM (SLA отсутствует)
16

17. 17
SQL Server в
Windows Azure VMs
 Поддерживаются многие версии SQL
 SQL 2014 CTP1, SQL 2012 SP1, SQL 2008 R2
 (Почти) 100% совместимость
 Нет SQL Failover Clusters (пока еще..)
 Управление SQL Server – ваше
 Security, Backups, HA, DR, etc
17

18. 18
Windows Azure IO система
 Диск выполнен как
разделяемый
многопользовательский
сервис
 Встроенная тройная
избыточность, опционально
гео-репликация
 Производительность менее
предсказуема, чем on-prem
 Хост серверы, сервисы хранилищ, сеть
разделена между многими
подписчиками и сервисами
 Производительность может зависеть от
того, где и когда VM была развернута
 Вопрос: операционные процессы
 Уровень контроля над конфигурацией
против стоимости, простоты и
встроенной избыточности
18
Storage Stamp
Stream Layer
Partition Layer
Front-ends
LB
Intra-stamp replication
Stream Layer
Partition Layer
Front-ends
LB
Intra-stamp replication
Storage Stamp
Geo-replication
Storage Location Service

19. 19
Как устроен дисковый кэш в VM?
 Кэширует данные VM внутри хост узла
 Помогает уменьшить задержки I/O уменьшая # транзакций против Windows
Azure Storage
 Кэш 2-го уровня
 Недавно «затронутые» данные хранятся в RAM кэше хост сервера – пространство,
разделяемое всеми VM на сервере machine
 Нечасто затрагиваемые данные хранятся на локальном диске физической машины
 Размер зарезервированного пространства кэша для VM “OS Disk” и “Data
Disks” зависит от размера VM
19

20. 20
Настройки VM кэш по умолчанию
 Read Only: Все запросы на чтение кэшируются для будущего доступа. Все
записи пишутся напрямую в Windows Azure Storage
 Read Write: Запись и чтение кэшируется для будущего доступа. Не write-
through записи хранятся сначала на локальном диске. Для SQL Server,
записи пишутся на WA storage , потому что потому что SQL использует
Write-through
 Обеспечивает низкие дисковые задержки для лёгких типов нагрузок
 None (выключен): пропускает кэш. Все данные пишутся сразу в Windows
Azure Storage
 Высокий уровень I/O для интенсивных I/O нагрузок
 Также включает стоимость TX
20
Тип диска Read Only Read Write None (disabled)
OS disk Supported Default mode Not supported
Data disk Supported (up to 4) Supported (up to 4) Default mode
Temporary disk Implemented using local attached storage

21. 21
Рекомендации по использованию
дискового кэша
Data disks
 Настройка кэша зависит от типа IO и интенсивности нагрузки
 Использовать настройки «по умолчанию» “None” (disable) для более
высоких random IOs (например, OLTP) & и более высокой пропускной
способности
 «пропускает» физический диск хоста, тем самым увеличивает частоту IO
 Принять во внимание включение read cache для запросов, чувствительных
к задержкам latency
OS Disk
 “Read Write” (default) уменьшает задержки при небольших и IO интенсивных
нагрузках на малых DBs (<=10GB)
 Рабочий набор может «влезть» в память, и уменьшить количество операций IO к blob
storage

22. Рекомендации
22
Сетевые задержки
Дисковая
конфигурация
Tempdb Оптимизация IO

23. 23
VM сеть
 Высокие сетевые задержки в сравнении с on-prem
 Виртуализация, безопасность, load balancing, удаленность
 Уменьшение сетевых «round trips» имеет большее влияние
 Объединить «болтливые» уровни приложений на
одной VM
 Располагайте VM в одной/одном Virtual Network /
Cloud Service
 Используется коммуникация через «внутренний» IP (DIPs)
 VMs со схожей/одинаковой нагрузкой должны жить в том же Cloud Service
(пример: VM включенная в AG, или VM в определенном app tier).
 Распределение нагрузки между VMs в том же cloud service через публичные
виртуальные IP (пример: нагрузка на чтение в AlwaysOn AG)
 Можно использовать Windows Azure Virtual Network для VMs в разных cloud
services

24. 24
Дисковая конфигурация: один диск
 Рекомендуется для <1TB
 Допустимая производительность
 Минимальная сложность, простое восстановление
Пример: SQL IO для одного диска:
24
Random I/O (8KB
Pages)
Sequential I/O
(64KB Extents)
Sequential I/O
(256KB Blocks)
Reads Writes Reads Writes Reads Writes
IOPS 500 500 500 300 300 300
Bandwidth 4 MB/s 4 MB/s 30 MB/s 20 MB/s 70 MB/s 70 MB/s

25. 25
Дисковая конфигурация: много
дисков
 Рекомендуется для:
 >1TB DB файлов, или
 Высокого числа IOPS / пропускной способности
 Два пути:
 Путь 1: Использовать файловые группы с несколькими
файлами
 Наилучшие результаты в тестах
 НЕ помогает масштабировать transaction log
 Путь 2: Windows Server 2012 storage space
 Storage spaces, а не OS striped volumes
25

26. 26
Суммарная пропускная способность
26
16 disks Random I/O (8KB Pages) Sequential I/O (64KB
Extents)
Sequential I/O (256KB
Blocks)
Reads Writes Reads Writes Reads Writes
IOPS 8000 8000 2500 5000 700 2400
Bandwidth 60 MB/s 60 MB/s 150 MB/s 300 MB/s 170 MB/s 600 MB/s
4 disks Random I/O (8KB Pages) Sequential I/O (64KB
Extents)
Sequential I/O (256KB
Blocks)
Reads Writes Reads Writes Reads Writes
IOPS 2000 2000 2000 1300 700 1100
Bandwidth 20 MB/s 20 MB/s 120 MB/s 80 MB/s 170 MB/s 270 MB/s
8 disks Random I/O (8KB Pages) Sequential I/O (64KB
Extents)
Sequential I/O (256KB
Blocks)
Reads Writes Reads Writes Reads Writes
IOPS 4000 4000 2500 2600 700 2200
Bandwidth 30 MB/s 30 MB/s 150 MB/s 160 MB/s 170 MB/s 550 MB/s

27. 27
Дисковая конфигурация:
масштабирование Reads and Writes
Чтение: Масштабирование I/O «поверх» нескольких
дисков
 OLTP (мелкие random операции)
 Маленький размер блока (8К)
 IOPS и пропускная способность растут линейно.
 Data Warehousing
 Большие блоки (128К, 256К и 512К).
 IOPS и пропускная способность перестают расти после добавления 4х дисков.
Запись: Масштабирование I/O «поверх» нескольких
дисков
 Для нагрузок, где много операций записи, добавление дисков
приносит явную пользу
 Для больших последовательных операций I/O, запись
масштабируется лучше, чем чтение.
27

28. 28
TEMPDB и временный диск D:
Не используйте никогда.
Почему?
 Ожидаемая производительность:
 Direct Attach Disks, которые разделяют IO между несколькими VM на
сервере.
 Размер диска зависит от размера VM
 Дополнительные сложности:
 SQL Server должен пересоздавать TEMPDB на диске D:, а для этого
требуются привилегии.
 А если еще и папка была создана?
 Если TEMPDB критична для приложения:
 Читаем tempDB IO best practices
28

29. 29
Рекомендация: сжатие данных
29

30. 30
Политика: Instant File Initialization
 Не настроена по умолчанию
 Уменьшает IO для
 СозданиеDB
 Восстановление DB
 Добавить файлы к DB
 Увеличение размера файла
 Autogrow, и т.д..
 Добавить SQL сервисе в
политику Perform Volume
Maintenance Tasks
 Перезапуск SQL Server
 Note: не поможет с
Transaction Log
30

31. 31
Как настроить Instant File Initialization
31

32. 32
Рекомендации
 Установить размеры
 Autogrow – это страховка
 Но не гарантия
 Настроить Instant File Initialization до создания DB
 Настроить Instant File Initialization до момента увеличения
файлов (TEMPDB)
 Настроить Instant File Initialization до создания DB
восстановления базы данных
 Не забываем про перезапуск SQL Server после настройки
Instant File Initialization
32

33. 33
Что еще принять во внимание
 Реинициализация диска
 NTFS размер блока ?
 Один или нескольких storage accounts на одной VM
 Не «размазывать» файлы базы данных по нескольким
Storage Accounts!!!
 Данные в разных BLOB не записываются одновременно
 BLOB, участник stripe set может быть «не синхронизован»
 Альтернатива:
 «Размазать» данные (файлы) по нескольким дискам для
повышения IO
 Помним:storage account имеет предел 20K tps
33

34. Мониторинг
34
Инструменты
Storage
Analytics
VM Dashboard SQL Perf counters

35. Поиск неисправностей
35
Классические
факторы
производительности
Высокоуровневые
шаги по решению
проблем
«Стандартные»
проблемы

36. Классические факторы
производительности SQL Server
36
Plan change/choice
issues
Software/hardware
configuration
Locking & latching
Multi-user
operations and
blocking
Checkpoint &
system operations

37. Высокоуровневые шаги по решению
проблем
37
Определение KPIs и
наблюдение
использования
ресурсов
Наблюдение KPIs на
промежутке времени
Исследование трендов
и шаблонов при росте
нагрузки
Наблюдение DMVs для
понимания
блокировок и
ожиданий на ресурсах
Наблюдение spinlock и
back-off событий

38. «Типичные» проблемы VM
38
Проблема KPIs Что делать?
CPU около 80%
% Processor Time (_Total)
SOS_SCHEDULER_YIELD waits
Увеличить размер
Тор запросы для оптимизаций
Load balance ( перенести Db на другой
инстанс )
I/O «до потолка» или
же задержки по
IO растут
Average disk reads per second
Average disk writes per second
Disk reads per second
Disk writes per second
io_virtual_file_stats
PAGEIOLATCH waits
SQL Server: Buffer ManagerPage Life
Expectancy
Check Page Life Expectancy counter, for
mem pressure. Increase instance size
Identify which DB and log files have I/O
bottleneck
Add more data disks and separate data
files if near IOPS limits per disk
Tune queries to reduce reads and writes
Consider enabling row or page
compression
Memory pressure
Memory: Available Bytes
Memory: Pages per second
SQL Server: Buffer ManagerPage Life
Expectancy
Process: Working Set (for SQL Server)
RESOURCE_SEMAPHORE waits
Check max server memory setting for
SQL Server.
Use high memory instance
Identify SQL component (such as, CLR,
high memory grants for app queries,
et.), tune appropriately.

39. 39
Подытожим
39
 Читаем Performance Guidance for SQL Server in
Windows Azure Virtual Machines
 Планируем и тестируем IO
 Определяем оптимальный размер VM
 Оптимизация для уменьшения IO и сетевых round
trips
 Использовать файловые группы и больше дисков
данных для больших DB
 Определить KPIs для мониторинга
 Пересмотр оптимизаций при росте нагрузки.

40. SQL Server at
Windows Azure VM
Высокая доступность или SQL AlwaysOn

41. HA/DR сценарии в
Windows Azure VMs
SQL Server

42. 42
SQL Server HA/DR сценарии
 HA внутри Azure
 Доступность SQL Server в Azure VM
 Защита от сбоев SQL Server или VM
 Использование другой SQL Server VM в том же Azure DC
 DR между On-Premise и Azure
 Доступность on-premise SQL Server (физической или виртуальной
конфигурации)
 Защита от сбоев on-premise data center
 Использование SQL Server VM в Azure
 DR между Azure data centers
 Доступность SQL Server в Azure VM
 Защита от сбоев внутри Azure data center
 Использование SQL Server VM в другом Azure DC
42

43. 43
SQL Server HA
внутри Windows Azure, ????
 Определение сбоев на уровне Azure сервисов (не SQL
Server)
 SQL Server сервис может «упасть» или «зависнуть»
 Сервис гостевой OS = downtime
 Сервис SQL Server = downtime
 Сервис восстановления Azure (service healing) приводит к
перезапуску VM на другом хосте
 ~12 мин downtime каждый раз
 Обновление Azure включает сервис OS хоста и
перезагрузку VM на другом узле
 ~15 минут downtime каждый раз
43

44. 44
Поддерживаемые технологии SQL
Server HA
44
Технологии SQL Server
версии
Нулевая
потеря
данных
Область # Реплики Автоматизаци
я
Failover
Readable
Secondary(es)
Availability
Groups
SQL Server
2012
SQL Server
2014
Yes
(Sync Mode)
DB(s) 4
8 + 1
Yes
(с
дополнительн
ым узлом в
кластере)
Yes
Database
Mirroring
SQL Server
2008 R2
SQL Server
2012
Yes
(High Safety
Mode)
DB 1 Yes
(с Witness
сервером)
Ограниченно
(database
snapshots)

45. 45
Availability Groups
 Много разных полезностей:
 Гибкие политики Failover
 Автоматическое восстановление страниц (Page Repair)
 Копии на Secondaries
 Улучшенная управляемость
 Поддержка FileStream & FileTable
 Не забываем, что требуются также:
 Windows Cluster
 Не поддерживается shared storage в облаке
 Тот же Windows Domain
 Требуется Active Directory Domain Controller
45

46. 46
Прежде чем начать
Убедитесь что хостинг VM настроен правильно
 В одной Availability Group
 В одном Azure кластере
 Уменьшает время синхронизации лога
 В одной Availability Set
 Разные Fault Domain (rack) и Upgrade Domain
 Гарантирует, что потеря rack и Azure’s upgrade влияют только
на одну реплику
 Одна VNet
 Гарантирует, что VM IPs не изменится после Azure’s service
healing (а так же избегаем обновления DNS записи: ~12 min)
 Требуется для Active Directory
46

47. 47
Прежде чем начать
Подготовка VMs
 Создаем Active Directory Domain Controller
 Ссылка
 Присоединяем VMs к домену
 Ссылка
 Создаем Windows Cluster
 Ссылка
 Ссылка
 Создать Availability Group (как в on-premise)
 Создать Availability Group Listener (внимание)
 Ссылка
47

48. Доступность бизнес-
приложений
На примере «1С»+AlwaysOn

49. 49
«1С»
платформа, особенности
 1С и SQL Server вместе с версии SQL Server 6.5.
 Простая установка, без специальных знаний
 1С использует только часть функционала SQL Server
 Масштабируется на уровни серверов приложений
 Возможности масштабирования на уровне БД нет
 Настроек «По умолчанию» – достаточно.
 Одна учетная запись “USR1CV82”
 OLTP запросы – основная нагрузка
 Управление потоками данных на обработку
 Лиц.ограничение на использование недокументированных
операций с БД средствами СУБД
 В текущих конфигурациях целостность данных контролируется
серверов 1С
 Большая часть проблем скрыта в коде, а не в «галочках» СУБД
 Работа на нестабильных каналах связи
49

50. 50
«1С» использует
часть функционала SQL Server
50
 Использует:
 Компонент Database Engine
 Не использует
 Полнотекстовый поиск
 Репликация
 Служба Analysis Services
 Служба Integration Services
 Служба Reporting Services
 Свой функционал
 менеджер блокировок
 полнотекстовый поиск
 механизм обменов между базами
 функционал аналитических данных (OLAP)
 мощный блок системы мониторинга и отчетности
 и другое

51. 51
Основные подходы к реализации
межсерверной кластеризации
Технология Плюсы Недостатки
Log shipping,
Mirroring
Простая настройка Сложно/невозможно использовать
ресурсы дополнительного сервера
Репликация Использование ресурсов
дополнительного сервера
Сложность сопровождения,
настройки, значительное
отставание, конфликты
Always On
(для MS SQL 2012)
 Минимальное отставание
 Распределение нагрузки
(использование в режиме
read only ресурсов
дополнительного сервера)
Не выявлено
Неполная поддержка
приложениями
51

52. 52
«1С» и AlwaysOn
конфигурация
52
Ссылка, конфигурация WSFC-кластера

53. 53
Укрупненная схема работы
53
Оперативная работа пользователей
всегда строится на первом (главном)
узле кластера.
В случае повышения нагрузки на
первом узле (настраиваемое
пороговое значение), запросы по
аналитике переключаются на
второй узел кластера, оставляя
первый при этом только для
оперативной работы
пользователей.
Оперативная работа пользователей не
остановится в случае падения первого
узла кластера или основной базы
данных. Данные реплицируются в с
минимальной задержкой в резервную
базу данных.
Чтение и запись Только чтение

54. 54
«1С»
управление
 Стандартные функции
 Активные пользователи
 Поиск ссылок на объекты
 Проведение документов
 Удаление помеченных объектов
 Управление итогами
 Управление полнотекстовым поиском
 Резервные копии
 Для файлового варианта – копирование файла 1Cv8.1CD
 Для клиент-серверного варианта – средствами СУБД
 Мониторинг и устранение проблем
 Тестирование и исправление информационной базы
 Журнал регистрации
 Технологический журнал
 Контроль ссылочной целостности
54

55. 55
«1С»
чистота и порядок
 Обновлять статистику
 exec sp_msforeachtable N'UPDATE STATISTICS ? WITH FULLSCAN‘
 раз в день, можно чаще
 Чистить процедурный кэш
 DBCC FREEPROCCACHE
 сразу за процедурой обновления статистики
 Дефрагментировать индексы
 sp_msforeachtable N'DBCC INDEXDEFRAG (<имя базы данных>, ''?'')‘
 Не реже раза в сутки, но можно не все таблицы сразу
 Реиндексировать таблицы
 sp_msforeachtable N'DBCC DBREINDEX (''?'')‘
 в моменты минимальной загруженности, но не режа раза в неделю
http://kb.1c.ru/articleView.jsp?id=13
55

56. 56
Further Reading
 White paper: Performance Guidance for SQL Server in Windows Azure Virtual Machines
 SQL IaaS Basics
 SQL Server in Windows Azure Virtual Machines
 SQL Server HA/DR on IaaS
 About SQL Clustering func
 Windows Azure Storage
 Windows Azure’s Flat Network Storage and 2012 Scalability Targets
 Windows Azure Storage: A Highly Available Cloud Storage Service with Strong Consistency
 Erasure Coding in Windows Azure Storage
 SQL Server Backup and Restore with Windows Azure Blob Storage Service
 SQL Server Performance
 Analyzing I/O Characteristics and Sizing Storage Systems for SQL Server Database Applications
 Compilation of SQL Server TempDB IO Best Practices
 Windows Azure SQL Database and SQL Server -- Performance and Scalability Compared and Contrasted
 SQL Server HA/DR on IaaS
 Тренинг и скрипты
 IaaS
 Как создать Virtual Network в Azure
 Настроить Virtual Network между on-premise и Azure
 Создать Active Directory Domain Controller
56

57. 57
Further Reading
 AlwaysOn + 1С
 Ссылка 1
 Ссылка 2
 WSFC кластер
 Ссылка 1
 Ссылка 2
 Видео
 SQL Server в Windows Azure
 Установка и обслуживание MS SQL Server 2008 R2 для 1С:Предприятие 8
57

58. Questions?

59. Thank You for Attending