Обслуживание баз данных 1C Предприятие 8.x на сервере Microsoft SQL 2008 R2

Базовые операции по обслуживанию баз данных в SQL Server 2008 R2 можно производить как из консоли при помощи служебной программы sqlcmd и языка запросов T-SQL, так и с помощью графической утилиты SQL Server Managment Studio. Отличительной особенностью средства  SQL Server Managment Studio является, то что в нем можно использовать оба способа, причем во время выполнения основных операций, программа позволяет переключатся в режим просмотра кода T-SQL. Достаточно нажать кнопку Script в верхней части окна программы. Для вызова средства sqlcmd, достаточно набрать в командной строке sqlcmd. Для подключения к удаленному серверу или именованному экземпляру необходимо добавить ключ -s:

sqlcmd -s SQLSERVER\SQLINSTANCE

Полный перечень команд доступных в интерактивном режиме, можно получить если набрать:

sqlcmd -?

К основным операциям по обслуживанию баз данных можно отнести резервное копирование (Back up Database), восстановление (Restore Database), сжатие (Shirink Database), дефрагментацию. Рассмотрим каждую из них на примере.

1. Резервное копирование (Back up Database)

SQL-сервером поддерживается широкий перечень методов резервного копирования. Наиболее распространенными являются:

Полное резервное копирование (Full) - выполняет полное резервное копирование всех данных в базе и всех изменений, которые возникают во время выполнения резервного копирования, а так же всех транзакций не зафиксированных в журнале транзакций. Выполняется в случае когда база данных имеет небольшой размер и резервное копирование осуществляется в течении приемлемого времени. База данных подвергается незначительным изменениям или доступна только для чтения.

Разностные резервные копии (Differential)  - следует выполнять для минимизации времени, которое необходимо для восстановления часто изменяемой базы данных. Возможно только в том случае, когда создана полная резервная копия базы данных.

Резервные копии журнала транзакций (Transaction Log) — в них записываются все изменения базы данных. Выполняется только при наличии полной резервной копии базы, и полной модели восстановления. Имеет смысл выполнять при наличии часто изменяемых баз данных.

Для выполнения резервного копирования, в SQL Server Management Studio необходимо перейти на закладку Database, щелкнуться правой кнопкой на нужной базе и в контекстном меню Task выбрать Back Up. В появившемся окне выбрать метод резервного копирования (Backup type), в поле «Back up To» задать путь для хранения резервной копии или оставить по умолчанию. Нажать ок.

Та же операция на языке запросов T-SQL будет выглядеть следующим образом:

BACKUP DATABASE [newdb] TO  DISK = N'C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Backup\newdb_backup_2012_08_24_020051_6455000.bak'
WITH NOFORMAT, NOINIT, NAME = N'newdb-Full Database Backup', SKIP, NOREWIND, NOUNLOAD,  STATS = 10
GO

2. Восстановление. (Restore Database)

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

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

  • При помощи параметра RESTRICTED_USER. (Ограничить доступ пользователям) в дополнительных свойствах (Options) базы данных. Если пользователи могут подключатся к базе с правами dbo, то необходимо выставить параметр в SINGLE_USER. В T-SQL за аналогичное действие отвечает параметр WITH RESTRICTED_USER.
  • Если на сервере имеется только одна рабочая база данных, то лучше просто на время восстановления отключить сетевой доступ к SQL Server. Для этого можно, на время восстановления отключить протокол TCP/IP в контейнере SQL Server 2008 Network Configuration в SQL Server Configuration Manager

Может случиться так, что база данных повреждена настолько сильно, что изменить ее свойства не удается. Она при этом может находиться в состоянии suspect (подозрительное) или в автономном режиме offline (информацию о состоянии можно просмотреть, например, из контейнера Datаbases в Management Studio). Если база данных находится в автономном режиме, то запустить ее восстановление не удастся. В этой ситуации самый простой выход — отсоединить (detach) поврежденную базу данных и произвести восстановление с резервной копии так, как будто эта база данных отсутствует на сервере вообще. Отметим, что для того, чтобы отсоединить базу данных, помеченную как  suspect (подозрительная), ее необходимо вначале перевести в состояние emergency (экстренной необходимости):

