dotNETportal.cz

Zdravím všechny,

potřebovala bych obnovit databázi (zákazník je bordelář - potřeboval nahrát fotky a vymazal backupy - no comment).

Domnívám se, že se připojím jako 'sa' na 'master' a zkusím pustit uloženou proceduru sp_resetstatus, ale to je asi vše, co vím. Poradí mi někdo?!?

Předem dík.

(SQL EXPRESS 2005)

Mezitím ze mne vypadlo tohle, ale bojím se to pustit:

Dim strConn As String

strConn = "Server=xx.xx.xx.xx;DataBase=master;USER ID=sa;PASSWORD=xxxxx;Timeout=15;"

Dim cnData As New SqlConnection(strConn)

cnData.Open()

Dim aCommand As New SqlCommand("sp_resetstatus", cnData)

With aCommand

.CommandType = CommandType.StoredProcedure

.Parameters.Add(New SqlParameter("@DBname", "Dbs"))

End With

aCommand.ExecuteNonQuery()

Zaprvé absolutně nechápu čeho chcete docílit spuštěním procedury sp_resetstatus, zadruhé nechápu proč k takovým účelům nepoužijete Management Studio což by bylo asi 10x jednodušší...

Protože to vůbec neumím. Nikdy jsem SQL server na této úrovni nespravovala, umím pouze naistalovat SQL, vytvořit databázi, backup, restore, shrink, přidat uživatele a roli.

S touto chybou si nevím rady a potřebuji zachránit nabořená data. Pokud je v management studiu nějaká funkce, ráda ji použiji.

A co konkrétně znamená "nabořená data"? Pokud nemáte s databázemi žádné, nebo jen malé zkušenosti, raději bych se být vámi do opravy provozní databáze nepouštěl...

Dotyčná databáze je v Management studiu označena '!' a vedle jména má v závorce slovo Suspect. Potřebuji se na ni nějak dostat, abych zachránila čtrnáctidenní práci deseti operátorek (poslední backup mají z 19.4.)

Pane Linhart, děkuji Vám, že jste mi odpověděl. Ale já nejsem blb. Dnes už o sobě mohu říci, že jsem zkušená programátorka VB.NET, o databázích vím také dost, v IT pracuji pětadvacet let, z relačních databází jsem měla tu čest vidět i Oracle. Že jsem poprvé narazila na tento problém ještě neznamená, že mne musíte napadat.

Škoda, že nejste aspoň schopen ocenit, že kromě tohoto dotazu zde na fóru se snažím nějaké informace 'vygúglovat'.

Právě jsem našla tohle:

http://doc.ddart.net/mssql/sql70/8_tr_01...

Mirka

Já vás nenapadám, pouze reaguji na vaše příspěvky a na základě vámi poskytnutých informací (kterých mnoho není) vymyslet/doporučit nějaké řešení... V tuto chvíli vám mohu doporučit pouze to, abyste si zálohovala vše co je v datové složce dané instance SQL Serveru než s tím budete experimentovat. Tím zálohováním myslím zastavení služby SQL Serveru a ruční zkopírování všeho z té složky někam stranou (příklad té složky: C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data, kde MSSQL.1 je ta konkrétní instance SQL Serveru).

Jiné informace nemám. Databáze je ve stavu Suspect a já ji potřebuji z tohoto stavu nějak dostat. Dočetla jsem se, že to lze, ale jak, to jsem zatím nenašla. Ještě snad jednu informaci, na hardu mám víc jak polovinu gigabajtů volných, takže přeplněný disk není.

Tak jsem to vrátila ke staré kopii. Nicméně by mne to zajímalo.

Moc dík, bohužel už nemám kopii, takže to nemohu vyzkoušet. škoda, tento typ mi gúgl nenabídl. Můj problém byl dosti atypický, problémy s SQL serverem jsem nakonec musela vyřešit reinstalací celého počítadla.

I když je toto vlákno skoro 3 roky staré, tak díky tomuto tipu jsem dnes poléčil SQL databázi z módu suspect do provozuschopného stavu bez ztráty dat. Tímto i po tolika letech děkuji za záchranu. Jen pro představu ... používáme IS na MS SQL EXPRESS 2005 a z neznámého důvodu došlo při každonočním zálohování k nekorektnímu ukončení služby SQL serveru a následně aplikačního serveru, a již odkopírovaná záloha databáze byla "poškozená" ... Při této příležitosti jsem zjistil že log (.ldf) soubor už má skoro 2GB a že je od instalace zapnutné FULL logování, přitom by stačilo Simple. Každopádně ani v Management Studiu nebylo možné se k databázi připojit, s logem, bez logu, nijak .... po celodenním úsilí programátorů od tvůrce SW, jsem dostal verdikt, že MDF databáze je vevnitř tak rozsypaná, že ji nelze zachránit ... takže včerejší celodenní práce naší firmy ztracena ... Nehodlal jsem s tím smířit a googloval jsem a narazil na tento tip ... zkusil výše uvedenou sekvenci příkazů vložit do přikazového řádku Management Studia, aniž bych se jakkoliv "dotýkal" databáze v suspectu (nebylo možné na ní ve Studiu ani kliknout ... ihned chyba) ... a za pár vteřin databáze běžela. Tipnul bych to jen na nějakou ztrátu konzistence, ale rozhodně ne na zhroucení celé struktury, jak mi bylo od programátorů tvrzeno ... hold asi "jinej gang" :) ... už tam volat nebudu, akorát bych se vytočil a pokazil si radost ze zachráněných dat ... ješte jsem přepnul log na Simple a odstranil původní LDF aby se vytvořil nový soubor s malou velikostí ...

Já říkám porád,že zlatý Oracle :-))

Víte o tom, že Oracle se do takového stavu může také dostat?

Ve skutečnosti je tento stav tím nejlepší, co může databáze udělat, pokud má podezření, že došlo k neočekávané ztrátě dat, které nebylo možné obnovit z transakčního logu a mohlo by tak dojít k porušení transakčního chování.