Pull to refresh

Comments 105

К сожалению это пока не Open Source, но последняя версия 17 релиз кандидат похудела сразу на 200 Мб

У них там цельнотянутый шелл visual studio внутри лежит, причём довольно старой версии.

Вообще-то последняя, Microsoft Visual Studio 2015 Isolated Shell ;)
меня больше интересует, а что же там такого в девелопер эдишн, что объем инсталлятора — 2 ГБ ???

ну и да, нет главного — бенчей, на многогигабайтных базах, и на сложных запросах. вон у меня мускул с базой в пару десятков ГБ вполне себе нормально крутится, порядка 80 строк в секунду пишет в таблички, регулярные выборки с агрегацией (zabbix) — и это все на RAID1 из HDD, по IOPS запас еще приличный. и чего-то мне кажется, что мсскл в таком режиме сложится…

Это такой тонкий троллинг SQL Server'а?

почему же?

я не могу представить, почему инсталлер весит 2 ГБ (если там нет в довесок IDE либо кучи файлов справки на разных языках). та же постгря весит на порядок меньше… потому и интересуюсь — что в мсскл инсталлере такого особенного?

и да, главной причины попробовать — бенчей, демонстрирующих явное преимущество платного решения в hiload/big data — почему-то в статье нет.
Я сейчас ради интереса залез в ISOшку инсталлера SQL 2014, файлы в папке бинарниками собственно сервера весят порядка 180 Мб, из них там какая-то база данных, вероятно, будущий «master» 40 Мб и языковая библитека 32 Мб. Так что вполне вменяемо. Остальное в дистрибутиве — клиентские библиотеки, полнотекстовый поиск, средства OLAP, документация и т.д.

Я не про инсталяр удивлялся, а про


и чего-то мне кажется, что мсскл в таком режиме сложится

По поводу инсталятора — в инсталятор MSSQL зашиты еще помимо самой базы данных различные сервисы SSAS, SSIS и прочие, которых естественно нет по умолчанию в инсталяре PostgreSQL (кстати я так на вскидку не могу назвать аналоги SSIS и SSAS в PotgreSQL, может кто подкинет ссылку?). Они не обязательны к установке и почему их нельзя вынести в отдельные инсталяторы это уже вопрос к Microsoft.


Еще раз повторюсь, я не говорю, что какая-то реляционная база данных лучше других (при прочих равных я всегда выберу PostgreSQL или SQLite для своих проектов), каждая из них отлично решает поставленные перед ней задачи и в зависимости от этих задач предпочтительнее (но ни в коем случае не обязательно) использовать ту или иную базу данных.

Я не про инсталяр удивлялся, а про

и чего-то мне кажется, что мсскл в таком режиме сложится

сугубо на основе ощущений от прочих продуктов, тесно завязанных на экосистему винды. что IIS, что всякое 3rd-party ПО типа Directum производительностью не особо блещут.

По поводу инсталятора — в инсталятор MSSQL зашиты еще помимо самой базы данных различные сервисы SSAS, SSIS и прочие, которых естественно нет по умолчанию в инсталяре PostgreSQL (кстати я так на вскидку не могу назвать аналоги SSIS и SSAS в PotgreSQL, может кто подкинет ссылку?)

после беглого прочтения — возникло чувство, что это сродни конструкторам модулей импорта и анализа для непрограммистов. спорное решение, оптимальностью, уверен, в результате даже не пахнет — хотя может кому-то и сгодится, особенно в махровом энтерпрайзе…
после беглого прочтения — возникло чувство, что это сродни конструкторам модулей импорта и анализа для непрограммистов

SSIS — это конструктор модулей экспорта-импорта для программистов. Движок, который позволяет создавать скрипты заливки и преобразования данных между разными источниками. Есть такой класс инструментов, называется ETL. Это один из их представителей, и пожалуй, один из самых доступных.
С производительностью у него всё в порядке, а вот инструментарий так себе, как по мне, громоздкий и неудобный. Вместо корявого редактора многомегабайтных XML-скриптов там намного уместнее был бы какой-нибудь скриптовый язык.
SSAS — это OLAP-движок, тоже вполне себе хороший. Всё это можно заменить специализированными инструментами, конечно. Но вот в этой сфере с бесплатным опенсурсом как раз довольно туго, решения предлагают в основном крупные вендоры и за крупные деньги. Набор таких инструментов в комплекте с MS SQL в этом плане является весьма приятной плюшкой.
да-да, бегу и волосы назад после postgress прыгать в это болото.

Я ни в коем случае не заставляю, может давно просто прыгали? Последняя версия уже ближе к озеру.

Открыл пост, чтобы написать такой же комментарий, но вы меня опередили )))

Неужто open-source PostgreSQL лучше MSSQL? Я не принижаю PostgreSQL, сам его люблю и изучаю, но на рынке труда намного больше вакансий с MSSQL, да и всегда казалось, что проприетарное ПО в большинстве случае будет получше open-source.
но на рынке труда намного больше вакансий с MSSQL

Просто "ещё никого не увольняли за выбор продуктов Microsoft, Oracle и IBM", что наряду с откатами влияет на решения менеджмента.

UFO just landed and posted this here
… и тут мы пришли в linux-сообщество, в белом фраке… Серьезный такой первый аргумент.

ИМХО, вполне годный аргумент. Идеологические войны идут в основном между сисадминами, а директора обычно больше интересуются финансовой стороной. Если какой-то нужный компании продукт требует MS SQL в качестве СУБД, и есть возможность сэкономить на лицензии серверной винды, либо уже имеется Linux-инфраструктура, это может оказаться решающим преимуществом.
UFO just landed and posted this here
Но ведь это не причина, чтобы «попробовать MS SQL прямо сейчас», верно?

Ну так СУБД, это ведь не конечный продукт. Целевая аудитория СУБД — это как раз и есть те пользователи, которые либо производят/продают софт на данной платформе, либо занимаются его внедрением/поддержкой, либо являются покупателем такого софта. Во всех этих случаях предложение «попробовать» вполне уместно. Если вы продаёте клиентам софтину, которая может использовать MS SQL в качестве хранилища, вы вообще один из первых побежите пробовать новую конфигурацию, т.к. от этого непосредственно зависят ваши продажи.
UFO just landed and posted this here
стоимость windows server 2016: 1000 € за 16 ядер. меньше лицензировать нельзя.
стоимость sql server enterprise 2016: 16300 € за 2 ядра, умножаем на 8, получаем 130400 €.
Вывод: те кто берет sql server на стоимости windows экономить не станут, поэтому цена в данном случае не критерий.
Цены сильно округленные, но общую картину дают. Зачем брать именно enterprise? Потому что именно в этой редакции всё самое вкусное: партиционирование и онлайн перестройка индексов. Без них можно и на постгре данные хранить, если сильно замороченное BI не нужно.

Ну партициорование и онлайн перестройка индексов самое вкусное спорное утверждение, тем более что в SQL Server 2016 с выходом SP1 партициорование входит в стандартную редакцию.


Самое важное отличие редакции для бизнеса (enterprise) от стандартной по моему скромному мнению — это ограничение на использование ресурсов сервера, в стандартной версии они достаточно жесткие для больших баз данных: 4 сокета или 24 ядра и всего 128 ГБ ОЗУ. И именно ограничение по ОЗУ становится самым не приятным моментов ввиду активного продвижения In-Memory OLTP (In-Memory Optimization)

Если почитать форумы, какие проблемы возникают у postgress в сравнении с MSSQL, я бы не был так категоричен в таких утверждениях…
Это какие, не поделитесь?
Угу, конечно. Хотя бы тот же хабр почитать про PostgreSQL — админы MS SQL (и не только) из своего теплого уютного «болота» на это смотрят глазами по пять рублей и крестятся.
А что именно такого пугающего писалось на Хабр (или где-то ещё) о PostgreSQL?
Я вроде ничего сильно кошмарного не припомню.
Да хотя бы настройка отказоустойчивых схем работы.
А что с ней не так? Я за MS SQL не скажу, не админ, но, к примеру, в Oracle оно не сильно проще.
Ну берем и гуглим:

https://habrahabr.ru/company/etagi/blog/314000/
https://habrahabr.ru/post/280872/
https://habrahabr.ru/post/188096/
https://habrahabr.ru/post/301370/

