МS SQL Server

Select DB_NAME(database_id)
file_id, 'Error case' = CASE event_type 
WHEN 1 THEN '823 or 824 or Torn Page'
WHEN 2 THEN 'Bad Checksum'
WHEN 3 THEN 'Torn Page'
WHEN 4 THEN 'Restored'
WHEN 5 THEN 'Repaired (DBCC)'
WHEN 7 THEN 'Deallocated (DBCC)'
END,
page_id,
error_count,
last_update_date,
PageType = Case
When page_id - 1 % 8088 = 0 Then 'Is PFS Page'
When page_id - 2 % 511232 = 0 Then 'Is GAM Page'
When page_id - 3 % 511232 = 0 Then 'Is SGAM Page'
When page_id BETWEEN 0 and 9 Then 'Is boot Page'
Else 'Is Not PFS, GAM, or SGAM page' 
End
From msdb..suspect_pages

Известная ошибка при попытке редактирования пакетов DTS:

описана здесь, но в статье две ссылки – Microsoft SQL Server 2008 Feature Pack page и Feature Pack for Microsoft SQL Server 2005 page.

Microsoft SQL Server 2005 Backward Compatibility Components доступен по обеим ссылкам, но версия только по второй будет работать с 2008R2 (несмотря на то, что дата релиза Feature Pack указана более ранняя).
Кроме того, здесь, в первом комментарии указаны правильные пути копирования *.dll и *.rll файлов.
В SSMS 2012 управление DTS пакетами больше не поддерживается.

При миграции БД с SQL Server 2000 на SQL Server 2005 выяснилось, что строка

RAISERROR ('test error %S', 16, 1, @test)

из-за неверно написанного %S вместо %s в SQL Server 2000 работает просто неверно (возвращает только первый символ параметра), а в SQL Server 2005 не создает процедуру совсем:
Msg 2787, Level 16, State 1, Line 6
Invalid format specification: ‘%S’.

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

SELECT name FROM sys.procedures WHERE CHARINDEX ( '%S', OBJECT_DEFINITION(object_id) COLLATE Latin1_General_CS_AS) >0

После исправления RAISERROR работает правильно.

На одном из серверов SQL Server 2005 при попытке открыть свойства БД через GUI видим:

Действительно, определить владельца БД не удается:

select owner_sid, suser_sname(owner_sid) from sys.databases where name='model'
owner_sid owner name
0x010500000000000515000000B92ACD62A473F62D825A8A49A3780000 NULL

Вероятно, это был доменный пользователь, которого больше нет в AD.
Изменить владельца процедурой sp_changedbowner в БД model нельзя:

use model; EXEC sp_changedbowner 'sa'

Msg 15109, Level 16, State 1, Line 1
Cannot change the owner of the master, model, tempdb or distribution database.

Можно поменять sid непосредственно в системной таблице, как описано здесь, но это, действительно, нерекомендуемый MS путь.

Так что воспользуемся тем, что при присоединении любой БД её владельцем становится текущий пользователь, и, запустив SQL Server с ключом /T3608, выполним из-под сессии пользователя sa:

EXEC master.dbo.sp_detach_db @dbname = N'model'
GO
CREATE DATABASE [model] ON
( FILENAME = N'E:\DATA\model.mdf' ),
( FILENAME = N'E:\DATA\modellog.ldf' )
FOR ATTACH
GO

Перезапустим SQL Server, убеждаемся:

select owner_sid, suser_sname(owner_sid) 'owner name' from sys.databases where name='model'
owner_sid owner name
0x01 sa

Если есть возможность, можно открыть порты для службы SQL Server Browser, перечисленные здесь.
Если нет, нужно создать алиас или просто подключаться, указывая порт в строке подключения:

где именованный инстанс INSTANCENAME работает по порту 1453.

Версия ОС: Windows Server 2008R2 EE x64
Версия SQL Server: SQL Server 2008R2 x64 SP1

Из-за неизвестной ошибки провайдера “Oracle provider for OLE DB” два раза подряд перезапустился сервис SQL Server, запись в логе приложений:

01:46:12 PM Information SERVERNAME.domain.a 1001 Windows Error Reporting N/A N/A Fault bucket , type 0 Event Name: APPCRASH Response: Not available Cab Id: 0 Problem signature: P1: sqlservr.exe P2: 2009.100.2500.0 P3: 4dfb6221 P4: StackHash_6d63 P5: 6.1.7601.17725 P6: 4ec4aa8e P7: c0000374 P8: 00000000000c40f2 P9: P10: Attached files: C:\Users\username\AppData\Local\Temp\WERC049.tmp.appcompat.txt C:\Users\username\AppData\Local\Temp\WERCB13.tmp.WERInternalMetadata.xml C:\Users\username\AppData\Local\Temp\WERDDCA.tmp.mdmp C:\Users\username\AppData\Local\Temp\WERE22E.tmp.WERDataCollectionFailure.txt These files may be available here: C:\ProgramData\Microsoft\Windows\WER\ReportQueue\AppCrash_sqlservr.exe_acc33c1fca791edc578ecac2be501126d4755535_cab_64a1e249 Analysis symbol: Rechecking for solution: 0 Report Id: 15cbe2fd-ae2a-11e1-a618-3c4a927b0a88 Report Status: 0
01:46:12 PM Error SERVERNAME.domain.a 19019 MSSQL$SQL1 Server N/A The MSSQL$SQL1 service terminated unexpectedly.

