May 16, 2011 at 10:29 am
Hello, firstly I want to say Hi for all forum members [] I have a seriuos problem that requires some good knowledge.
I have game server sofware (to run game server), game client and INCOMPLETE mssql database . The deal is that complete database is lost and now I have only incomplete one.
The problem is that my database have all tables, but most of the tables have no records/wrong columns in it. So I need some realy big help here. Does it's possible with what I have (server sofware and client) fully restore the database?
P.S I can fully edit the client, see how client is built.
Thanks.
May 16, 2011 at 10:32 am
If you don't have a valid backup of the production DB you're basically screwed.
Time to search for any sort of backups that run on that server and hope they have a valid backup somewhere.
May 16, 2011 at 10:37 am
hmm its impossible to do something to full those tables? dissambling the client or something?
May 16, 2011 at 10:47 am
If you erased the prod db with the wrong backup and you don't have a vaild backup you don't have any option other than reentering the data manually from other documents.
May 16, 2011 at 11:04 am
Hmm, but the server software should require all of those tables, so if I would dissamble the game server sofware I should get some info, with ollydbg for example.
May 16, 2011 at 11:55 am
Good luck with that. Reverse-engineering a DB is an incredibly hard thing to do. You may be able to get the table names from the front end, unlikely to get the data, might not even be able to get the table design (column names & types)
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
May 16, 2011 at 12:00 pm
I have all table names, just need to get table structure/records.
May 16, 2011 at 12:05 pm
You'll be able to make guesses on the table structures if, and only if, you have all dynamic TSQL. If they're calling stored procedures you will have absolutely no mechanism to replicate what is within that code. Also, if the dynamic TSQL in the code is NOT calling views. If there are views, your structures will reflect the view, not the underlying table. It's just not something you can really do with any degree of confidence that you'll have a valid structure in the end. The best you can come up with is a structure that maps what the app thinks it needs, not what the structure actually is.
----------------------------------------------------The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood... Theodore RooseveltThe Scary DBAAuthor of: SQL Server 2017 Query Performance Tuning, 5th Edition and SQL Server Execution Plans, 3rd EditionProduct Evangelist for Red Gate Software
May 16, 2011 at 12:16 pm
There's barely a snowball's chance in hell you'll be able to get data back by reverse-engineering the front end. Column names, maybe (depends how the app queried the DB). Column types, constraints and indexes no way.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
May 16, 2011 at 10:32 pm
I totally agree with gail. Now it is near impossible to re-generate your data. That is why we always stress on backups. Not only backups but restorable backups before you do any major/minor activity on your production.
Backing up database is the first step we must look at to do even the smallest or tinest of activities on the production database. It makes life easier for DBAs in situation like you are in.
Good Luck mate! i feel realy sorry for you.
Regards,
Sachin
May 17, 2011 at 3:23 am
ahh thats bad 🙁 SO reverse engineering wouldn't help too? Btw, yeah there is things called stored procedures in that db.
May 17, 2011 at 5:20 am
At this point you basically have to do what you got to do to get the site working... from there on out maybe someone can reenter some data, most likely you'll lose data, maybe even a lot of data.
then schedule backups and make sure they work.
May 17, 2011 at 5:24 am
buferis12 (5/17/2011)
ahh thats bad 🙁 SO reverse engineering wouldn't help too? Btw, yeah there is things called stored procedures in that db.
There you go. You can't possibly know what's going on inside stored procs just from looking at the paratmers passed or the results returned. Think of it like a function call, you just can't see what happens there unless you put some type of code profiler on it. Same thing here.
----------------------------------------------------The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood... Theodore RooseveltThe Scary DBAAuthor of: SQL Server 2017 Query Performance Tuning, 5th Edition and SQL Server Execution Plans, 3rd EditionProduct Evangelist for Red Gate Software
May 17, 2011 at 5:27 am
Grant Fritchey (5/17/2011)
buferis12 (5/17/2011)
ahh thats bad 🙁 SO reverse engineering wouldn't help too? Btw, yeah there is things called stored procedures in that db.There you go. You can't possibly know what's going on inside stored procs just from looking at the paratmers passed or the results returned. Think of it like a function call, you just can't see what happens there unless you put some type of code profiler on it. Same thing here.
Well you can always guess by seeing which columns are used by the dataset in the front end but that's really a guess and you better hope that the columns were not renamed in the proc!
So basically you're in quite a big mess. And that is why you should ALWAYS have a valid, tested backup.
May 17, 2011 at 11:07 am
Hmmm, dunno, maybe those stored procedures is correct :ermm:
btw I uploaded that backup http://www.mediafire.com/?jzefzg0s0c7mr1z
so you can see how its look like, maybe the situation isn't so complicated?
Viewing 15 posts - 1 through 15 (of 16 total)
You must be logged in to reply to this topic. Login to reply