 |
|
|
 |
|
|
hi, i have read that keeping the log file in a separate drive will speedup the query, please tell me how you see this? and i have used the following steps to move my log file
1. Execute the below query "ALTER DATABASE dbname modify file (name = logical log filename, filename = 'new path with filename')" 2. Stop SQL Services 3. Move the log file from old path to new path 4. Start SQL services Will this make the database Suspect? any issue with this?
My small attempt...
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
Great post.... save my day...!!!
Never argue with an idiot. They drag you down to their level, then beat you with experience. - Dilbert
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
 |
|
|
This fixed my problem in a few minutes. Awesome! Note: this was a development database. I don't know what I would do in production - I'm not a DBA.
Enoc Pardue - Software Architect PhoneTree Product Development Personal Communication Systems, Inc. www.phonetree.com Disclaimer: my opinions are my own and should not be construed to be representative of those of PCS, Inc. or its prinicipals.
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
Hi Friend,
I have implemented the same with production Database, and believe me, it is still working file. Still, if you have any doubt then copy the mdf and ldf file and try.
Thanks and let me know the result
Suvendu
Suvendu Banik, A.M.I.E. Electronics & Telecommunication Engineer
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
 |
|
|
Hello,
havent hit the situation..but not to panic in the moment..! I am looking for a way out to recover if SQL server 2000 database is in suspect mode.
Please post successful cases.
Thanks
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
Hi,
I was posted this article, after faced the same situation for the first time in my life. I have spent most of my valuable time behind this problem and successfully restored a live database.
Thanks and regards Suvendu
Suvendu Banik, A.M.I.E. Electronics & Telecommunication Engineer
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
 |
|
|
Hi,
I am really happy, that my article helps some one.
Thanks again for reading this article
Suvendu
Suvendu Banik, A.M.I.E. Electronics & Telecommunication Engineer
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
First question in my mind is Why database is in suspect mode? What was the cause for this? After that we can discuss the solution. If the reason is corruption you can not recover without loosing dates. On the other hand if your log file can not grow you can end in suspect mode but it is easy to fix: increase the size of log file and you don't loose dates. I think your solution it is the one of the last things that we must do in a particular situation, but I don't understand what is this situation.
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
 |
|
|
 |
|
|
Thanks for your feedback, actually I have tried with two of my existing live system and found no data loss. Obviously there is two more option available.
run REPAIR_ALLOW_DATA_LOSS to ensure the database is returned to a structurally and transitionally consistent state.
Here are a few things to bear in mind about emergency mode repair:
it's a one-way operation. Anything it does cannot be rolled back or undone. If this worries you (if someone ever got into that state then surely they don't have the healthy concern about data that should have in the first place) then make a copy of the damaged database before you run emergency mode repair. as its a one-way operation, you cannot wrap it in an explicit user-transaction. it's the only repair option available in emergency mode - if you try to use REPAIR_REBUILD then it won't work.
Thanks again
Suvendu Banik, A.M.I.E. Electronics & Telecommunication Engineer
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
Suvendu Banik wrote: actually I have tried with two of my existing live system and found no data loss
But the data loss can appear and everyone using this option has to be aware of this, so it should be mentioned. Somebody can learn about this option from article and use it on some other occasion, less severe than troubleshooting a database in suspect mode.
Suvendu Banik wrote: Here are a few things to bear in mind about emergency mode repair:
I suggest you add these remarks to the article.
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
Hi Chopeen, Thanks again for your suggesstion, I have added that comments to the article too.
Suvendu Banik, A.M.I.E. Electronics & Telecommunication Engineer
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
running DBCC without the allow_data_loss parameter will report back where the problem is. hence, a user should pay attention if problems where reported in user tables, rather than indecis and system tables and other scriptable objects. as in later cases, allowing data_loss is mostly sustained.
|
| Sign In·View Thread·PermaLink | 1.67/5 (2 votes) |
|
|
|
 |
|
|
Hi All, I am not able to bring analytics db in normal mode from emergency mode. It was in suspect mode earlier before I followed the steps given here. Please suggest how to get it back to normal mode? replication was failing because analytics db was in suspect mode and was not accessible. but, replication will still fail as long as this will be in emegency mode because no write operations can be done on this. Shall I hope that once out of emergency mode, it will become normal,and not suspect? if yes, how? using sql server2005.will appreciate your quick reply. 
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |