Около недели назад здесь была интересная статья о методах организации видеотрансляций с минимально возможной задержкой, и в комментариях прозвучал ряд закономерных вопросов, на многие из которых я не увидел полноценного и содержательного ответа. В своём посте я хотел бы дополнить материал коллег, и поделиться с читателями своими мыслями по следующим вопросам:

Зачем вообще нужна минимальная задержка?
Как можно просто и наглядно замерять задержку при трансляции видеосигнала?
Какие элементы видеотракта влияют на увеличение задержки?


Наш топовый результат — FullHD сигнал пролетел до сервера и обратно менее чем за полсекунды.

Интересно? Тогда читайте дальше.

HP LaserJet 1000 — отличная рабочая лошадка, быстрый и безотказный принтер с USB интерфейсом с низкой стоимостью отпечатка. В статье я опишу сложности и тонкости настройки софт-принтеров HP для работы через роутер по сети на примере своего LJ1000. Велкам под кат!

Вероятно, вы знаете, что обслуживание баз данных это целый комплекс процедур: создание бэкапов, проверка целостности, обслуживание индексов, статистики и т.д. На просторах сети (да и на Хабре в том числе) на эту тему написано множество статей и рекомендаций. Однако занимаясь внедрением «1С: Предприятие», нам частенько приходится сталкиваться с тем, что обслуживание баз данных настраивается либо неправильно, либо по очень упрощённой схеме. Например, чтобы не заморачиваться с управлением журналами транзакций, для «боевых» баз устанавливается Простая модель восстановления (Simple Recovery model). И это несмотря на то, что потеря информации за пару часов уже критична для компании. Иногда задача по сжатию файлов БД включается в регулярное обслуживание («шобы не росло»), или после обновления индексов идёт уничтожение статистики и прочие подобные ляпы. Так происходит потому, что чаще всего в компаниях нет опытного администратора БД и обслуживанием приходится заниматься кому-то из сотрудников ИТ-службы – «невольному» администратору баз данных (DBA). При этом такой DBA не всегда осознаёт все риски и возложенную на него ответственность.

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

Можно привести такой случай из жизни одного из наших сотрудников: в юности он переболел пневмонией, в результате чего все последующие годы на флюорограммах регистрировалось затемнение в лёгком. Участковый врач об этом прекрасно знал. Но однажды герою этой истории пришлось делать флюорографию в другой поликлинике. И там, увидев пятно, его едва не госпитализировали насильно, заподозрив туберкулёз. Никакие рассказы о пневмонии не помогли, пришлось ехать в свою поликлинику, просить свои старые снимки и везти их в качестве доказательства. Но даже после этого на него смотрели косо и пытались заставить еженедельно делать контрольные снимки. А ведь всех этих неудобств и нервотрёпок можно было бы избежать, будь у нас в стране хорошо развита система хранилищ медицинских данных регионального и городского уровней. Врач мог бы зайти туда и открыть всю историю болезней пациента начиная с рождения. Было бы снято множество вопросов и сэкономлена уйма времени.

Здравствуйте!
Основной целью статьи является осветить вопрос развития ИТ-инфраструктуры одной государственной бюджетной образовательной организации в условиях ограничения бюджета.

Цель публикации

1. поделиться опытом;
2. по возможности, получить отзывы и рекомендации.

Введение

Ни для кого не секрет, что движителем развития ИТ в организации могут быть:
А) отдел ИТ (или его представители).
Б) бизнес (или его представители).

В любом из двух крайних положений – это плохо! Решение находиться где-то посередине. На стыке бизнеса и представителей ИТ – тех, кто зарабатывает деньги и тех, кто создает условия для того, чтобы можно было зарабатывать деньги комфортно, безопасно, надежно, стабильно, много и т.д.

Для решения любой проблемы необходимо сделать первый шаг – признать ее существование (проблемы). Затем планомерно выполнить следующее:
А) описать ее, понять причины;
Б) поставить задачи по устранению причин и недопущению их в будущем;
В) решать поставленные задачи и отслеживать, контролировать состояние, поддерживая его в стабильном положении.
Это все лирика теория. Переходим к практике.

“Что для вас современное программное обеспечение для офиса? Какие IT-задачи поставлены перед вами?” — именно с такими вопросами мы обратились к представителям малого и среднего бизнеса (SMB) с целью понять их осведомленность, степень готовности и способы решения IT-проблем. В результате опроса обнаружилась довольно низкая информированность о возможных предложениях на рынке софта.

Почему так происходит? — Догадаться не сложно. Во-первых, в условиях высокой конкуренции в приоритете производственная деятельность и продажи, на продумывание поиска и выбора ПО для офиса элементарно не остается времени. Во-вторых, цена популярных продуктов для сегмента SMB кусается.