ALTER DATABASE newdb SET emergency.

Существует три модели восстановления баз данных. Полная (Full), простая (Simple), c неполным протоколированием Bulk-Logged).

В полной модели восстановления, используются копии баз данных (*.bak) и все сведения журналов. (*.ldf)  Сервером SQL Server заносятся в журнал все изменения базы данных, включая массовые операции и операции создания индексов. Если сами журналы не повреждены, сервером могут быть восстановлены все данные за исключением транзакций, которые обрабатывались на момент сбоя. Поскольку все транзакции записаны в журнал, восстановление может быть выполнено до любого момента времени. Главное ограничение этой модели — большой размер файлов журналов и итоговые затраты памяти и процессорного времени. Полное восстановление имеет смысл, только если:

  • База данных имеет небольшой размер. Резервное копирование выполняется в течении приемлемого времени.
  • База данных подвергается незначительным изменениям или доступна только для чтения.

Простая модель восстановления (simple) используется для малых баз данных или баз данных, в которых данные изменяются редко. Копии журналов не предусмотрены. В этой модели восстановления используются полные или разностные копии баз данных, и восстановление ограничивается восстановлением базы данных до момента, когда была создана последняя резервная копия. Все изменения, сделанные после создания резервной копии, утрачиваются. Основное преимущество этой модели, что для хранения журналов (*.ldf) требуется меньше места.

В модели восстановления с неполным протоколированием (Bulk-Logged) для восстановления базы данных используются резервные копии как базы данных так и журнала. Это дополнение к полной модели восстановления, позволяющее выполнять высокопроизводительные операции массового копирования. Основное преимущество — уменьшает место занимаемое журналами, за счет протоколирования большинства массовых операций. Возможно восстановление до конца любой резервной копии. Восстановление до заданной точки не поддерживается.

Представим, что произошел сбой и база данных newdb повредилась и соответственно возникла необходимость в ее восстановлении. Для этого в  SQL Server Managment Studio в контейнере Databases выбираем базу newdb, затем Tasks — Restore — Database.

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

Параметр 'To a point in time' (К моменту времени) задает момент времени на который требуется восстановить базу, по умолчанию: самый последний. Обычно используется только в ситуации, когда пользователь совершил ошибку (например, удалил важные данные) и вы знаете примерно, когда это произошло. Используется только при восстановлении журналов транзакций.

From Database — задает из резервной копии какой базы производить восстановление, по умолчанию предлагает то, что находится в  .\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Backup. В списке можно выбрать не только текущую базу данных, но и другие базы данных, которые есть на этом сервере;

From Device - предлагает выбрать резервную копию расположенную на другом диске или устройстве. Эта возможность используется в тех ситуациях, когда нужно восстановить базу данных на другой сервер или местонахождение резервной копии изменилось.

Соглашаемся с параметрами выбранными по умолчанию, нажимаем ОК, и получаем ошибку:

Restore Failed fo Server 'server'. (Microsoft.SqlServer.SmoExtended) System.Data.SqlClient.SqlError:  The tail of the log for the database «newdb» has not been backed up. Use BACKUP LOG WITH NORECOVERY to backup the log if it contains work you do not want to lose. Use the WITH REPLACE or WITH STOPAT clause of the RESTORE statement to just overwrite the contents of the log.

'Заключительный фрагмент журнала базы данных «newdb» не был добавлен в резервную копию. Если журнал содержит данные, которые нужно сохранить, используйте для его резервного копирования BACKUP LOG WITH NORECOVERY. Используйте предложение WITH REPLACE или WITH STOPAT инструкции RESTORE для замены содержимого журнала.'

