Поиск планов выполнения по названию индекса

Ниже приведенный скрипт позволяет осуществлять поиск, в каким планах выполнения использовался указанный индекс:

DECLARE @op sysname = 'Index Scan';
DECLARE @IndexName sysname = 'YOUR_INDEX_NAME';

;WITH XMLNAMESPACES(DEFAULT N'http://schemas.microsoft.com/sqlserver/2004/07/showplan')
SELECT
cp.plan_handle
,operators.value('(IndexScan/Object/@Schema)[1]','sysname') AS SchemaName
,operators.value('(IndexScan/Object/@Table)[1]','sysname') AS TableName
,operators.value('(IndexScan/Object/@Index)[1]','sysname') AS IndexName
,operators.value('@PhysicalOp','nvarchar(50)') AS PhysicalOperator
,cp.usecounts
,qp.query_plan,
t.text
FROM sys.dm_exec_cached_plans cp
CROSS APPLY sys.dm_exec_query_plan(cp.plan_handle) qp
CROSS APPLY sys.dm_exec_sql_text(cp.plan_handle) AS t
CROSS APPLY query_plan.nodes('//RelOp') rel(operators)
WHERE operators.value('@PhysicalOp','nvarchar(50)') IN ('Clustered Index Scan','Index Scan')
AND operators.value('(IndexScan/Object/@Index)[1]','sysname') = QUOTENAME(@IndexName,'[');

Позы программистов

Итак, пятница, почти конец рабочего дня… Программистам посвящается.

Утро, начало рабочего дня — Миссионерская поза


Пятница, вечер, до конца работы остался час — Позиция «Позвоночник Кобры»

Глубокой ночью: О да, это будет самая лучшая программа в мире!.. — Позиция «Игривый сверчок»

Позиция «Секретничающий бурундук»
Применяется при внезапном и неудачном появлении босса или коллег по работе.

Позиция «Разъярённая Годзилла»
Когда уже ничего, включая отладчик, не помогает… будь вы все прокляты!

Позиция «Долбаный неудачник»
На следующий день после «Разъярённой годзиллы», в ожидании трудовой книжки после увольнения.

SOLID

Очень коротко, своими словами, что из себя представляют эти небезынтересные 5 концепций написания красивого кода.
SOLID расшифровывается как:

1. S – Single responsibility principle
Каждый класс должен иметь только одну причину для изменения, только одну ответственность. Не нужно делать помоечные классы, которые и ходят в базу, и вычисляют какие-то характеристики для бухгалтерии, и генерируют графики для веб-интерфейса. Один класс – одна задача. При таком подходе приложение легче изменять, тестировать, поддерживать.
Читать запись полностью »

Один маленький недостаток пула потоков

Пул потоков в .Net framework представляет собой довольно мощный и хорошо отлаженный механизм управления потоками. Какждый раз при выполнении новой задачи новый поток не создается, вместо этого он берется из пула за символическое время. Таким образом минимизируется воздействие на производительность, которое было бы недопустимо значимым, если бы каждый раз поток создавался заново.

Работа с пулом потоков в .Net проста и заключается в вызове метода

ThreadPool.QueueUserWorkItem(SomeAction, data);

При этом вся работа по синхронизации потоков проводится аналогично, как и при использовании потоков без пула.
Однако, есть в Threads pool и один недостаток, который делает невозможным его использования в некоторых сложных системах. Заключается этот недостаток в том, что пул потоков в .Net имеет внутреннее ограничение на максимальное число потоков и не позволяет его изменять извне. Сделано это по ряду причин. По умолчанию это ограничение составляет 1000 потоков. Предполагается, что больше 1000 нитей создавать нет смысла, да и не получится это. Ведь максимальное адресное пространство, доступное для процесса под управлением 32-разрядной системы составляет 2 гигабайта. А с учетом того, что каждый поток использует как минимум 1 мегабайт оперативной памяти для хранения своих системных данных, то получается что 1000 потоков уже займет не менее 1 гигабайта памяти. Плюс еще приложение расходует память на свои основные задачи. Вот и получается, что больше 1000 потоков создать на 32-разрядной системе может и не получится.

Однако, что если вы разрабатываете серверное приложение, которой скорей всего будет крутиться на 64-разрядной оси. В этом случае никаких ограничений на максимальное число потоков у вас нет (в практическом смысле). И теоретически для мощного многоядерного сервера может быть написано приложение, которое будет выполнять задачи, скажем в 50-100 потоков. Причем одновременно в некоторые моменты может пытаться выполнять несколько десятков таких задач. И в один прекрасный момент получится ситуация, когда все потоки тред пула будут заняты, и для новой задачи не останется свободного обработчика. Здесь мы получим в лучшем случае заддержку при обработке определенного таска, в худшем deadlock.