Оцените количество ручной работы при развертывании. Просто развертывании, планирование оставляем за скобками. По сравнению с «щелк-щелк-щелк, и работает» у MS. И это я даже на комментарии на тему правильности реализации, возможных косяков и т.п. не обращаю внимания. «Так» это или «не так», пусть каждый для себя сам решает. Более того, я и сам могу назвать сценарии, где это неважно. Но читать, что MS SQL — это по сравнению с PostgreSQL «болото», тем не менее, немного смешно.
Да, я читал большую часть этих статей. Но я не припомню аналогичных статей про MS SQL (возможно просто не обращал внимания). Допустим, нам надо развернуть простейший отказоустойчивый кластер из двух нод. Просто Master/Standby, пусть даже с ручным переключением при отказе Master-а. Неужели в MS SQL (я правда этого не знаю) этот вопрос настолько тривиален, что решается путём «щёлк-щёлк и работает» (и тем самым не требует никакой писанины на Хабре)?
Неужели в MS SQL (я правда этого не знаю) этот вопрос настолько тривиален, что решается путём «щёлк-щёлк и работает»

Кстати, да. Я был приятно удивлен, но именно так. Правда, несколько лет назад я был неприятно удивлен, что отказоустойчивый кластер MS SQL из двух нод унёс с собой в могилу базы без возможности их восстановления, и пришлось несколько часов всё заново поднимать из бэкапов, но это уже другая история.
Да, нагуглил. Но тут вопрос «кошмарности» сильно субъективен. Для меня гораздо кошмарнее вот такие простыни скриншотов чем простые и понятные команды выполняемые с консоли. Серьёзно, я не прикалываюсь. Кстати как-то раз я напоролся с этим MS SQL 2005 «щёлк-щёлк». Ставил базу себе на комп (нужна была для одного проекта). И только через неделю заметил, что она молча отожрала половину винта (причём вопросов про диск во время установки я вообще не помню). Дружественный интерфейс имеет свои минусы. IMHO конечно.
Ну так это же просто вопрос привычной парадигмы работы. В виндовой среде традиционно любят GUI-мастера, в *никсовой — командную строку. Все те же опции, которые вы вводите через мастер, там доступны и из командной строки, если пользователю так удобнее.
Кстати, по поводу восстановления и могилы — это тоже важные вопросы. В Oracle (в PostgreSQL я новичок) я всегда чётко знаю, что и как происходит. В MS SQL для меня такой прозрачности нет. Всё скрыто красивыми картинками. Да были книжки на тему «MS SQL Inside», но по Oracle или PostgreSQL такой информации на порядок больше (или на порядки). А при восстановлении после всякого рода аварий понимание того что происходит крайне важно.
Само собой. Но я по такому случаю тогда обратился к профильным специалистам, которые знали, что там происходит. Они мне и выдали окончательное «свидетельство о смерти».
За большинством UI форм настройки MSSQL прячутся обычные команды к SQL.
Обычно, в форме есть кнопочки генерации SQL команд на основании изменений которые сделаны в форме.
Команды таким образом можно сохранить и использовать как душе угодно.
Это достаточно очевидный момент, но многие ли задаются вопросами о том, какие SQL-команды скрываются за UI формами? Можете не отвечать, я знаю, что не многие.
Вероятно, немногие.
UI подход снижает порог вхождения, при этом не ограничивает пытливые умы.
Еще раз, кнопочка «Script» есть практически в каждой форме настройки SQL сервера.
С бекапами не всё хорошо по сравнению с коммерческими СУБД.

Зато на виртуалках без жестких требований к RPO можно ничего не настраивать, так как потеряется лишь 600 мс транзакций перед бекапом ВМ без нарушения целостности БД.
delete из большой таблицы вообще довольно тухлая операция, в любой СУБД. А уж все эти пляски с limit-ами и rownum-ами… Откройте для себя партиционирование. Что касается оптимизатора, то пусть та СУБД в которой он идеален первая бросит в PostgreSQL камень. Несерьёзно всё это.

И чем бы мне в той задаче помогло партиционирование?..

