Activity overview
Latest activity by hhdoan
Found a solution using a secret registry item. Anyone wants to know, go ahead send me a few thousand $. / comments
Found a solution using a secret registry item. Anyone wants to know, go ahead send me a few thousand $.
I will submit the support case.
There is one thing unique about our host server. There are 3 IP addresses assigned to the 3 instances.
162.123.172.201 assigned to PDB1 listened on port 1433
162.123.172.202 assigned to PDB2 listened on port 1433
162.123.172.203 assigned to PDB3 listened on port 1433
I have a hunch that somewhere in RedGate/MS code, it used the assumption that the Winsock TCP call to be made on the first item of the address list. That should explain that the backup always work on the first instance PDB1, never worked on the rest of the IP addresses. As the matter of fact, I've seen code from experienced developers that used only the host name and port number for TCP call. That would be a disaster for this kind of setup.
I have the the stack call generated from the Process Monitor and WireShark to prove this. When I executed the backup process on PDB1, the TCP call was made once and only once. But when I ran the process on PDB2, it created an infinite loop of TCP call. / comments
I will submit the support case.
There is one thing unique about our host server. There are 3 IP addresses assigned to the 3 instances.
162.123.172.201 assigned to PDB1 listened on port 1433
162.123...
I'm not sure how to get the last stack trace.
I checked the services, all of them have correct parameter.
Instance PDB1: SQBCoreService.exe -I PDB1
Instance PDB2: SQBCoreService.exe -I PDB2
Instance PDB3: SQBCoreService.exe -I PDB3 / comments
I'm not sure how to get the last stack trace.
I checked the services, all of them have correct parameter.
Instance PDB1: SQBCoreService.exe -I PDB1
Instance PDB2: SQBCoreService.exe -I PDB2
Instanc...
I followed your instruction on instance PDB2.
Ran this T-SQL command:
EXECUTE master..sqlbackup '-SQL "BACKUP DATABASE [master] TO DISK = [N:\MSSQL\PDB2\Backup\<AUTO>.sqb]"'
The process hung as usual. This is the stack trace:
**deleted** / comments
I followed your instruction on instance PDB2.
Ran this T-SQL command:
EXECUTE master..sqlbackup '-SQL "BACKUP DATABASE [master] TO DISK = [N:\MSSQL\PDB2\Backup\<AUTO>.sqb]"'
The process hung as usu...
I installed version 6.5.1.9. Still experienced the same behavior.
I even tried the cmd line.
On instance PDB1, I ran this:
"C:\Program Files (x86)\Red Gate\SQL Backup 6\PDB1\SQLBackupC.exe" -I PDB1 -E -SQL "BACKUP DATABASES [master] TO DISK = 'N:\MSSQL\PDB1\Backup'"
It completed just fine.
On instance PDB2, I ran this:
"C:\Program Files (x86)\Red Gate\SQL Backup 6\PDB2\SQLBackupC.exe" -I PDB2 -E -SQL "BACKUP DATABASES [master] TO DISK = 'N:\MSSQL\PDB2\Backup'"
The process hung after this message: Red Gate SQL Backup 6.5.1.9, (c) Red Gate Software Ltd 2004 - 2011. Serial number: ***-***-*******-****
I also ran sqbutility 9997. You can review the log below:
**deleted** / comments
I installed version 6.5.1.9. Still experienced the same behavior.
I even tried the cmd line.
On instance PDB1, I ran this:
"C:\Program Files (x86)\Red Gate\SQL Backup 6\PDB1\SQLBackupC.exe" -I PDB1...
Wait indefinitely PREEMPTIVE_OS_GETPROCADDRESS
I have 3 SQL 2008 Enterprise Edition instances installed on a Windows Enterprise 2008 R2 box. Named instances: PDB1, PDB2, PDB3
I installed 3 instances of Red-Gate Backup 6.2.0.134. Then applied pa...