in know this articel, we already verified it but that was not the problem. Yesterday i kept looking in the internet, i came across this microsoft articel http://support.microsoft.com/kb/2653893/en-us. My DB administrator checked the VLF´s of that DB at morning and he saw that the fragmentation was very high , about 400.000 VLF´s for the transaction log´s. He modified the transaction logs that there is a lower amount of VLF´s ( now 37 ). At the moment i am testing the restore if its working now. I will come back and inform you if this was the solution.
now we tried it many times and in one time we were successful to recover the database, but i tooks about 12 hours and it was the same behavior, at 99% the restore slows down from 64KB/s to 512 bytes. I attached the nsrsqlrc log.
1. the debug level 6 was activated temporary after it reached 99% to show whats going on , for the rest of the backup run level1 was activated. We also run it without debug and it´s the same issue.
2. The backup is stored on disklibrary
3. yes it using a storage node
3. about CPU/Memory i attached a screeshot
4. backup rate , i have to verify it when you want to know it exactly but it seems for me to be ok when i look at the group run time
In the log you sent I couldn't see any failure because I suppose you attached the output of when the restore worked, but having in mind the size of the DB I would say this could be a TCP/IP time out.
Where are the DB's stored on? I am talking about storage, as looks like there is a high disk activity, which is normal, but wandering if it could be related to the disk if it's not local disk.
I wanted to know about the backup rate, in case the network could be an issue here however I don't think the issue here is with the speed itself but with the random failures, correct?
In that case I would need the output of the log with a failure.
i attached the log of a failed run. The DB is stored on local disks. The throughput is ok till the state of 99% then it slows down we it comes to recover to the log files.
Wenn it´s interrupting i have two information messages in the eventlog:
Starting up database 'RatCube'.
The database 'RatCube' is marked RESTORING and is in a state that does not allow recovery to be run.
After that it killed the sessions but there is no message anywhere else .
Based on the information you shared so far this seems to be an issue with SQL itself, as in NW/NMM logs there is no activity for hours, in fact restore as such (data from NW server to client) is completed, NMM is just waiting for the "acknowledge" from SQL (VDI) to nsrsqlrc.exe
Let us know please the outcome of applying that fix.
sheuter
1 Rookie
•
9 Posts
0
December 19th, 2012 02:00
Hi Carlos,
in know this articel, we already verified it but that was not the problem. Yesterday i kept looking in the internet, i came across this microsoft articel http://support.microsoft.com/kb/2653893/en-us. My DB administrator checked the VLF´s of that DB at morning and he saw that the fragmentation was very high , about 400.000 VLF´s for the transaction log´s. He modified the transaction logs that there is a lower amount of VLF´s ( now 37
). At the moment i am testing the restore if its working now. I will come back and inform you if this was the solution.
CarlosRojas
1.7K Posts
0
December 17th, 2012 06:00
Hi Sven,
Could you please share the nsrsqlrc.raw rendered, as well as xbsa.messages file?
Have you found any error and/or warning in the Applications and System event logs?
Thank you.
Carlos.
CarlosRojas
1.7K Posts
0
December 18th, 2012 01:00
Hi Sven,
I can see that the operation itself takes about 6 hours to complete, however the process doesn't completes until 5 hours later.
Have you tried with no debug set? I can see debug level 6.
What kind of backup device is the backup stored into?
Is it using any storage node?
What is the CPU/Memory usage during the restore process?
What is the backup rate when backing up that SQL DB?
Is the size around 21GB?
Thank you.
Carlos.
sheuter
1 Rookie
•
9 Posts
0
December 18th, 2012 01:00
Hello Carlos,
now we tried it many times and in one time we were successful to recover the database, but i tooks about 12 hours and it was the same behavior, at 99% the restore slows down from 64KB/s to 512 bytes. I attached the nsrsqlrc log.
1 Attachment
nsrsqlrc.rar
sheuter
1 Rookie
•
9 Posts
0
December 18th, 2012 01:00
Hello Carlos,
about your questions,
1. the debug level 6 was activated temporary after it reached 99% to show whats going on , for the rest of the backup run level1 was activated. We also run it without debug and it´s the same issue.
2. The backup is stored on disklibrary
3. yes it using a storage node
3. about CPU/Memory i attached a screeshot
4. backup rate , i have to verify it when you want to know it exactly but it seems for me to be ok when i look at the group run time
5. The size is about 270 GB
1 Attachment
resource.jpg
CarlosRojas
1.7K Posts
0
December 18th, 2012 05:00
Hi Sven,
In the log you sent I couldn't see any failure because I suppose you attached the output of when the restore worked, but having in mind the size of the DB I would say this could be a TCP/IP time out.
Where are the DB's stored on? I am talking about storage, as looks like there is a high disk activity, which is normal, but wandering if it could be related to the disk if it's not local disk.
I wanted to know about the backup rate, in case the network could be an issue here however I don't think the issue here is with the speed itself but with the random failures, correct?
In that case I would need the output of the log with a failure.
Thank you.
Carlos.
sheuter
1 Rookie
•
9 Posts
0
December 18th, 2012 08:00
Hi Carlos,
i attached the log of a failed run. The DB is stored on local disks. The throughput is ok till the state of 99% then it slows down we it comes to recover to the log files.
Wenn it´s interrupting i have two information messages in the eventlog:
Starting up database 'RatCube'.
The database 'RatCube' is marked RESTORING and is in a state that does not allow recovery to be run.
After that it killed the sessions but there is no message anywhere else .
1 Attachment
nsrsqlrc_fail.zip
CarlosRojas
1.7K Posts
0
December 19th, 2012 02:00
Hi Sven,
I think this has to do with the status of the model/temp DB. Please see the link below:
http://blogs.msdn.com/b/karthick_pk/archive/2010/11/26/the-database-model-is-marked-restoring-and-is-in-a-state-that-does-not-allow-recovery-to-be-run.aspx
If you manually aborted the restore process you will fall into the issue described above, and still I don't see any failure in the log you attached
Thank you.
Carlos.
CarlosRojas
1.7K Posts
0
December 19th, 2012 07:00
Hi Sven,
Based on the information you shared so far this seems to be an issue with SQL itself, as in NW/NMM logs there is no activity for hours, in fact restore as such (data from NW server to client) is completed, NMM is just waiting for the "acknowledge" from SQL (VDI) to nsrsqlrc.exe
Let us know please the outcome of applying that fix.
Thank you,
Carlos.