Не пойдет, в таблице могут быть незакомиченные вставки — их удалять не надо. Если бы у меня была возможность монопольного доступа к базе — я бы всю таблицу целиком грохнул (после того как прочитал) и пересоздал бы ее заново.

Ну не пойдёт так не пойдёт, я ведь не знаю вашей задачи.
Возможно у вас change_log это не change_log, а что-то для хранения незакомиченных данных. Хозяин — барин.

Задача — простая. Перенести 20 миллионов записей из одной таблицы (в которую параллельно дописывают новые записи) в другую базу.


Разумеется, любая операция записи может проводиться в транзакции, а транзакция проходит не мгновенно.

В такой постановке это не задача. Перенести данные можно сотней различных СУБД-зависимых способов. Тот способ который выбрал бы я зависит от подробностей, огласить которые вы не озаботились. Одно могу сказать точно. delete from t in (select id… limit ...) это последнее из того, что я стал бы использовать для удаления уже перенесённых записей. Разумеется, если речь действительно идёт об удалении 20 миллионов записей из таблицы содержащей, для примера 200 миллионов. И дело здесь совсем не в оптимизаторе.

Хорошо, объясняю подробнее. Есть оперативная БД, есть аналитическая. Нужна ETL-обработка, которая бы переносила данные из одной БД в другую раз в сутки. Для этого в оперативную БД добавили триггеры и таблицу change_log, чтобы отслеживать произошедшие изменения.


Из-за серии ошибок в ETL-обработках они не работали довольно долго, к тому же за ошибками никто не следил (потому что аналитика еще не написана, данные в аналитической БД складируются на будущее), из-за чего в оперативной БД в этой самой таблице скопилось 20 миллионов записей. Когда меня кинули на этот проект — ETL никак не могла перенести записи из-за тайм-аута при получении данных.


Первой попыткой было ограничение числа записей, переносимых за 1 операцию. Это позволило бы в цикле разобрать накопившуюся очередь — и в SQL Server даже сработало бы. Но в Postgres не оказалось способа переносить данные "по частям" не теряя при этом изменения, которые идут параллельно.


Поэтому в итоге пришлось делать отдельные ветки для переноса старых данных и свежих.

Ну опять же, не знаю всех ваших подробностей. Например о том можно ли останавливать оперативную БД и находится ли она на том же инстансе что и аналитическая или нет (подозреваю что нет на оба вопроса). Но кое что уже проясняется. Например то, что операция по разгребанию 20 миллионов записей разовая, а не периодически выполняемая в рамках какого-то тех.процесса. С учётом того, что я знаю, я бы постарался:

  1. Остановить перенос данных
  2. Приостановить оперативную обработку (очень ненадолго)
  3. Cклонировать change_log в другую таблицу (если есть место)
  4. Очистить change_log (truncate-ом или пересоздав таблицу)
  5. Возобновить оперативную обработку
  6. Неспеша перенести клон, обработать его в аналитической БД и дропнуть в оперативной
  7. Возобновить перенос данных (в change_log накопятся новые данные, но, вероятно (опять не знаю подробностей) немного

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

delete… in (select… limit) продолжаю считать крайне неудачной идеей. Например, не вижу как он поможет с пресловутыми незакомиченными данными. Ну и delete 20 миллионов записей это в любом случае очень плохо. Просто замусоривание REDO-лога (ну или дары богу вакуума в Постгресе)

Так я о том и говорю, что в Postgres нужно делать что-то еще — в то время как в MS SQL довольно простое исправление запроса позволяет ему разбираться с любыми объемами данных.


delete… in (select… limit) продолжаю считать крайне неудачной идеей.

Такой она и оказалась (из-за не очень умного оптимизатора запросов, предпочитающего Hash и Merge там, где нужен Nested Loops).


Например, не вижу как он поможет с пресловутыми незакомиченными данными.

Очень просто — они не попадают в выборку и переносятся в следующий день.

Не буду спорить поскольку не очень хорошо знаю MS SQL. Да, в выборку не попадают. Нет, дело не в оптимизаторе. Удаление большого объёма данных просто крайне затратная операция с точки зрения ненужного журналирования, вот и всё. Будет ли там Nested Loop или Merge Join не так уж и важно на этом фоне. Проще пересоздать таблицу.

Эта операция не более затратна с точки зрения журналирования, чем создание тех же записей :) То есть с точки зрения амортизационного анализа — delete вместо truncate просто удваивает ресурсы, требуемые для вставки.


