Краткая предыстория:
техники случайно отрубили питание у сервера с базой. после чего наблюдается
00:00000:00001:2009/03/26 16:02:29.43 server Redo pass for database 'bill': 3793729 records done (95%); 196104 records left.
00:00000:00001:2009/03/26 16:02:36.52 server Error: 3474, Severity: 21, State: 1
00:00000:00001:2009/03/26 16:02:36.52 server During redo the page timestamp value is less than old timestamp from log. Page #=17540917, object id = 1045575732, page timestamp=0001 ed65f690. Log old timestamp=0001 f10d347b. Log record marker = (30869510, 2).

Хозяйство я принял недавно - бакапы до меня не делались (какой-то глюк с бакап-сервером, он был криво поставлен).
Опыта работы с сибейсом немного...

Хочу запустить базу хотя бы в режиме "Use not recovered".

нарыл следующее:

убрать статус Suspect

1> sp_configure "allow updates", 1
2> go

1> use master
2> go

1> begin transaction
2> go

1> update sysdatabases
2> set status = status & ~256
3> where name="bill"
4> go


The following status bits override the "database offline" status bit:
* Began upgrade
* Bypass recovery
* In load
* Not recovered
* Suspect
* Use not recovered


Подскажите, как запустить базу в режиме Use not recovered - какие это должны быть биты статуса. И вообще - рабочая ли это идея? Хотя бы на некоторое время... пока не подниму бакап сервер...

Сам нашел...

1> update sysdatabases
2> set status = -32768
3> where name="bill"
4> go

1> commit transaction
2> go

1> sp_configure "allow updates", 0
2> go

1> shutdown with nowait
2> go

И после старта базы
1> online database bill
2> go

И опять рестарт.

Тактические вопросы вроде решил - остались стратегические...

"рабочая ли это идея? Хотя бы на некоторое время... пока не подниму бакап сервер..."
как я понимаю - после любого выключения питания - снова пляски с бубном...

0rcyastcher,
в скрипте который стартует сервер поставь -T3453 и запусти сервер... должно помочь

То есть с этим параметром он не переводит базу в режим suspect после неудачной проверки, а работает с ней?
Учту на будущее :) Спасибо :)

Пока dbcc checkalloc (bill) работает уже 16 часов и до конца не дошел. Уже выдал ошибки:


...........
Msg 7949, Level 18, State 1:
Server 'MVTS2', Line 1:
The number of pages used and unused for object 1045575732 index 0 on allocation
page 7053568 do not match the counts in the OAM entry.
Msg 7940, Level 18, State 1:
Server 'MVTS2', Line 1:
The counts in the OAM are incorrect. This implies that there are entries
missing. Run tablealloc utility with the FIX option on the table with the
inaccurate OAM counts.
Data level: 0. 9322237 Data pages allocated and 1171855 Extents allocated.
Думаю после запустить:
dbcc tablealloc (trafficAccountDetail, fast, fix)

Как я понимаю - при первой же возможности надо будет создать новую базу из бакапа. Старая от глюков не излечится?

0rcyastcher,
если я не прав, морис поправит :) сервер после старта с этим флагом какое-то время поработает, по ходу жизни страницы лога будут замещаться, и та "битая" в том числе, так что спустя некоторое время сервер уже без флага можно стартовать...
в принципе несколько раз спасало после "ой я не тот сервер по питанию выключил"

какую-то ерунду выводит...

--------------------------------------------------------------
log only free kbytes = 753473932
это точно вранье...
нету столько места ни в базе ни на диске
раньше были цифры порядка
--------------------------------------------------------------
log only free kbytes = 2037526

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

1> select * from sysdatabases
2> go
name dbid suid status version logptr
crdate dumptrdate status2
audflags deftabaud defvwaud defpraud def_remote_type
def_remote_loc
status3 status4
------------------------------ ------ ----------- ------ ------- -----------
-------------------------- -------------------------- -------
----------- ----------- ----------- ----------- ---------------
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
----------- -----------
bill 4 1 -32768 1 30869626 May 1 2006 4:15PM Mar 26 2009 6:20PM -32768
0 0 0 0 NULL
NULL
0 0
master 1 1 0 1 3052
Apr 30 2006 2:17PM Apr 30 2006 2:46PM -32768
0 0 0 0 NULL
NULL
0 0
model 3 1 0 1 631
Apr 30 2006 2:17PM Apr 30 2006 2:46PM -32768
0 0 0 0 NULL
NULL
0 0
sybsystemdb 31513 1 0 1 619
Apr 30 2006 2:17PM Apr 30 2006 2:17PM -32768
0 0 0 0 NULL
NULL
0 0
sybsystemprocs 31514 1 8 1 39790
Apr 30 2006 2:17PM Mar 26 2009 10:35AM -32768
0 0 0 0 NULL
NULL
0 0
tempdb 2 1 12 1 261277
Mar 27 2009 1:03PM Mar 30 2009 9:17AM 0
0 0 0 0 NULL
NULL
0 0


после изменения статуса tempdb на -32768 и перегрузки базы вот что в логах...

00:00000:00001:2009/03/30 09:29:42.71 server Clearing temp db
00:00000:00001:2009/03/30 09:29:59.39 server Error: 3908, Severity: 16, State: 1
00:00000:00001:2009/03/30 09:29:59.39 server Attempt to BEGIN TRANSACTION in database 'tempdb' failed because database is in BYPASS RECOVERY mode.
00:00000:00001:2009/03/30 09:29:59.45 server Error: 1624, Severity: 18, State: 1
00:00000:00001:2009/03/30 09:29:59.45 server Warning: Errors occured while initializing thresholds on tempdb. Trying to continue the startup. Thresholds might not be active on tempdb.
00:00000:00001:2009/03/30 09:29:59.45 server Error: 3908, Severity: 16, State: 1
00:00000:00001:2009/03/30 09:29:59.45 server Attempt to BEGIN TRANSACTION in database 'tempdb' failed because database is in BYPASS RECOVERY mode.

и вот что в логах...

Фу . все. разобрался. пошли данные...