Похоже срабатывает, проверка безопасности, запрещающая производить восстановление базы данных, если на ней осталась часть журнала транзакций  (tail-log), резервное копирование которой еще не производилось. Данная проверка срабатывает, только в случае полной модели восстановления и модели восстановления с неполным протоколированием.  Поэтому, что бы восстановить такую базу данных необходимо перейти в раздел опций и добавить параметр Overwrite the existing database (WITH REPLACE), который отключает проверку безопасности. Либо во время резервного копирования базы, делать так же резервную копию журнала транзакций и производить восстановление в месте с журналом.

Еще, при восстановлении существуют проверка не допускающая случайной перезаписи базы данных другой базой данных, т.е. если данная база, которую нужно восстановить уже существует на сервере, а имя базы данных или набор файлов для заданной базы данных отличается от  имени или набора файлов записанного в резервном наборе данных, то ее восстановление так же не будет выполнено. Так же запрещено перезаписывать файлы, которые относятся к базам данных, находящимся в автономном режиме (offline), и, кроме этого, вообще любые файлы, которые не относятся к SQL Server;

Следующий параметр Preserve the replication settings (WITH KEEP_REPLICATION) (Сохранить настройки репликации при восстановлении) - используется только тогда, когда база данных одновременно участвует и в репликации, и в автоматической доставке журналов (log shipping).

Prompt before restoring each backup (Выводить приглашение перед каждым восстановлением) — выводить приглашение перед восстановлением каждой следующей резервной копии из выбранного вами списка. Если используется стример.

Restrict access to the restored database (Ограничить доступ к восстанавливаемой базе данных) — после восстановления доступ будет открыт только членам роли базы данных db_owner и членам серверных ролей dbcreator и sysadmin. Этот параметр обычно применяется в тех случаях, когда после восстановления базы данных вам необходимо произвести дополнительные проверки или внести исправления.

Restore the database files as (Восстановить файлы базы данных как) — данный параметр, позволяет определить новый путь для восстанавливаемых файлов баз данных. Применяется, в тех ситуациях, когда производится восстановление базы данных на другой сервер, на котором конфигурация дисков выглядит по-другому.

Recovery state (Состояние восстановления) — этот параметр определяет, будет ли база данных открыта для пользователей после окончания восстановления с носителя. Возможны три варианта:

1. WITH RECOVERY — восстановление в обычном режиме. После окончания восстановления начнется процедура RECOVERY, все незавершенные транзакции будут отменены, и в итоге база данных будет открыта для пользователей. Этот параметр используется по умолчанию;

2. WITH NORECOVERY — после окончания процесса восстановления с носителя процедура RECOVERY не начнется. Базы данных останется в нерабочем состоянии восстановления. Этот параметр используется тогда, когда после восстановления резервной копии вы хотите восстановить дополнительные копии, например, после восстановления полной резервной копии восстановить резервную копию журнала транзакций;

3. WITH STANDBY — процедура RECOVERY начнется, но вся информация о всех отмененных незавершенных транзакциях будет записана в файл отмены (его нужно будет указать). В результате пользователи смогут обращаться к восстановленной базе данных для чтения (например, для создания отчетов), но в то же время сохраняется возможность применения следующих резервных копий журналов транзакций. Такое решение используется обычно только при применении автоматической доставки журналов на резервный сервер (log shipping).

На языке запросов восстановление базы данных выглядит следующим образом:

RESTORE DATABASE [newdb] FROM  DISK = N'C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Backup\newdb_backup_2012_08_24_020051_6455000.bak'
WITH  FILE = 2,  NOUNLOAD,  REPLACE,  STATS = 10
GO

3. Сжатие баз данных (Shirink Database) 

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

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

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

Для выполнения операции сжатия файлов данных и журналов транзакций в конкретной базе необходимо выполнение инструкции DBCC SHRINKDATABASE. Для сжатия отдельных файлов используется команда DBCC SHRINKFILE.