Я же говорю про время работы. Merge Join сам по себе неплох — но операция Sort перед ним означает чтение всей таблицы целиком, что не вписывается ни в какой тайм-аут.

Ну а зачем мне удваивать время вставки 20 миллионов записей? В MS SQL я не удалял такие объёмы, не приходилось, но когда я делаю это в PostgreSQL или Oracle я даже не пытаюсь удалять миллион записей из 10 миллионов. Я пересоздаю таблицу с нужными мне записями и дропаю старую. Именно потому-что знаю насколько по времени затянется такой delete (пробовал как-то раз). Причём, я говорю о delete по простому условию (на дату из первичного ключа, например), без всяких подзапросов. Так что оптимизатор здесь совершенно не при чём.

При нормальном режиме работы там такого большого количества записей никогда не накопится. А время выполнения разовой операции никому не интересно — пусть хоть месяц крутится, лишь бы количество записей в таблице в течении этого месяца уменьшалось, а не росло.

Оно мне интересно, когда я время от времени выполняю такие разовые операции. Гораздо веселее пересоздать таблицу за пару минут чем ждать минут двадцать (при том что в это время кто-то ещё и капает на мозги). Я знаю о чём говорю.

Вот чтобы не капали на мозги — и надо обходиться без приостановки оперативной обработки :)


Если понадобится — я просто удалю в БД информацию о прошлой выгрузке — после чего следующий запуск ETL автоматически пойдет по альтернативному пути. Это куда проще и веселее, чем пересоздавать таблицу вручную.

Вот видите, я же вас не учу, поскольку не знаю ваших обстоятельств?
Вы моих тоже не знаете.
Интересный вопрос относительно поддержки Linux. В замечательной статье Microsoft SQL Server на Wikipedia указывается, что первая версия под Windows NT существенно повысила производительность путём выбрасывания уровня абстракции API из стека SQL->Unix->NT и использования напрямую вызовов NT (SQL->NT).

Какова сейчас ситуация с MS SQL под Linux? Был снова добавлен уровень абстракции системных вызовов в обратную сторону (SQL->NT->Linux)?
Я думаю, не слишком ошибусь, если предположу, что в ядре за прошедшую четверть века наросло столько уровней абстракций, что добавление библиотеки под системное API другой ОС даже не потребовало добавления нового слоя.
Перечислив плюсы, надо перечислить и минусы текущего момента. А минусов в лицензировании предостаточно в последние годы:

2012: «Кинули» (извините, другого слова не подберу) пользователей SQL Enterprise Server+CAL, даже тех, у кого была подписка на SA: продолжать использовать можно (даже новую версию, если есть SA), но новые CAL (по истечении текущего контракта SA, у кого он был, и немедленно, у кого не было) купить нельзя. Вложены огромные деньги в десятки и сотни лицензий, фирма растёт, а для новых сотрудников купить дополнительные лицензии нельзя. И это ведь не лицензии на непосредственную работу с базой данных, сидит сотня операционистов, заполняет в своей программе какое-нибудь поле, а это поле (даже через 5 промежуточных серверов) попадает в SQL Server — всё, пользователю нужна CAL.

2014: Подняли цены почти в 2 раза, заодно сменив систему лицензирования с per-processor на per-core (то же, что в 2016 сделали с Windows Server). Теперь, купив «безлимитную» лицензию, вы должны докупать ещё по кусочку «безлимита» после обновления сервера, если в новом сервере больше ядер. А как весело в Microsoft смеялись с этой идеи ещё в 2013!

