February 18, 2010 at 3:35 pm
GT-897544 (2/18/2010)
GilaMonster (2/18/2010)
GT-897544 (2/18/2010)
If that is the status values for suspect databases. Looks like it is a clean shut down, no corrupt files.It's not.
Cleanly shutdown is indicated by value 1073741824 in the status column. OP's status column is 65536.
Are you talking about Status 2 Column?
No. I'm talking about the status column. If you check Books Online, you'll see that toggled bits for the value 1073741824 in the status column indicate 'Cleanly shutdown'. 65536 isn't a documented value, from from what I can tell, it means Online (which is odd in this case). I could be wrong though.
See - http://msdn.microsoft.com/en-us/library/aa260406%28SQL.80%29.aspx
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
February 18, 2010 at 3:46 pm
GilaMonster (2/18/2010)
GT-897544 (2/18/2010)
GilaMonster (2/18/2010)
GT-897544 (2/18/2010)
If that is the status values for suspect databases. Looks like it is a clean shut down, no corrupt files.It's not.
Cleanly shutdown is indicated by value 1073741824 in the status column. OP's status column is 65536.
Are you talking about Status 2 Column?
No. I'm talking about the status column. If you check Books Online, you'll see that toggled bits for the value 1073741824 in the status column indicate 'Cleanly shutdown'. 65536 isn't a documented value, from from what I can tell, it means Online (which is odd in this case). I could be wrong though.
See - http://msdn.microsoft.com/en-us/library/aa260406%28SQL.80%29.aspx
Curious, but have you pinged Paul Randal regarding this one?
February 18, 2010 at 3:53 pm
GilaMonster (2/18/2010)
GT-897544 (2/18/2010)
GilaMonster (2/18/2010)
GT-897544 (2/18/2010)
If that is the status values for suspect databases. Looks like it is a clean shut down, no corrupt files.It's not.
Cleanly shutdown is indicated by value 1073741824 in the status column. OP's status column is 65536.
Are you talking about Status 2 Column?
No. I'm talking about the status column. If you check Books Online, you'll see that toggled bits for the value 1073741824 in the status column indicate 'Cleanly shutdown'. 65536 isn't a documented value, from from what I can tell, it means Online (which is odd in this case). I could be wrong though.
See - http://msdn.microsoft.com/en-us/library/aa260406%28SQL.80%29.aspx
The only reference I can find for this status is related to the status 2 field. Nothing for this value is documented in the status field.
65536 = concat null yields null
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
February 18, 2010 at 4:02 pm
Sorry for replying so late, Thanks everyone for your suggestions.
Step 1: I had restored these databases to another server from backups, and kept business going. I has good full backup and t- logs backups, fortunately I had t log backup just few mins before this happened. I run t logs backups every 15 for these databases.
Step 2: Checked error logs and I did see an error "Device activation error. The physical file name 'L: \data\Framework_log.ldf' may be incorrect."
Step 3: Server Team told us yesterday they had changed disk drives from sata to iscsi, unfortunately it was not communicated properly across IT.
Step 3: I had already kept databases up and running, I tried to bring one database offline then bought online it worked. Later i did same for each database and all are up and running now, now the databases are up and running. However I need to move databases from other server during maintenance window. Recycle SQL services or Reboot might have fixed the issue, The only reason i did not chose to Recycle\Reboot because of other databases on this server.
Thanks again,
February 18, 2010 at 4:10 pm
dennisengel (2/18/2010)
Sorry for replying so late, Thanks everyone for your suggestions.Step 1: I had restored these databases to another server from backups, and kept business going. I has good full backup and t- logs backups, fortunately I had t log backup just few mins before this happened. I run t logs backups every 15 for these databases.
Step 2: Checked error logs and I did see an error "Device activation error. The physical file name 'L: \data\Framework_log.ldf' may be incorrect."
Step 3: Server Team told us yesterday they had changed disk drives from sata to iscsi, unfortunately it was not communicated properly across IT.
Step 3: I had already kept databases up and running, I tried to bring one database offline then bought online it worked. Later i did same for each database and all are up and running now, now the databases are up and running. However I need to move databases from other server during maintenance window. Recycle SQL services or Reboot might have fixed the issue, The only reason i did not chose to Recycle\Reboot because of other databases on this server.
Thanks again,
Well, thanks for updating us.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
February 18, 2010 at 4:15 pm
Glad to hear that you had good backups and could get the databases up and running on another server.
February 18, 2010 at 4:18 pm
GilaMonster (2/18/2010)
GT-897544 (2/18/2010)
GilaMonster (2/18/2010)
GT-897544 (2/18/2010)
If that is the status values for suspect databases. Looks like it is a clean shut down, no corrupt files.It's not.
Cleanly shutdown is indicated by value 1073741824 in the status column. OP's status column is 65536.
Are you talking about Status 2 Column?
No. I'm talking about the status column. If you check Books Online, you'll see that toggled bits for the value 1073741824 in the status column indicate 'Cleanly shutdown'. 65536 isn't a documented value, from from what I can tell, it means Online (which is odd in this case). I could be wrong though.
See - http://msdn.microsoft.com/en-us/library/aa260406%28SQL.80%29.aspx
May be Status value remained as online because, no files were corrupt. Though I don't have document to support.
EnjoY!
February 18, 2010 at 4:20 pm
And i also feel i should keep away from this Blog, as when ever i replied to question looks like other DBA's are not happy.
Time to hit the road!
EnjoY!
February 18, 2010 at 6:48 pm
GT-897544 (2/18/2010)
And i also feel i should keep away from this Blog, as when ever i replied to question looks like other DBA's are not happy.
I wouldn't take too much notice of that.
February 19, 2010 at 1:17 am
dennisengel (2/18/2010)
Step 1: I had restored these databases to another server from backups, and kept business going. I has good full backup and t- logs backups, fortunately I had t log backup just few mins before this happened. I run t logs backups every 15 for these databases.Step 2: Checked error logs and I did see an error "Device activation error. The physical file name 'L: \data\Framework_log.ldf' may be incorrect."
Step 3: Server Team told us yesterday they had changed disk drives from sata to iscsi, unfortunately it was not communicated properly across IT.
Nice.
Step 3: I had already kept databases up and running, I tried to bring one database offline then bought online it worked. Later i did same for each database and all are up and running now, now the databases are up and running. However I need to move databases from other server during maintenance window. Recycle SQL services or Reboot might have fixed the issue, The only reason i did not chose to Recycle\Reboot because of other databases on this server.
So all is well, all happy, up and running again?
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
February 19, 2010 at 6:14 am
GT-897544 (2/18/2010)
And i also feel i should keep away from this Blog, as when ever i replied to question looks like other DBA's are not happy.Time to hit the road!
EnjoY!
It isn't we aren't happy with your trying to help, it has just been more of how you've tried to help. When dealing with problems like this one the first thing to do is not to start fixing things but to determine what went wrong so that the correct course of action can be determined. It really is problem solving 101. I learned this many years ago in the Air Force as a computer operator, and what I learned there grew as my carreer grew in different directions, but the basics still remained the same; determine the root cause before taking action.
Obviously, now, the OP was able to restore from good backups to another server and get the databases up and available. Obviously a good first step in this prior to figuring out what was wrong with databases. It gave him time to work the problem.
Also obvious now, a lack of communication between groups occurred when changes were made. This is the real world and things like that can happen. Hopefully, there will be some changes where the OP works that will reduce the chance of that type of mistake occuring again.
Viewing 11 posts - 46 through 56 (of 56 total)
You must be logged in to reply to this topic. Login to reply