Highlighted
connolly
2 Iron

DDBEA SQL - backups ran but SQL shows job failed

First off - not sure where I should post this, but I saw other DDBEA posts here, so here it is.

Second - hoping that I can get some perspective on this here but aware that I will more than likely have to log an SR to get it addressed.

OK, so here we go:

1) Customer is familiar with DDBEA and has backups running fine on other SQL instances in their environment.

2) Customer is "rolling out" DDBEA SQL backups in their SQL environment.

3) Customer had errors trying to run a SQL backup job using DDBEA on databases in the latest SQL instances they have configured.

4) Initial issues were due to the customer not having the "stored procedures" in SQL that DDBEA apparently expects to be there in order to run backups.

5) Customer "copied" the "stored procedures" from another instance in SQL.

6) After that, the customer tried to run SQL backups again via a SQL job with DDBEA, and the job failed - however, relative to later review of the DDBEA log, it appears that the SQL database targets were apparently backed up successfully.

7) After the failure of the SQL backup job, the customer tried to run a single SQL database job from the instance and got the following error in the SQL job log:

Unknown token received from SQL Server [SQLSTATE HY000] (Error 0)  String data, right truncation

8) The customer then tried to run the same SQL backup "manually", and the following error showed up in the window where he was monitoring the backup (which I believe displays the DDBEA SQL commands):

38008:ddbmsqlsv: An internal error occurred.


9) There is a similar 38008 error in the DDBEA SQL log for the earlier backup job that failed

10) The only thing I currently see different in the DDBEA SQL log between the backups that failed, and the one that succeeded (in spite of the SQL job showing as failed) is that the successful one shows the full path for the DDBEA SQL executable.

So, I'm wondering if there was some kind of issue created by the way the stored procedures were copied to this instance, or whether something else needed to happen after they were copied since they weren't there when DDBEA was first "associated" with that instance. FWIW, I did not observe the customer configuring DDBEA for their SQL environment, so I can't speak for what might have been done then.

Sorry for the extended detail, but this is a weird one, at least to me at this point in time. Hopefully someone can provide some perspective or detail that makes it a bit clearer, or at least gives some insight in terms of whether I should just log an SR for the issue.

Thanks.

0 Kudos