2016: Теперь, простите, «кинули» пользователей SQL Server Business Intelligence (2012-2014). Сценарий ещё хуже, чем в 2012 — можете использовать, но ни новых CAL нельзя купить (несчастным владельцам SA разрешили, с барского плеча, докупить ещё не более 25% CAL), ни новую версию использовать. Формально — можно использовать Enterprise Server+CAL 2016, но она не даёт, насколько я понимаю, исключения из правил мультиплексирования, а без этого исключения SQL BI — бессмысленна. Там, где для SQL 2014 BI нужно пару десятков SQL BI CAL для начальства, просматривающего аналитику, может понадобиться тысяча-другая SQL Enterprise CAL за счёт мультиплексирования, но сколько б их не было надо, их в продаже нет с 2012 года.

Так что покупая Microsoft SQL Server, можно быть уверенным только в том, что назад лицензию не отберут. Можно ли будет завтра докупить лицензий для новых сотрудников, перейти на новую версию, обновить процессор — лотерея, и никакая подписка SA ничего не значит.

Ого, спасибо за развернутый комментарий, много полезной информации. Вы случайно не занимаетесь закупками лицензиями? Если да, и у вас есть немного свободного времени, не могли бы вы кратко описать стоимость покупки лицензий для SQL Server в России?

Цены найти нетрудно, а все скидки индивидуальны и для анализа нужно много источников.
Ввиду этих проблем и еще других мы тоже начала переползать на PostgreSQL. 1С уже на нем и 3 год полет нормальный. По немногу и другой софт переделываем.
Вы явно некоторые вещи путаете. Навскидку как минимум:
Подняли цены почти в 2 раза, заодно сменив систему лицензирования с per-processor на per-core (то же, что в 2016 сделали с Windows Server).

Во-первых, модель с Per Processor на Per Core поменялась уже в 2012, а не в 2014. Во-вторых, цены MS, конечно, подняла. Но не вдвое, и не связи с переходом на новую версию. Винить MS в обрушении курса рубля, думаю, всё-таки не стоит. :)
Сам факт плясок с лицензированием я не оспариваю, но остальным читателям всё-таки рекомендую не воспринимать описание проблем выше как истину в последней инстанции.
Ваша правда: там, где у меня написано 2014 следует читать 2012 — время летит быстро, казалось, что это было совсем недавно, потому и подумал, что в 2014. Что до сути — то она никуда не далась: процессоры на ядра обменяли как 1:4 (за исключением тех, кто в 2012 имел SA, но им одноразовую поблажку дали), а популярные модели серверов уже тогда имели 6-8 ядер (а для SQL могли браться и более плотные), отсюда и подъём цены. Насколько помню аналитику тех времён — по опросам, в среднем получалось увеличение цены чуть менее чем в 2 раза.

Про цены я, по географическим причинам, могу говорить только в американских или канадских долларах, курс российского рубля не отслеживаю.
Я не знаю как вы общаетесь с Microsoft, но работая с множеством заказчиков у нас получалось не раз договорить с Microsoft и часто на выгодных для нас и на менее выгодных для них условиях. Поэтому проблему с CALL 2012 Enterprise выглядят по меньшей мере странно.
С ними ещё и договариваться можно? Или там с их дилерами? Эх, сколько организаций я подсадил на Линукс, просто потому что заходил на сайт дилера, смотрел сколько стоит та или иная лицензия и умножал на, скажем, 200, а руководство организаций офигивало от суммы, но на сайтах дилеров ничего вроде «звоните — договоримся не было» или «оптом дешевле» не было.
С ними ещё и договариваться можно? Или там с их дилерами?

Вот это штука, которая на первых порах вызывает большой когнитивный диссонанс, что со здоровенной корпорацией можно торговаться больше, чем с магазином одежды. Да, можно. За одну лицензию чего-нибудь вы особых условий себе вряд ли выторгуете, но если вы покупаете большой пакет софта, то плюшек можно получить много.
Давайте отделим ценообразование от отказа от продажи продуктов и клиентских лицензий к ним: цена для клиентов с EA, безусловно, отличается от прайс-листа, я же не об этом говорю.
Вы заявляете, что в официальных Licensing Guides написана неправда?

Откройте, на выбор, любую версию 2012, 2014 и увидите там:

As of July 1, 2012, Microsoft no longer offers the SQL Server Enterprise Edition under the Server+CAL license model. Current customers with active SA coverage for existing SQL Server 2008 R2 Enterprise Edition server licenses should consider the following when transitioning to SQL Server 2012:

