Symantec BackupExec 11D - Database In Use

i take it you are using sql agent to backup the sql db?  i am posting some links

http://seer.support.veritas.com/docs/275277.htm

https://forums.symantec.com/syment/board/message?board.id=115&message.id=8270

hi, there

if you got 2 min to test it out i would suggest to take out the license key and then try the jobs again.
That will basically bring BE11d back to trial version and under the trialversion all agents are available so then you know if this works you have a problem on the agent side missing licenses.

Cooledit

I detached the BEDB database after stopping the backupexec services, reatched it correctly with no double slashes then started the services.

I then checked the database file path and it has put double slashes back in!

Any ideas?

Ok, i have this same issue with one of my sql databases.  There is no fix that i am aware (at least last time i checked with Symantec).  So what i do is setup a backup job in enterprise manager and then use symantec to backup the database backups.  

I have the same issue with SQL 2005 and BE 11d rev.7170  I've upgraded the BE SQL agents, in my logs I do not have double backslashes, only server\dabasename  Here's the log:

V-79-57344-33938 -
An error occurred on a query to database DBname.
V-79-57344-33938 - Write on "DBname_00__4c315e2e_2575_4f31_acaa_766253fa7cd6_" failed: 995(The I/O operation has been aborted because of either a thread exit or an application request.)
The item server\DBname in use - skipped.

How can there NOT be a resolution.  Whats the point of the SQL agent if it don't work! Thanks Symantec!

i actually raised a ticket with Symantec and they could not fix the issues.

He said to me something about it NOT needing to be backed up anyway as it is done as part of its daily course.

hmm, i am not sure.

no, it is the same issue.

as i just said. There own support could not figure out why it kept putting in the extra slashes and then gave me the above response.

check in enterprise manager and see if a task is setup to backup the dbs.  

if so then just include the backup files in your backup

if not set a task to backup the db, then backup the backup

i'm refering to atkinson IT--regarding his errors

yes, i think its unacceptable. Symantec says it an issue with MS and they shouldn't have \\.  

I use the agent for other sql dbs and it works fine.  the db that i have a problem with isn't as important as the ones that work.  plus the most important db i backup, the vendor only supports backup exec so my hands are kind of tied.  

Capslockassasin found the solution to be a registry change on the Symantec Backup Exec server.  In the registry key HKLM\SOFTWARE\Symantec\Backup Exec For Windows\BEDatabase look for the values Server Database Path and Server Database Log Path.  If these values have trailing backslashes like so:

Server Database Path=E:\Microsoft SQL Server\MSSQL\Data\
Server Database Log Path=D:\Microsoft SQL Server\MSSQL\Data\

then remove them so that they appear like this instead:

Server Database Path=E:\Microsoft SQL Server\MSSQL\Data
Server Database Log Path=D:\Microsoft SQL Server\MSSQL\Data

You should now find that the documented solution from Symantec works properly.

I am not finding those values on the backup exec server under that key.

on the sql server i am trying to backup, i am not even finding that key (perhaps b/c it is sql 2000?)

i am using SQL 2000 Ent on W2k3Ent and the key change solved my problem, dunno why you cant find it...very strange. Did you search the registry?

I am having the same issue, way too many databases are skipped.  And just like opie6373 those registry keys do not exist on my Backup Exec Server.  I do agree with others here, the whole point of purchasing the SQL agent is to give you the ability to do hot backups or backup while the database is live.  If you have to resort to backing up databases from the SQL server to .bak files and then back those up as regular files, then the SQL agent is pretty much useless.  You can do the same thing without the SQL agent.  Also, if a work around is to do a pre and post exec scripts to bring the databases up or down, make the SQL Agent useless.  This SQL Agent is worthless, no wonder so many people shy away from it.  You're better off using the backup tools Microsoft provides with SQL to do hot backups and just have Backup Exec backup those backups.  We're at the point where we just want our $$ back.

Yeah, Symantec blames it on microsoft.  I'm just glad its not a mission critical database.