Именно для таких компаний мы подготовили выборку из 11 надёжных, недорогих и простых, но в то же время нужных решений для организации эффективной работы офиса, а также провели тестирование совместимости некоторых из них между собой, а также с корпоративным решением IT-безопасности — Traffic Inspector.

В новости «ОСТОРОЖНО. Вирус-шифровальщик Trojan.Encoder.225» я уже подробно рассказывал об одном конкретном вирусе Trojan.Encoder.225, но, на тот момент, решения по расшифровке я так и не получил.
Но в последствии (спустя 3 с лишним недели после начала дэшифровки) ситуация изменилась в лучшую сторону. За этот период мною были успешно расшифрованы данные сразу после двух вирусов Trojan.Encoder.225 и Trojan.Encoder.263 на разных ПК.

После разбора теории процессов и практических советов для резервного копирования виртуализованного SQL Server перейдем к рассказу о восстановлении баз данных с помощью Veeam Explorer for Microsoft SQL Server. Этот инструмент позволяет восстановить базу на исходный или на другой сервер без необходимости поднимать сам сервер из резервной копии.

В общем виде процесс восстановления с участием Veeam Explorer происходит так:

Добрый день, хабрасообщество. Мне хотелось бы продолжить рассмотрение аспектов реализации DICOM Viewer'а, и сегодня речь пойдёт о функциональных возможностях.


Итак, поехали.

Доброго времени суток, уважаемые читатели!

Данный пост будет интересен тем, кто использует SQL Server Management Studio (SSMS) при работе c SQL Server.
Речь пойдет о расширении SQL Refactor Studio для SSMS.
Данное расширение позволяет значительно сэкономить время на ежедневных рутинных операциях.

Практически ни один серьезный пентест не обходится без проверки СУБД, ведь это одна из самых популярных у злоумышленников дверей к желаемой информации и машине. В крупных проектах в качестве СУБД очень часто используется MS SQL Server. И о проверке именно его безопасности мы сегодня и поговорим. Открывать Америку не будем — опытные камрады лишь освежат свои знания, а вот для тех, кто только начинает осваивать тему, я постарался максимально подробно разложить все по пунктам.

MySQL — одна из самых распространенных СУБД. Ее можно встретить повсюду, но наиболее часто она используется многочисленными сайтами. Именно поэтому безопасность базы данных — очень важный вопрос, ибо если злоумышленник получил доступ к базе, то есть большая вероятность, что он скомпрометирует не только ресурс, но и всю локальную сеть. Поэтому я решил собрать всю полезную инфу по взлому и постэксплуатации MySQL, все трюки и приемы, которые используются при проведении пентестов, чтобы ты смог проверить свою СУБД. 0day-техник тут не будет: кто-то еще раз повторит теорию, а кто-то почерпнет что-то новое. Итак, поехали!

В данной статье хотел бы рассказать про набор полезных дополнений к Visual Studio, которые могут в значительной мере облегчить разработку баз данных на основе MS SQL Server.
Основными преимуществами использования SSDT я бы выделил следующее:

• возможность простого изменения (refactoring) схемы базы (можно переименовать колонку таблицы и все Views, Functions и Stored Procedures ссылающиеся на неё автоматически будут исправлены для отражения изменений)
• создание юнит тестов для базы данных
• хранение структуры базы данных в Source Control
• сравнение схемы/данных c возможностью генерации скрипта для приведения схемы/данных к требуемому состоянию

Безусловно на этом плюсы использования SSDT не заканчиваются, но остальное не так сильно впечатляет, как то, что упомянуто выше. Если вас интересует, как воспользоваться этими и другими преимуществами — прошу под кат.

Предыдущие части

• Часть первая — habrahabr.ru/post/255361
• Часть вторая — habrahabr.ru/post/255523
• Часть третья — habrahabr.ru/post/255825

В данной части мы рассмотрим

Многотабличные запросы:

• Операции горизонтального соединения таблиц – JOIN
• Связь таблиц при помощи WHERE-условия
• Операции вертикального объединения результатов запросов – UNION

Работу с подзапросами:

• Подзапросы в блоках FROM, SELECT
• Подзапрос в конструкции APPLY
• Использование предложения WITH
• Подзапросы в блоке WHERE:
  
  • Групповое сравнение — ALL, ANY
  • Условие EXISTS
  • Условие IN

Предыдущие части

• Часть первая — habrahabr.ru/post/255361
• Часть вторая — habrahabr.ru/post/255523

О чем будет рассказано в этой части

В этой части мы познакомимся:

1. с выражением CASE, которое позволяет включить условные выражения в запрос;
2. с агрегатными функциями, которые позволяют получить разного рода итоги (агрегированные значения) рассчитанные на основании детальных данных, полученных оператором «SELECT … WHERE …»;
3. с предложением GROUP BY, которое в скупе с агрегатными функциями позволяет получить итоги по детальным данным в разрезе групп;
4. с предложением HAVING, которое позволяет произвести фильтрацию по сгруппированным данным.