Поэтому при проектировании системы следует учесть, а подходит ли вам стандартный пул потоков .Net framework для ваших конкретных задач, или имеет смысл написать свой.

Стоит ли дорабатывать или переписывать работающий код

сын – Папа, а почему солнце всегда встает на восходе, а заходит на западе?
папа – Поворачивает голову с красно-воспаленными глазами к сыну
папа – Всегда восходит на востоке?
сын – Всегда
папа – Заходит всегда на западе?
сын – Да
папа – Ничего не глючит? все работает нормально?
сын – да, все нормально
папа – Ну так и не трогай там нихрена!

Порядок вызовов конструкторов

Что выведет на экран код, представленный ниже:

class Base
{
	public Base()
	{
		Console.WriteLine(100 / GetValue());
	}

	protected virtual Int32 GetValue()
	{
		return 1;
	}
}

class Derived : Base
{
	private Int32 value;

	public Derived()
	{
		value = 2;
	}

	protected override Int32 GetValue()
	{
		return value;
	}
}

class Program
{
	static void Main()
	{
		Console.WriteLine(new Derived());
	}
}

Что нового в MVC 4.0

<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.Web.Helpers"
             publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0" newVersion="2.0.0.0"/>
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Web.Mvc"
             publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0-3.0.0.0" newVersion="4.0.0.0"/>
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Web.WebPages"
             publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0" newVersion="2.0.0.0"/>
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>

@media handheld and (min-width: 20em), screen and (min-width: 20em) { ... }:

protected void Application_Start()
{
    AreaRegistration.RegisterAllAreas();
    RegisterGlobalFilters(GlobalFilters.Filters);
    RegisterRoutes(RouteTable.Routes);

	DisplayModes.Modes.Insert(0, new DefaultDisplayMode("iPhone")
	{
		ContextCondition = context =>
			context.Request.UserAgent != null &&
			context.Request.UserAgent.IndexOf("iPhone", StringComparison.OrdinalIgnoreCase) >= 0
	});
}

@{
    Layout = "~/Views/Shared/_Layout.cshtml";
    DisplayModes.RequireConsistentDisplayMode = true;
}

<meta charset="utf-8" />
<title>@ViewBag.Title</title>
<meta name="viewport" content="width=device-width" />

Я хочу стать программистом

Режимы работы Garbage Collector в .Net framework

Каждый кто хотя бы раз занимался оптимизации .Net приложений и анализировал их с помощью какого-либо профайлера, например, dotTrace, наверняка знает, что довольно-таки значимую часть ресурсов процессора потребляет Garbage Collector.

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

Первое, о чем хотелось бы поговорить, это свойство IsServerGC класса GCSettings. В случае если ваше приложение является серверным, и при этом на сервере оно является доминирующей аппликацией, то имеет смысл установить это свойство в True. При этом GC будет использовать процессор сервера на полную катушку, таким образом увеличив производительность сборщика мусора. Установить это свойство в True можно, внеся следующие изменения в конфигурационный файл приложения:

<configuration>
  <runtime>
    <gcServer enabled="true" />
  </runtime>
</configuration>

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

• Interactive – значение по умолчанию. Походит для большинства десктопных приложений.
• Batch – можно обратить внимание на этот вариант, если ваше приложение является серверным.
• LowLatency – с данным режимом работы Garbage Collector нужно быть очень осторожным. При этом работа коллетора практически полностью прекращается, и вся ответственность за стабильность работы приложения ложится на плечи разработчика. Данную опцию имеет смысл включать на очень короткое время при выполнении особенно критических операций. Устанавливать LowLatency следует только таким способом:

GCLatencyMode oldMode = GCSettings.LatencyMode;
RuntimeHelpers.PrepareConstrainedRegions();
try {
GCSettings.LatencyMode = GCLatencyMode.LowLatency;
// perform time-sensitive actions here
}
finally {
GCSettings.LatencyMode = oldMode;
}

В данной реализации необходимо убедиться, что старый Latency Mode будет восстановлен при любом исходе выполнения блока try. Для этого используется блок finally, а также механизм Constrained Execution Regions.

Отличное описание работы горбатого коллектора есть в первоисточнике.

Валидный HTML