Для выполнения операции сжатия баз данных (Shirink Database) с помощью графического средства Managment Studio в контейнере Database щелкаемся правой кнопкой и в контекстном меню выбираем: Tasks — Shrink — Database.

В появившемся окне в поле Currently allocated space (Выделенное в данный момент место) указывается суммарный объем данных, которые использует база данных и лог транзакций.

В поле Available Free Space (Доступное свободное место) указывается объем данных который высвободится после операции сжатия.

Reorganize files before releaising unused space. (Реорганизовывать файлы перед освобождением неиспользованного места). Установка данного флажка эквивалентна выполнению инструкции DBCC SHRINKDATABASE с заданием целевого процентного параметра. Снятие данного флажка эквивалентно выполнению инструкции DBCC SHRINKDATABASE с параметром TRUNCATEONLY (освобождает для операционной системы все свободное пространство в конце файла, но не выполняет перемещение страниц внутри файла) По умолчанию при открытии диалогового окна этот флажок не установлен. Если этот флажок установлен, то необходимо задать целевое процентное значение в поле Maximum free space in files after shirinking (максимальное свободное пространство в %, которое должно остаться в базе данных после ее сжатия.)

Аналогичная операция на языке запросов T-SQL, будет выглядеть так:

USE [newdb]
GO
DBCC SHRINKDATABASE (N'newdb', TRUNCATEONLY)
GO

Иногда, может возникнуть ситуация, когда файлы журнала начали существенно увеличиваться в размере, порой превышая по объему саму базу данных в несколько раз. Происходит это, потому что, в свойствах базы данных выставлена полная модель восстановления (Full) или модель с неполным протоколированием (Bulk-Logged), которая по сравнению с простой моделью восстановления (Simple) не предполагает автоматическое очищение журнала транзакций. Поэтому, что избежать данной ситуации необходимо на ровне с полным резервным копированием регулярно выполнять резервное копирование журнала транзакций.

Для того что бы уменьшить размер файла журнала транзакций, необходимо сначала:

Выполнить его резервное копирование (*.trn), при этом убедившись что полная резервная копия самой базы (*.bak) так же присутствует.

Затем выполнить сжатие файла журнала транзакции при помощи вышеназванной операции либо при помощи команды  DBCC SHRINKFILE или соответствующей ей операции в графическом контексте Managment Studio:

В контейнере  Database щелкаемся правой кнопкой и в контекстном меню выбираем: Tasks — Shrink — Files. В появившемся окне в поле File Type выбираем Log. Нажимаем Ок.

При помощи команд T-SQL:

USE [newdb]
GO
DBCC SHRINKFILE (N'newdb_log' , 0, TRUNCATEONLY)
GO

4. Дефрагментация индексов.

Индексы — это определяемые пользователем структуры данных, позволяющие организовать быстрый доступ к данным без поиска по всей БД.

Существует два способа дефрагментации индекса: реорганизация и перестроение. Реорганизация (переиндексация) индекса  (Reorganize Index) дефрагментирует конечный уровень кластеризованных и некластеризованных индексов таблиц, физически изменяя порядок страниц конечного уровня для соответствия логическому порядку (слева направо) узлов конечного уровня. Упорядочивание страниц улучшает производительность просмотра индексов. Индекс реорганизуется внутри существующих страниц, выделенных для индекса, новые страницы не выделяются. Если индекс занимает несколько файлов, файлы реорганизовываются по одному. Страницы не перемещаются между файлами. Реорганизация индекса так же сжимает страницы индекса. Все пустые страницы, созданные этим сжатием удаляются, высвобождая дисковое пространство.

Перестроение (пересоздание) индекса (Rebuild Index) удаляет индекс и создает новый. При этом фрагментация исчезает, а дисковое пространство освобождается с помощью сжатия страниц, используя заданное или существующее значение коэффициента заполнения. Строки индекса упорядочиваются заново в смежных страницах (при необходимости выделяются новые страницы). Это может повысить быстродействие диска, уменьшая число чтений страниц, необходимое для получения запрошенных данных.