Вступление и DDL – Data Definition Language (язык описания данных)

Часть первая — habrahabr.ru/post/255361

DML – Data Manipulation Language (язык манипулирования данными)

В первой части мы уже немного затронули язык DML, применяя почти весь набор его команд, за исключением команды MERGE.

Рассказывать про DML я буду по своей последовательности выработанной на личном опыте. По ходу, так же постараюсь рассказать про «скользкие» места, на которые стоит акцентировать внимание, эти «скользкие» места, схожи во многих диалектах языка SQL.

Т.к. учебник посвящается широкому кругу читателей (не только программистам), то и объяснение, порой будет соответствующее, т.е. долгое и нудное. Это мое видение материала, которое в основном получено на практике в результате профессиональной деятельности.

Основная цель данного учебника, шаг за шагом, выработать полное понимание сути языка SQL и научить правильно применять его конструкции. Профессионалам в этой области, может тоже будет интересно пролистать данный материал, может и они смогут вынести для себя что-то новое, а может просто, будет полезно почитать в целях освежить память. Надеюсь, что всем будет интересно.

Т.к. DML в диалекте БД MS SQL очень сильно связан с синтаксисом конструкции SELECT, то я начну рассказывать о DML именно с нее. На мой взгляд конструкция SELECT является самой главной конструкцией языка DML, т.к. за счет нее или ее частей осуществляется выборка необходимых данных из БД.

О чем данный учебник

Данный учебник представляет собой что-то типа «штампа моей памяти» по языку SQL (DDL, DML), т.е. это информация, которая накопилась по ходу профессиональной деятельности и постоянно хранится в моей голове. Это для меня достаточный минимум, который применяется при работе с базами данных наиболее часто. Если встает необходимость применять более полные конструкции SQL, то я обычно обращаюсь за помощью в библиотеку MSDN расположенную в интернет. На мой взгляд, удержать все в голове очень сложно, да и нет особой необходимости в этом. Но знать основные конструкции очень полезно, т.к. они применимы практически в таком же виде во многих реляционных базах данных, таких как Oracle, MySQL, Firebird. Отличия в основном состоят в типах данных, которые могут отличаться в деталях. Основных конструкций языка SQL не так много, и при постоянной практике они быстро запоминаются. Например, для создания объектов (таблиц, ограничений, индексов и т.п.) достаточно иметь под рукой текстовый редактор среды (IDE) для работы с базой данных, и нет надобности изучать визуальный инструментарий заточенный для работы с конкретным типом баз данных (MS SQL, Oracle, MySQL, Firebird, …). Это удобно и тем, что весь текст находится перед глазами, и не нужно бегать по многочисленным вкладкам для того чтобы создать, например, индекс или ограничение. При постоянной работе с базой данных, создать, изменить, а особенно пересоздать объект при помощи скриптов получается в разы быстрее, чем если это делать в визуальном режиме. Так же в скриптовом режиме (соответственно, при должной аккуратности), проще задавать и контролировать правила наименования объектов (мое субъективное мнение). К тому же скрипты удобно использовать в случае, когда изменения, делаемые в одной базе данных (например, тестовой), необходимо перенести в таком же виде в другую базу (продуктивную).

Индексы — это первое, что необходимо хорошо понимать в работе SQL Server, но странным образом базовые вопросы не слишком часто задаются на форумах и получают не так уж много ответов.
Роб Шелдон отвечает на эти, вызывающие смущение в профессиональных кругах, вопросы об индексах в SQL Server: одни из них мы просто стесняемся задать, а прежде чем задать другие сначала подумаем дважды.

Как dba и консультант по оптимизации производительности SQL Server в Ambient Consulting, я часто сталкиваюсь с необходимостью анализа узких мест производительности на экземплярах SQL Server, которые вижу первый раз в жизни. Это может быть сложной задачей. Как правило, у большинства компаний нет документации по их базам данных. А если есть, то она устарела, или же её поиск занимает несколько дней.

В этой статье я поделюсь базовым набором скриптов, раскапывающим информацию о метаданных с помощью системных функций, хранимых процедур, таблиц, dmv. Вместе они раскрывают все секреты баз данных на нужном экземпляре – их размер, расположение файлов, их дизайн, включая столбцы, типы данных, значения по умолчанию, ключи и индексы.

Если вы когда-нибудь пытались получить часть этой информации, с помощью GUI, я думаю вы будете приятно удивлены количеством той информации, которая, с помощью этих скриптов, получается мнгновенно.

Как и с любыми скриптами, сначала проверьте их в тестовом окружении, прежде чем запускать в продакшене. Я бы рекомендовал вам погонять их на тестовых базах MS, таких как AdventureWorks или pubs.

Ну, хватит слов, давайте я покажу скрипты!