● SQL Server 2012 Enterprise Edition server licenses ceased to be available on price lists after June 30, 2012.

● Enterprise Agreement (EA) and Enrollment for Application Platform (EAP) customers with active agreements
on this date can continue purchasing new licenses until the end of their current agreement term.


А вот цитаты из документа 2016 года:

Existing SQL Server 2016 Enterprise Edition server licenses continue to have tremendous value, and with the
availability of ongoing SA coverage, customers licensed under the Server+CAL model can retain access to the
latest product enhancements and advanced capabilities of Enterprise Edition. As such, there are no
programmatic conversions to core licenses.


SQL Server 2014 was the last version of the SQL Server Business Intelligence Edition. Customers with active SA coverage on qualifying Business Intelligence Edition server licenses on June 1, 2016 are eligible to upgrade to and use SQL Server 2016 Enterprise (Server+CAL) software with those licenses.

● During the current term of SA coverage (effective on or before June 1, 2016), customers who are
licensing SQL Server 2014 Business Intelligence Edition can, for a given deployment, upgrade to and use
the SQL Server 2016 Enterprise Edition (Server+CAL) software in place of the licensed SQL Server 2014
edition. Note: Customers who upgrade to SQL Server 2016 software are subject to current version
Enterprise Edition server license product terms.
[А условия использования Enterperise Server+CAL не содержат исключения для мультиплексирования.]

Customers with Enterprise Agreements effective on or before June 1, 2016 can continue to acquire
additional SQL Server 2014 Business Intelligence server licenses—and upgrade those licenses to SQL
Server 2016—through the end of their current enrollment term, as long as the number of new licenses
acquired does not exceed more than 25%
of the number of qualifying licenses acquired as of May 1,
2016.
sudo apt-get install -y mssql-server

Мир уже не будет прежним, если на сайте МС пишут такое
Тоже хотел это написать :) Лет 10 назад за такое бы высмеяли что линуксойды что виндовозники :)))
Это выглядит странно только если воспринимать apt как пакетный менеджер для опенсорсных программ, но на самом деле проприетарные бинарники через него давным давно распространяются, те же nvidia драйвера например
Это выглядит странным из-за самого факта наличия MS SQL под Linux + из-за общепринятой практики установки программ на Windows.
Это выглядит странным из-за самого факта наличия MS SQL под Linux
Не вижу ни чего странного, MS давно развивает интеграцию с Linux
+ из-за общепринятой практики установки программ на Windows.
А при чем тут установка программ в Windows, когда речь про установку программ в Linux
Я первый раз в жизни столкнулся с установкой продуктов MS через apt.

При том, что это установка программы от MS.
С моей точки зрения способ установки определяется целевой платформой, а не традициями разработчиков MS. Пока линукс не был широко распространен, MS до него как до целевой платформы дела не было и проблема установки софта MS в линуксе была проблемой любителей ПО для Windows. Сейчас ситуация изменилась, и поскольку MS решили выпустить ПО для линукс, то и распространять его они стали так, как этого ожидали пользователи линукс, как собственно и все остальные приличные производители проприетарного ПО для линукс.
Раньше уже сталкивался с установкой софта от MS под Linux. Это make && make install было.

Собственно шок от того, что MS решила стать именно приличным производителем ПО под Linux, не просто софт написали и делайте что хотите и(или) «запустите наш бинарник», а начала полноценно вписываться в экосистему.
MS — коммерческая компания специализирующаяся на проприетарном ПО, коммерческие продукты не возможно распространять с комментарием «делайте что хотите». А то что их разработчики развлекаются еще и написанием каких-то опенсорсных программ со статусом «мало кому нужное экспериментальное поделие» — так это ведь совсем другая история.
Я не про развлечения, а про, например, официальный odbc-драйвер к тому же MS SQL Server. Как по мне, то это (была?) сознательная политика. Ради избежания антимонопольных претензий выпускать продукты под платформы отличные от Windows, но выпускать их «сырыми», не интегрированными в экосистему этих платформ, с тем чтобы увеличивать стоимость владения инфраструктур на этих платформах.
Ради избежания антимонопольных претензий
Ну да, если компания сама не считает платформу целевой, то от антимонопольщиков толку мало
Так и не понял, в чем же заключается причина №3.

