Разрастание кэша TFS на сервере

У вас на сервере TFS могут возникать проблемы с местом из-за разрастания кэша TFS, который хранится в папке:

• TFS 2012 - C:\Program Files\Microsoft Team Foundation Server 11.0\Application Tier\Web Services\_tfs_data
• TFS 2013 - C:\Program Files\Microsoft Team Foundation Server 12.0\Application Tier\Web Services\_tfs_data

Для того, чтобы кэш не разрастался больше фиксированного объёма, необходимо сконфигурировать файл web.config (для TFS 2013 находится в папке C:\Program Files\Microsoft Team Foundation Server 12.0\Application Tier\Web Services).

Внесите в раздел <appSettings> элемент:

 <add key="FixedSizeBasedPolicy" value="NNN" /> 

где NNN - количество мегабайт, больше которого кэш не должен разрастаться.

Например, если вы хотите, чтобы кэш не разрастался более 500 Мб, у вас должно быть:

...

<appSettings>

...

 <add key="FixedSizeBasedPolicy" value="500" /> 

...

</appSettings>

Источник: http://msdn.microsoft.com/en-us/library/ms400793.aspx

Оповещение о создании/удалении баз данных на MS SQL Server

USE master;

GO

CREATE TRIGGER [os_Trigger_Notification_CreateDrop_Database] 

ON ALL SERVER FOR CREATE_DATABASE, DROP_DATABASE 

AS 

declare @results varchar(max)

declare @subjectText varchar(max)

declare @subjectBegin varchar(255) 

declare @databaseName VARCHAR(255)

BEGIN

SET NOCOUNT ON;

SET @results = (SELECT EVENTDATA().value('(/EVENT_INSTANCE/TSQLCommand/CommandText)[1]','nvarchar(max)'))

SET @databaseName = (SELECT EVENTDATA().value('(/EVENT_INSTANCE/DatabaseName)[1]', 'VARCHAR(255)'))

SET @subjectBegin = 'Создана'

IF (LEFT(@results,4) = 'DROP') SET @subjectBegin = 'Удалена'

SET @subjectText = @subjectBegin + ' база данных на сервере ' + @@SERVERNAME + ' пользователем ' + SUSER_SNAME() 

EXEC msdb.dbo.sp_send_dbmail

@profile_name = 'MailProfile',

@recipients = 'user@example.ru',

@body = @results,

@subject = @subjectText;

END

Для удаления триггера используйте:
DROP TRIGGER [os_Trigger_Notification_CreateDrop_Database] ON ALL SERVER; 
GO

Ссылки:

• Проектирование триггеров DDL 
• Использование функции EVENTDATA  

TFS Planning Guide

Обязательный к прочтению для администратора TFS: http://vsarplanningguide.codeplex.com/

Перенос базы TempDB в новое место

USE master
ALTER DATABASE tempdb MODIFY FILE(Name = tempdb, Filename = N'C:\NewFolder\tempdb.mdf')
GO

ALTER DATABASE tempdb MODIFY FILE(Name = templog, Filename = N'C:\NewFolder\templog.ldf')
GO

Если необходимо добавить файлы данных для базы TempDB (учитывая рекомендации в соответствии с количеством процессоров):

ALTER DATABASE tempdb
ADD FILE (NAME = tempdev2, FILENAME = 'C:\NewFolder\tempdb2.mdf', SIZE = 256);
ALTER DATABASE tempdb
ADD FILE (NAME = tempdev3, FILENAME = 'C:\NewFolder\tempdb3.mdf', SIZE = 256);
ALTER DATABASE tempdb
ADD FILE (NAME = tempdev4, FILENAME = 'C:\NewFolder\tempdb4.mdf', SIZE = 256);
GO

HammerDB - оценка производительности SQL-сервера

HammerDB (бывший Hammerora) - бесплатный инструмент, позволяет проводить TPC-подобные тесты (TPC-C и TPC-H) различных СУБД: Oracle, Microsoft SQL Server, PostgreSQL, Greenplum, MySQL и Redis.

Скачать: http://hammerora.sourceforge.net/download.html

Сценарий восстановления базы данных с помощью параметра REPAIR_ALLOW_DATA_LOSS

ps: перед использованием обязательно проконсультироваться с врачом прочитать MSDN.
ps2: не рекомендую использовать это в боевой системе без соответствующих знаний, чтобы не нанести вред.

USE [ИмяБазыДанных]

-- 1 шаг. Проверка базы на ошибки
DBCC CHECKDB([ИмяБазыДанных])

-- 2 шаг. Перевод базы в монопольный режим
ALTER DATABASE [ИмяБазыДанных] SET SINGLE_USER WITH ROLLBACK IMMEDIATE