Решение о том, реорганизовывать или перестраивать индекс для устранения дефрагментации, должно основываться на существующем уровне фрагментации индекса сообщаемого средой SQL Server Managment Studio или процедурой sys.sm_db_index_physical_stats. Например:

SELECT OBJECT_NAME(object_id),avg_fragmentation_in_percent FROM sys.dm_db_index_physical_stats
(DB_ID(N'newdb'), NULL, NULL, NULL, NULL) where avg_fragmentation_in_percent<30

Если sys.sm_db_index_physical_stats <= 30% — реорганизация.

Если sys.sm_db_index_physical_stats  = 30% — перестроение.

Так же можно попробовать в работе скрипт который сам производит анализ фрагментации индексов и по результатам производит либо реорганизацию либо перестроение.

5. Создание планов обслуживания.

Большую часть административных задач можно автоматизировать при  помощи планов обслуживания (Maitenance Plans), которые позволяют планировать и выполнять по расписанию, различные операции по обслуживанию. В версии SQL 2008R2 доступны для выполнения следующие задания:

Check Database Integrity — Проверка целостности баз данных (Соответствует выполнению команды DBCC CHECKDB);

Shirink Database - Позволяет уменьшить размер базы данных, высвободив из ее файлов неиспользуемое пространство. Обычно такая задача применяется для баз данных промежуточного хранения с большим количеством временных объектов и данных;

Reorganize Index - задача для «мягкой» реорганизации индексов. При использовании этой задачи индексы реорганизуются, а не перестраиваются. Степень дефгментации получается несколько хуже, зато требуется меньше системных ресурсов, и таблицы на время реорганизации остаются доступными для пользователей;

Rebuild Index - полное перестроение индексов (обычно для целей дефрагментации). При настройке этой задачи необходимо выбрать таблицу или представление или указать все таблицы или представления в определенной базе данных;

Update strong Statistics - задача обновляет статистику оптимизатора запросов (Query Optimizer) для объектов в базах данных SQL Server 2008. Обычно такая задача используется для больших баз данных, в которых автоматическое обновление статистики отключено в целях оптимизации производительности.

Clean Up History - очистка истории резервного копирования, или истории выполнения заданий SQL Server Agent, или истории выполнения планов обслуживания. Цель проста — уменьшить размер базы данных msdb, удалив из нее ненужную информацию;

Execute  SQL Server Agent Job - задача, при помощи которой можно выполнить задание SQL Server Agent;

Back up Database Full — Полное резервное копирование баз данных. На выходе создаются файлы с расширением *.bak;

Back up Database Differential — Разностное копирование баз данных. Следует выполнять для минимизации времени, которое необходимо для восстановления часто изменяемых баз данных. Возможно только, в том случае, если создана полная резервная копия базы данных;

Back up Database (Transaction Log) — Резервное копирование журнала транзакций, на выходе создаются файлы с расширением *.trn. Рекомендуется выполнять перед полным резервным копированием баз данных, что позволит существенно сократить время восстановления на момент сбоя, а так же не позволит разрастись журналу транзакций в часто изменяемых базах данных. Как правило не используется в простой модели восстановления (Simple); 

Maintenance Clean Up Task —  эта задача позволяет удалить старые файлы. Обычно она используется для удаления старых файлов резервных копий, но ничего не мешает вам использовать ее и для удаления любых других файлов;

Лично мне в работе не приходилось сталкиваться с большими часто изменяемыми базами данных и поэтому всегда было достаточно в одном плане обслуживания держать максимум три, четыре задачи, которые выполняются в основном ночью, когда базы не используются. Обычно сначала, у меня, запускается тест целостности баз данных (Check Database Integrity), затем в  случае успеха  запускается либо реорганизация  (Reorganize Index) либо  перестроение индексов (Rebuild Index), затем, необязательный шаг, это резервное копирование журнала транзакций (Back up Database (Transaction Log)), и наконец полное резервное копирование самой базы (Back up Database Full). Рассмотрим на примере: Перейдем на вкладку Managment, далее Maitenance Plans — Maitenance  Plan Wizzard (Мастер обслуживания планов). Зададим имя плану обслуживания:

В поле Schedule (Планировщик), нажимаем Change, где задаем время выполнения задачи.

Нажимаем ОК, Next. Затем выберем те задачи которые будем использовать. На следующем экране кнопками Move Up, Move Down выберем очередность выполнения задач. Нажимаем Next.

Для каждого из заданий выбираем базы, которые хотим задействовать. Все другие настройки по умолчанию. На экране Select Report Options, выбираем режим оповещения о выполнении плана (в текстовый файл или по e-mail), жмем Next, и наконец Finish. В результате получим следующую картинку:

Здесь зеленые стрелки означают, что переход к следующему заданию возможен, только в случае успеха выполнения предыдущего (Success). Так же, возможны варианты «не успеха», провала задания (Failure) — задаются красными стрелками и вариант перехода к следующему заданию в любом случае (Completion) — задаются синими стрелками. Для переключения режимов, щелкаемся на стрелочке правой кнопкой и выбираем нужный. Вариант перехода в случае успеха (Success),  нам нужен только в самом начале, когда проверяется целость баз данных (Check Database Integrity). Соотвественно, если он не пройден, то все последующие задания будут не выполнены. Остальные связи выставим в режим Completion.

Итак, сначала выполняется проверка целостности баз данных (операция DBCC CHECKDB), затем в случае успеха производится полное перестроение индексов, затем выполняется резервное копирование журнала транзакции (необходимо наличие полных резервных копий файлов баз данных), размер которого существенно возрастает, после операции перестроения индексов, что позволяет, существенно сократить время восстановления базы в случае сбоя, и только потом полное резервное копирование. После выполнения всех заданий, чуть позже у меня в планировщике стартует простой батничек, который дополнительно пакует бекапы баз за текущую дату в отдельные zip-архивы, которые в последствии можно будет записать на двд-болванку и сдать нужным людям на хранение :)

SET SQLBackup="D:\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Backup\"
SET yyyy=%date:~6,4%
SET mm=%date:~3,2%
SET dd=%date:~0,2%
"%ProgramFiles%\7-Zip\7z.exe" a -tzip -mx7 H:\Backups\BUH8_backup_%date%.zip %SQLBackup%\BUH_8_backup_%yyyy%_%mm%_%dd%_*.bak"
"%ProgramFiles%\7-Zip\7z.exe" a -tzip -mx7 H:\Backups\UT8_backup_%date%.zip %SQLBackup%\UT_8_backup_%yyyy%_%mm%_%dd%_*.bak"

Если необходимо складывать бэкапы в сеть, то скрипт к примеру может выглядеть следующим образом:

net use z: \\server\Backups$ /user:Domain\BackupUser password
SET SQLBackup="D:\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Backup\"
SET yyyy=%date:~6,4%
SET mm=%date:~3,2%
SET dd=%date:~0,2%
"%ProgramFiles%\7-Zip\7z.exe" a -tzip -mx7 Z:\Backups\BUH8_backup_%date%.zip %SQLBackup%\BUH_8_Work_backup_%yyyy%_%mm%_%dd%_*.bak"
"%ProgramFiles%\7-Zip\7z.exe" a -tzip -mx7 Z:\Backups\UT8_backup_%date%.zip %SQLBackup%\UT_8_backup_%yyyy%_%mm%_%dd%_*.bak"
net use z: /delete

Для наилучшего сжатия, вместо zip, можно иcпользовать родной формат 7z, для этого убираем параметр -tzip и меняем расширение получаемых файлов на *.7z.

Оставить ответ

Войти с помощью: 

Вы можете использовать эти HTML тэги

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

  

  

  

*