В SQL Server 2016 можно с помощью хранимой процедуры sp_execute_external_script выполнять R скрипты, также Microsoft выпустила собственную версию языка R, которая доступна в 2-х видах — Microsoft R Open (MRO) и Microsoft R Server (MRS).

также Microsoft выпустила собственную версию языка R
Очевидно, у обычного R обнаружился фатальный недостаток.
*facepalm*
Насчет удобства SSMS — до сих пор невозможно отображать вкладки с запросами в несколько рядов. Хорошо хоть есть возможность «прилепить» определенные запросы, а в настройках есть галка «отображать прилепленные в отдельной строке». Тогда можно сделать 2 ряда вкладок.
Мне Tabs Studio в этом очень помогает (это расширение для Visual Studio и SSMS, хоть и платное, но оправдало затраты полностью).

Спасибо за аддон, удобный он (добавил его в список, но только дороговат для своего функционала, хотя если цена одна для Visual Studio и SSMS, то может быть и стоит того.

Причина 0: Завтра всегда дороже, чем вчера!
SSMS становится просто вне конкуренции среди аналогичных коммерческих и бесплатных продуктов.

С выходом DataGrip от JetBrains спорное утверждение.

Ну так же он (DataGrip) платный?

Попробуйте DataGrip админить или хотя бы настроить сервера ;)
Хотя если выключить сарказм, то продукт перспективный. Но его еще долго нужно развивать
Раньше CU не рекомендовалось использовать на проде. Что-то поменялось?

Да. Теперь по заверениям Microsoft они также хорошо тестируются и готовы для использования на проде как и SP.

С этим не соглашусь что тестируется все тщательно. То и дело после каждого CU то хинт NOLOCK к блокировкам приводит (это из последних приколов), то всякие траблы с производительностью вылазят. Я как ставил SP так это и делаю… и то опять же после того как все протестирую.
Люблю MSSQL, но после ситуации, когда вышла 2012 и закрыли продажи 2008 лицензия Enterprise на процессор в 1 млн за 2 процессора выросла до 8 млн без возможности купить старую версию.
Прежде чем использовать это в своем проекте нужно 1000 раз подумать, завтра тебе нужен будет ещё один сервер и цена может опять вырасти в несколько раз.
Возможна ли установка SQL Server 2014 Developer Edition на Windows Servers с целью тестирования?

В пункте 2 ссылка на статью где этот вопрос подробно разобран со ссылками на Microsoft: https://www.littlekendra.com/2016/07/12/is-user-acceptance-testing-covered-under-developer-edition/


Customers cannot use the software in a production environment, and any test data that was used for design, development or test purposes must be removed prior to deploying the software for production use.


So be very careful if your User Acceptance Testing environment is used to “stage” data that is later restored to production. Per the 2014 rules, that is a production system.

В общем тестировать можно, главное не использовать потом для восстановления на проде.

Я не настоящий админ, я bash на стройке нашел, но когда попробовал поставить MS SQL Server 2016 Developer Edition из Express Installer в настоящем корп. окружении — он просто не смог скачать основной ISO. Без всякой диагностики. Пришлось руками искать на сайте микрософт (где 2014, 2016 и другие версии перемешаны неясным порядком) и скачивать 2GB образы.
Еще из приятного — ставите галку установить R Server — на этапе установке инсталлер запросится в интернет. Надо откатываться назад до этапа конфигурации убирать галку и снова с песней.
После этого говорить о том, что это делается для корп окружения (которое с самого начала кремния сидело за прокси), наверное рановато.
А как там с интеграцие с AD? Аутентификацией/Авторизацией через учетки AD?

Там это где? В SQL Server 2016 или в SQL Server VNext под Linux? В SQL Server 2016 все хорошо, VNext под Linux пока нет возможности протестровать, возможно кто-то уже опробовал в корпоративной среде?

Конечно же имелся в виду SQL Server VNext под Linux.
И хотелось бы услышать ребят из Microsoft по данному вопросу.
Sign up to leave a comment.

Articles