Причина перезагрузки SQL Server – это ошибка доступа (access violation AV) – повреждение кучи (heap corruption):

STACK_TEXT:
00000000`00000000 00000000`00000000 oraoledbutl10!Unknown+0x0
FAILURE_BUCKET_ID: ACTIONABLE_HEAP_CORRUPTION_heap_failure_block_not_busy_AFTER_CALL_c0000374_OraOLEDButl10.dll

Чтобы исключить подобное в будущем, убираем свойство “allow in process” провайдера Oracle, чтобы провайдер для линкованного сервера Oracle работал вне процесса SQL Server:

Далее, в соответствии с этой статьей, настраиваем доступ к MSDAINITIALIZE.

Теперь ошибка провайдера “Oracle provider for OLE DB” не повлечет за собой перезапуск службы SQL Server.

В SQL Server 2005 изменять расположение файлов ресурсной БД можно, что заявлено в msdn.
Посмотрим там же о SQL Server 2008 R2, читаем:
The resource database cannot be moved.

Все же полюбопытствуем, и попробуем сделать так же, как описано в msdn для SQL Server 2005:

C:\>NET START MSSQLSERVER /f /T3608

Проверим версию:

select @@version

Microsoft SQL Server 2008 R2 (SP2) – 10.50.4000.0 (X64) Jun 28 2012 08:36:30 Copyright (c) Microsoft Corporation Enterprise Edition (64-bit) on Windows NT 6.1(Build 7601: Service Pack 1) (Hypervisor)

Задаем новое расположение:

ALTER DATABASE mssqlsystemresource
 MODIFY FILE (NAME=data, FILENAME= 'C:\DATA\mssqlsystemresource.mdf');
 ALTER DATABASE mssqlsystemresource
 MODIFY FILE (NAME=log, FILENAME= 'C:\DATA\mssqlsystemresource.ldf');

The file “data” has been modified in the system catalog. The new path will be used the next time the database is started.
The file “log” has been modified in the system catalog. The new path will be used the next time the database is started.

Перемещаем  файлы БД mssqlsystemresource:

C:\>move "C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Binn\mssqlsystemresource.*" C:\DATA\

C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Binn\mssqlsystemresource.ldf
C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Binn\mssqlsystemresource.mdf
2 file(s) moved.

И перезапускаем SQL Server – всё работает.

Версия:
Microsoft SQL Server 2008 R2 (RTM) – 10.50.1600.1 (X64) Apr 2 2010 15:48:46 Copyright (c) Microsoft Corporation Enterprise Edition (64-bit) on Windows NT 6.1 (Build 7601: Service Pack 1)

Проблема:
В таблице IndexTable есть полнотекстовый индекс, около 3 миллиардов строк.
При старте актуализации (populate) получаем очень много таких ошибок в FT-логе:

2012-07-17 18:34:26.04 spid25s Error ‘0x80043630: The filter daemon process MSFTEFD timed out for an unknown reason. This may indicate a bug in a filter, wordbreaker, or protocol handler.’ occurred during full-text index population for table or indexed view ‘[TS_MageDB].[dbo].[IndexTable]’ (table or indexed view ID ‘667201477’, database ID ‘7’), full-text key value ‘1986286701’. Attempt will be made to reindex it.

Продолжается это 9 дней, загрузка процессора и диска не превышает ежедневную, процесс не заканчивается.

Ничего особенно полезного здесь (в моем случае 2008 R2, а не 2008) и здесь не нашел (Только “We have therefore resolve this issue as by design”)

Решение:
Помогло только пересоздание индекса, с последующим заполнением:

DROP FULLTEXT INDEX ON [dbo].[IndexTable]
CREATE FULLTEXT INDEX ON [dbo].[IndexTable]( [IndexValue] LANGUAGE [Russian])
KEY INDEX [PK_IndexTable] ON ([FT_IndexTeble], FILEGROUP [ftfg_FT_IndexTeble])
WITH (CHANGE_TRACKING = OFF, STOPLIST = SYSTEM)

или, если мы хотим запускать заполнение позже, например, ночью, то:

...CHANGE_TRACKING = OFF, NO POPULATION...

и стартуем:

ALTER FULLTEXT INDEX ON [dbo].[IndexTable] START FULL POPULATION

Процесс длился около 12 часов, ошибок больше не было.

dbcc sqlperf('logspace')

Database Name Log Size (MB) Log Space Used (%)
tempdb 23058,62 48,53052

Тем не менее:

March 2024
M T W T F S S
« Jul    
 123
45678910
11121314151617
18192021222324
25262728293031