-- 3 шаг. Перевод базы в аварийных режим
ALTER DATABASE [ИмяБазыДанных] SET emergency

-- 4 шаг. Восстановление базы
DBCC CHECKDB([ИмяБазыДанных], REPAIR_ALLOW_DATA_LOSS)

-- 5 шаг
ALTER DATABASE [ИмяБазыДанных] SET multi_user

Обслуживание TFS

1. В первую очередь...

• Применяйте все обновления безопасности. Используйте инструмент MBSA (http://go.microsoft.com/fwlink/?linkid=20567). Критические обновления безопасности должны применяться в течении 48 часов. 
• Используйте последнюю версию TFS.
• Используйте последнюю версию SQL.
• Используйте последнюю версию ОС.
• Используйте последние версии драйверов оборудования (особенно NIC и SAN/HBA драйвера).

2. Настройка ОС и регулярные задачи

• Соберите все данные с базовых счётчиков производительности, чтобы выявить узкие места. В будущем это также послужит полезным инструментом диагностики. Необходимо собрать данные счётчиков в рабочий день в течении 24 часов с интервалом 1-5 мин. Не знаете какие счётчики собирать? Используйте инструмент PAL (http://pal.codeplex.com/) с шаблонами "System Overview" and "SQL Server".
• Обеспечите антивирусные исключения для TFS, SQL и SharePoint (http://support.microsoft.com/kb/2636507) 
• Обеспечите корректные правила для Firewall.
• Убедитесь, что настроен полный дамп памяти (http://support.microsoft.com/kb/254649). При сбое это существенно повысит ваши шансы на исправление причины неполадки. Используйте NotMyFault.exe для создания дампа вручную (http://support.microsoft.com/kb/969028).
• Не запускайте SQL и TFS под учётной записью локального администратора.

3. Настройка SQL

• Ознакомитесь со статьёй "SQL Server Best Practices Article" (http://technet.microsoft.com/library/Cc966412) перед развёртыванием SQL. Используйте SQLIO/IOMeter для сравнения производительности систем хранения.
• Используйте рекомендации IQ именно для SQL. См. статью "Storage Top 10 best practices" (http://technet.microsoft.com/en-US/library/cc966534).
• Сделайте проверку на выравнивание разделов диска (потенциально, можно увеличить производительность на 30%). Особенно эффект может быть заметен когда диски были добавлены в системе Windows Server 2003. См. статью http://technet.microsoft.com/en-us/library/dd758814(v=SQL.100).aspx
• Убедитесь, что включена "Instant File Initialization" (инициализация файлов базы данных). Для этого потребуется учётной записи SQL дать права "Perform Volume Maintenance Tasks" (выполнение задач по обслуживанию томов; SE_MANAGE_VOLUME)
• Используйте отдельные LUNs для data/log/tempdb/system
• Рекомендации по соответствию количества файлов количеству процессоров. См. Configuring TempDB for Optimal TFS Performance и TempDB should always have one data file per processor core.
• Рассмотреть возможность переноса таблицы tbl_Content в отдельную файловую группу для более гибкого управления.
• Рассмотреть возможность изменения значения "max degree of parallelism" (MAXDOP) в значение, отличное от "0". См. "Team Foundation Server Performance - SQL Server Configuration Settings"
• Рассмотреть возможность использования traceflags для SQL: T1211 (предотвратит эскалацию блокировки таблицы, см. KB934005 и здесь), T1118 (для TempDB, http://www.sqlskills.com/blogs/paul/misconceptions-around-tf-1118/), T1222 (https://www.simple-talk.com/sql/database-administration/handling-deadlocks-in-sql-server/), T1117 (авторасширение файлов для TempDB)
• Настроить хранение ежедневного SQL ErrorLog и хранение его за 30 последних дней (http://sqlblog.com/blogs/jonathan_kehayias/archive/2010/03/03/setting-sql-server-errorlog-retention-and-rollover-with-powershell.aspx) 
• Установите рекомендуемое значение "max server memory" для SQL Server (см. http://www.sqlskills.com/blogs/jonathan/how-much-memory-does-my-sql-server-actually-need/). Выделить 1 Gb для ОС, до 16 Gb выделить 1 Gb для SQL на каждые 4 Gb системы, после 16 Gb выделить 1 Gb для SQL на каждые 8 Gb системы. Для 32 Gb сервера необходимо выделить 25Gb=32-1-4-2 на SQL Server. Если у вас на SQL-сервере запущены SSRS/SSAS/TFS, то для системы необходимо оставить больше памяти.

4. Регулярное обслуживание SQL

• Настроить резервное копирование в соответствии с рекомендациями, см. http://msdn.microsoft.com/en-us/library/ms253070(v=vs.120).aspx. Использовать метки транзакций, бэкап трансакционного лога, SSRS encryption key (ключи шифрования), SQL backup compression (сжатие) и WITH CHECKSUM.
• Запускать DBCC CHECKDB (http://blogs.msdn.com/b/cindygross/archive/2010/06/13/dbcc-checkdb-database-integrity.aspx) регулярно для обнаружения физических/логических сбоев в базе данных. См. http://www.sqlskills.com/blogs/paul/how-to-tell-if-the-io-subsystem-is-causing-corruptions/. Также, используйте инструмент http://ola.hallengren.com/sql-server-integrity-check.html
• Проверить, что в базе данных значение конфигурационного параметра PAGE_VERIFY равно CHECKSUM для предотвращения разрушения базы данных. Если вам пришлось поменять параметр, необходимо перестроить индексы после настройки, чтобы получить набор контрольных сумм.
• Управлять свободным местом и расширением файлов баз данных data/log.
• Мониторинг для TempDB (<75% доступно)
• Мониторинг длительных транзакций (>60 минут, за исключением заданий перестраивания индексов)
• Мониторинг размеров таблиц и количества строк (http://blogs.msdn.com/b/granth/archive/2011/02/12/tfs2010-test-attachment-cleaner-and-why-you-should-be-using-it.aspx)
• Мониторинг SQL ErrorLog для отслеживания errors и warnings.

5. Настройка TFS

• Иметь не меньше 2 App-tier (серверов приложений) в NLB. Это позволит вам использовать 2 job-агента для запуска фоновых заданий TFS, выполнять больше запросов/сек. Убедитесь, что NLB имеет TCP Idle timeout в 60 минут и все ваши клиенты используют последнюю версию. См. http://blogs.msdn.com/b/granth/archive/2013/02/13/tfs-load-balancers-idle-timeout-settings-and-tcp-keep-alives.aspx
• Включите SQL Page Compression для таблиц кроме tbl_Content. Для включения используйте действия, обратные KB2712111.
• Убедитесь, что включено секционирование таблиц для Version Control. Не рекомендуется, если у вас >1 млн. строк в tbl_LocalVersion. Обратитесь в службу поддержки MS т.к. это недокументированная возможность только для самых больших TFS instances (например, для DevDiv).
• Проверьте, что SOAP gzip compression включена (http://blogs.msdn.com/b/granth/archive/2010/05/09/tfs2010-how-to-enable-compression-for-soap-traffic.aspx)
• Отключить log-файлы IIS, чтобы они не заполнили диск: %windir%\system32\inetsrv\appcmd set config -section:system.webServer/httpLogging /dontLog:"True"  /commit:apphost
• Изменить TFS App Pool Idle Timeouts с 20 до 0 минут (нет тайм-аута) и отключить scheduled recycling чтобы не было остановок в рабочие часы. 
• Запустить TFS Proxy Server и убедиться, что сотрудники используют его (особенно build-сервер). Даже если не будет удалённых пользователей, это всеравно увеличит количество обрабатываемых запросов (request/sec) на App-tier. Сконфигурируйте его как прокси-сервер по умолчанию для сайта: tf proxy /add
• При необходимости включить work item tracking metadata filtering.
• Проверить корректность работы SMTP (SMTP settings). Наиболее распространённой проблемой здесь является ..
• Установите NotificationJobLogLevel = 2 (http://blogs.msdn.com/b/granth/archive/2009/10/28/tfs2010-diagnosing-email-and-soap-subscription-failures.aspx) чтобы получать подробное сообщение об ошибке (например, используя TFS Best Practice Analyzer из TFS Power Tools)
• Перенести кеш TFS на отдельный физический и/или логический диск. Как это сделать - http://msdn.microsoft.com/en-us/library/vstudio/ms400793.aspx. Во-первых, снизить нагрузку на систему ввода/вывода. Во-вторых, если вы восстановите базу данных на более ранний момент времени, вам необходимо будет очистить кеш TFS, иначе пользователям будет выдаваться неправильный контент. Если кеш TFS будет на отдельном диске, сделать это можно будет очень быстро. 

6. Регулярное обслуживание TFS

• Проводите регулярные проверки с помощью TFS Best Practice Analyzer из пакета TFS Power Tools. Это поможет вам выявить проблемы, которые присутствуют на вашем сервере TFS.
• Периодически просматривайте Activity Log и Job Monitoring в панели управления вашего сервера TFS - http://ServerName:8080/tfs/_oi/. В Activity Log вы можете просмотреть последние действия пользователей на сервере TFS. В Job Monitoring вы увидите успешно ли выполняются сервисные задания TFS-агента. 
• Установите Performance Report Pack для просмотра пользователей, которые больше всех нагружают TFS. Также, анализируйте таблицу TFS-коллекции - tbl_Command.
• Используйте Test Attachment Cleaner Tools (см. http://geekswithblogs.net/terje/archive/2011/11/15/guide-to-reduce-tfs-database-growth-using-the-test-attachment.aspx) для очистки таблицы tbl_Content.
• Очищайте неиспользуемые workspaces и shelvesets. Используйте Team Foundation Sidekicks. Команда: tf workspace /delete.
• Удаление полей, которые не используются (witadmin listfields /collection:http://tfs:8080/tfs/Collection /unused).
• Проверяйте здоровье куба и warehouse с помощью Admin Report pack.
• Проанализируйте поля со свойством reportingtype=’dimension’. Действительно ли они должны находится в кубе? Если нет, то поменяйте значение на 'detail' и при необходимости вызывайте их с помощью базы данных Tfs_Warehouse. 
• Проанализируйте запросы на использование полей. Возможно, необходимо проиндексировать некоторые поля (witadmin indexfield /index:on) для увеличения быстродействия.
• Проверьте tbl_EventSubscriptions на наличие невалидных получателей (email). Для удаления подписок используйте TFS Web Access "All Alerts" - http://yourserver:8080/tfs/YourCollection/YourProject/admin/_alerts

Первоисточник: http://blogs.msdn.com/b/granth/archive/2013/10/08/what-does-a-well-maintained-team-foundation-server-look-like.aspx

Тест дисковой подсистемы SQL-сервера с помощью SQLIO

Дисковую подсистему сервера с СУБД SQL Server рекомендуется тестировать с помощью утилиты SQLIO (http://www.microsoft.com/en-us/download/details.aspx?id=20163).

Тест процессора для SQL-сервера с помощью Geekbench

Для тестирования производительности процессора сервера с СУБД SQL Server рекомендуется использовать утилиту Geekbench (http://www.primatelabs.com/geekbench/).

Помимо количественных показателей различных тестов процессора утилита выдаёт общий балл производительности процессора.

В итоге, вы увидите следующую информацию..

Утилита также запускается и в консольном варианте.

TFS 2012: Права доступа уровня проекта

Разрешения уровня проекта применяются к пользователям и группам отдельного проекта. Чтобы настроить эти разрешения, выберите проект в Team Explorer, выберите меню Параметры, а затем выберите Безопасность, либо откройте Team Web Access в режиме администрирования, перейдите к уровню проекта, а затем выберите вкладку Безопасность. Данные разрешения также можно настроить с помощью служебной программы командной строки TFSSecurity.

• Создать запуск тестов (Create test runs)
Пользователи с данным разрешением могут добавлять и удалять результаты тестов, а также добавлять или изменять тестовые запуски для командного проекта.
TFSSecurity: PUBLISH_TEST_RESULTS
• Удалить проект (Delete team project)
Пользователи с данным разрешением могут удалять проект, для которого у них есть данное разрешение из Team Foundation Server.
TFSSecurity: DELETE
• Удалить запуск тестов (Delete test runs)
Пользователи, имеющие это разрешение, могут удалять запланированные тесты для данного командного проекта.
TFSSecurity: DELETE_TEST_RESULTS
• Редактировать информацию уровня проекта (Edit project-level information)
Пользователи с данным разрешением могут изменять разрешения на уровне проекта для пользователей и групп в Team Foundation Server.
TFSSecurity: GENERIC_WRITE
• Управление конфигурациями тестов (Manage test configurations)
Пользователи, имеющие это разрешение, могут создавать и удалять конфигурации тестов для данного командного проекта.
TFSSecurity: MANAGE_TEST_CONFIGURATIONS
• Управление тестовой средой (Manage test environments)
Пользователи, имеющие это разрешение, могут создавать и удалять тестовые среды для данного командного проекта.
TFSSecurity: MANAGE_TEST_ENVIRONMENTS
• Просмотр информации уровня проекта (View project-level information)
Пользователи с данным разрешением могут просматривать участников групп уровня проекта, а также разрешения данных пользователей проекта.
TFSSecurity: GENERIC_READ
• Просмотр запусков тестов (View test runs)
Обладающие этим разрешением пользователи могут просматривать планы тестирования в этом узле.
TFSSecurity: VIEW_TEST_RESULTS

Источник: http://msdn.microsoft.com/en-us/library/vstudio/ms252587.aspx#Project