Is it possible that I change the data's type when I create the DSV in the Visual Studio 2005?

Hello everyone:

Recently, I was responsible for creating a analysis services project with the SQL Server Business Intelligence Development Studio in Visual studio 2005. I encountered a error that the data type is not supported when I tried to add the table from a remote Oracle server. I can not modify the data type in the oracle server. Is it possible that I change the data's type when I create the DSV in the Visual Studio 2005? (if I have known the table's name)

Help me Please! tell me the steps or some references if it is possible

Thanks

---

While I don't think you can change the data type of the column within the DSV, what you can do is add a named calculation to the table within the DSV and use a snippet of Oracle to cast the underlying column to whatever data type you want. The new named calculation would then inherit that data type.

For example (using SQL Server here, not Oracle), if I had a table with a column named ZIPCODE of type INT but I wanted to treat the column as VARCHAR within my SSAS solution, I could add a new named calculation to the table within the DSV (right-click on the table in the DSV and select New Named Calculation), call it something like ZIPCODE_STR and then use the T-SQL snippet CONVERT(VARCHAR(10), ZIPCODE). This new column then behaves like any other within the DSV and within the rest of my solution -- and has a datatype of System.String with a length of 10.

HTH,

Dave Fackler

|||

Thank you very much

Now I did not install SQL Server 2005 and VS on current computer, I will try it later. I think you suggest is very well. But I have a question: you said I could add a new name calculation to the table within the DSV. Does it equal that the table (at least one column's datatype doesn't not match the SSAS's rule) have been added into the DSV?

The problem I encounter is that I can not add that table to the DSV because of the unsuited the datatype for the column. Is there any other suggestion to me?

Thanks^_^

|||

Sorry, I missed the point that you can't add the table to the DSV because of the data type...

In that case, instead of adding a named calculation to the table (as you are correct in thinking that the table must be present within the DSV to do this), add a named query instead. Just right-click on the design surface of the DSV and select New Named Query.

This will bring up a dialog box that you can use to enter any PL/SQL select statement (given you are using Oracle) returning whatever columns (converted to whatever datatypes you need) from one or more tables. Very similar to creating a view in the Oracle database. Just give the named query a name and it will then appear as a table within the DSV. So, in your case, you'd likely want to select all the relevant columns that you need, converting the one with the unsupported datatype to another datatype (just be sure to alias the column once you convert it as a named query must return named columns so that the DSV can understand the metadata returned by the query).

HTH,

Dave Fackler

|||

I think this response is I need. Thank~ you very much.

I will try it later.

Thanks^_^

Winnie

Is it possible that I change the data's type when I create the DSV in the Visual Studio 200

Hello everyone:

Recently, I was responsible for creating a analysis services project with the SQL Server Business Intelligence Development Studio in Visual studio 2005. I encountered a error that the data type is not supported when I tried to add the table from a remote Oracle server. I can not modify the data type in the oracle server. Is it possible that I change the data's type when I create the DSV in the Visual Studio 2005? (if I have known the table's name)

Help me Please! tell me the steps or some references if it is possible

Thanks

---

While I don't think you can change the data type of the column within the DSV, what you can do is add a named calculation to the table within the DSV and use a snippet of Oracle to cast the underlying column to whatever data type you want. The new named calculation would then inherit that data type.

For example (using SQL Server here, not Oracle), if I had a table with a column named ZIPCODE of type INT but I wanted to treat the column as VARCHAR within my SSAS solution, I could add a new named calculation to the table within the DSV (right-click on the table in the DSV and select New Named Calculation), call it something like ZIPCODE_STR and then use the T-SQL snippet CONVERT(VARCHAR(10), ZIPCODE). This new column then behaves like any other within the DSV and within the rest of my solution -- and has a datatype of System.String with a length of 10.

HTH,

Dave Fackler

|||

Thank you very much

Now I did not install SQL Server 2005 and VS on current computer, I will try it later. I think you suggest is very well. But I have a question: you said I could add a new name calculation to the table within the DSV. Does it equal that the table (at least one column's datatype doesn't not match the SSAS's rule) have been added into the DSV?

The problem I encounter is that I can not add that table to the DSV because of the unsuited the datatype for the column. Is there any other suggestion to me?

Thanks^_^

|||

Sorry, I missed the point that you can't add the table to the DSV because of the data type...

In that case, instead of adding a named calculation to the table (as you are correct in thinking that the table must be present within the DSV to do this), add a named query instead. Just right-click on the design surface of the DSV and select New Named Query.

This will bring up a dialog box that you can use to enter any PL/SQL select statement (given you are using Oracle) returning whatever columns (converted to whatever datatypes you need) from one or more tables. Very similar to creating a view in the Oracle database. Just give the named query a name and it will then appear as a table within the DSV. So, in your case, you'd likely want to select all the relevant columns that you need, converting the one with the unsupported datatype to another datatype (just be sure to alias the column once you convert it as a named query must return named columns so that the DSV can understand the metadata returned by the query).

HTH,

Dave Fackler

|||

I think this response is I need. Thank~ you very much.

I will try it later.

Thanks^_^

Winnie

Is Installing SQL05dev and VS05pro on the same machine supported?

Hello,

When SQL05dev is installed a SQL05 version of Visual Studio (SQL05-VS) is also installed (called the “SQL Server Business Intelligence Development Studio”). The SQL05-VS installs files into a “C:\Program Files\Microsoft SQL Server\90\Tools\binn\VSShell\Common7\IDE” directory (and other directories - not described here).

When the full version VS05pro is installed it installs/uses files in a “C:\Program Files\Microsoft Visual Studio 8\Common7\IDE” directory.

The number of files in these two directories is different – the directory for VS05pro has (of course) many many more files than the directory for SQL05-VS. On the surface this seems ok since the install of VS05pro should supersede the install of the SQL05-VS and when VS05 is started it utilizes the files from the VS05pro directory and picks up the functions from the SQL05-VS (like SSIS, SSAS, SSRS and such).

But what about the SQL05-VS Common7/IDE directory? In this directory are 64 files that exist in both directores (556 files are not found in the VS05pro Common7/IDE directory). Additionally, there are 10 files that have different versions (mostly having to do with SQL-CE) – newer versions are in the SQL05-VS directory.

I’m confused. Is Microsoft going to support revision changes (Service Packs and such) to both directories? I suppose so, but this introduces possible versioning problems when SQL is updated but VS is not or VS is updated but SQL is not.

I guess I do not understand the rational for not maintaining a single VS directory structure and the problems that this creates. Microsoft is utilizing VS as the IDE for SQL but to not have a really good matching installation layout with the full version of VS is wacky – to say the least. Maybe M$ considers maintaing the versions of 64 files to be unimportant for the correct functioning of VS?

Is Installing SQL05dev and VS05pro on the same machine supported?

MikeC

Installing VS 2005 (and flavor) and SQL 2005 on the same machine is supported.

SQL installs what we call the Premier Partner Edition, which is just the basic IDE with no langauges. SQL then installs its own packages on top of the IDE.

The additional files are SQL specific. The Premier Partner Edition and any VS flavor will install to one location. If you install SQL first, when installing VS, VS will "lock" you to install to a specific directory and won't allow you to install anywhere you want.

That way, you only have one version of the file, its serviced in one place, and is properly ref counted.

|||

QuanT,

You said, "Installing VS 2005 (and flavor) and SQL 2005 on the same machine is supported.”

If this is the case, then I would like to see Microsoft fix the problems with SQL05 when VS and SQL05 are installed on the same machine – *but not to the C: volume*. That is - installing full VS05 (without SQL Express) and SQL05 to a non-C: volume on a freshly formatted/installed version of Windows 2003R2.

You said “If you install SQL first, when installing VS, VS will "lock" you to install to a specific directory and won't allow you to install anywhere you want."

It does not matter which you install first, installing VS to a non-C: volume after SQL is installed to a non-C: volume broke SSIS and the copy db wizard (I did not do any checking beyond these show-stoppers…)

Installing VS first (to a non-C: volume) allows the SQL install to install more components to a non-C: volume, but the problems still arise. Installing in this order should also be supported.

Installing VS to C: and SQL to E: works, but then RS has issues...

It appears that very little SQL05 installation testing was done to anything other than a C: volume - when VS05 is also installed on the same machine - as would be the case on development boxes. On a production db server it is unlikly that I would install the full VS, but who knows, it might be necessary, and should be possible without worry that SQL05 will be broken.

MikeC

Error from create SSIS package (save to server):
===================================

No description found (Microsoft Visual Studio)
Program Location: at Microsoft.SqlServer.Dts.Runtime.Application.SaveToSqlServerAs(Package package, IDTSEvents events, String packagePath, String serverName, String serverUserName, String serverPassword) at Microsoft.DataTransformationServices.Controls.PackageLocationControl.SavePackage(Package package) at Microsoft.DataTransformationServices.Design.Controls.PackageSaveCopyForm.PackageSaveCopyForm_FormClosing(Object sender, FormClosingEventArgs e)

===================================

Error from copy db wizard:
===================================

No description found (Copy Database Wizard)
Program Location: at Microsoft.SqlServer.Dts.Runtime.Application.SaveToSqlServerAs(Package package, IDTSEvents events, String packagePath, String serverName, String
serverUserName, String serverPassword) at Microsoft.SqlServer.Management.CopyDatabaseWizard.PackageCreator.SavePackage()

===================================

|||

Thanks for the feedback Mike.

I'm moving this to the SQL Setup alias to get comments from the SQL Team.

|||

Mike,

is your issue resolved? I would like to know what the resolution was if it has been resolved. Iam encountering the same issue now.

My setup is:

1. Installed SQL2000 (default instance)

2. Installed SQL2005 (named instance)

All on C:

I was able to save SSIS packages to the DB until recently using "Save Copy of <pkg> As".

Now I'm encountering the above error (No decription found etc..). I don't even remember anymore if I specified the <machine name> OR <machine name>\<Instance Name> for the "Server" when I had it working.

But I tried with both and I get different errors:

<machine name>\<Instance Name> : No decription found etc.

<machine name> :

======================
The ExistsOnSQLServer method has encountered OLE DB error code 0x80004005 (Client unable to establish connection). The SQL statement issued has failed.
(Microsoft Visual Studio)

=======================

For "Protection Level", I have tried different options, but it doesn't seem to matter.

Another thing is that I suspect this may have started happening after I was trying to install VS05 (other components) on top of the default version that was installed along with SQL05. I didn't go ahead with the VS install and canceled it half way through the initial install setup.

Any inputs are appreciated.

Thanks.

|||

Sql_Rv,

I have an open support call with M$ for the last week or so about the "can't save package" problem. This problem with saving packages absolutely has something to do with installing VS05 on the same machine that has SQL05 installed. Works without VS05, fails with VS05 installed.

To fix your installation (without a complete wipe of the house-of-cards that is Windows ), I suggest installing VS05 all the way! Then run the VS05 uninstall. This is the only way to get the VS05 install/uninstall program to run and remove the all the bits of VS05 that M$ stashes all over the place - especially the registry. I would hope that an aborted VS05 install would back-out any changes, but given the somewhat buggy state of Win03r2, MMCv3, VS05 and SQL05 tools… Really, I don’t think M$ has it altogether any more, the testers likely do not have initiative to try anything slightly out of line…

Lets see - ALL third party and M$ products like ISA04 that use MMC cause the new MMC v3 to crash on WinR2 - really - what kind of testing is M$ doing? I suppose we are doing the testing for them...

It would be nice if M$ (and other M$ app mfg) would wake up and see the simplicity of installing all executables of an application in ONE directory tree, and have a minimal registry footprint. A manifest of files would be nice also - but no, we get this horrific splat of install logs that lists what files were installed - and the number of registry entries that get added by SQL05 is obscene. Really, it is too much to ask for list of files and their versions needed to maintain a SQL05 installation? Tracking revisions must be a fuzzy concept at M$...

Anyway - M$ support is slow on the testing and the wonderfully informative error message "no description found" goes a long way in pointing to the problem - not.

Question: What version of Windows are you running? Is it a domain controller? Are SQL services running with a domain account?

MikeC

|||

Mike,

Thanks for taking the time to respond. I appreciate it.

This is on my dev box which is running XP Pro. No, it is not a domain controller. Yes, the services are running with a domain account that has admin privileges on this box.

btw, to get around this problem, I tried saving it from a different machine and it worked. This is what I did:

box1\2K5 - Unable to save the pkg to this DB from box1.

box2 - Has a 2K5 instance too. I used this to save it to box1\2K5 by doing a save as and specifying box1\2K5 as the SQLServer name - and it saved successfully.

Thanks,

RV

|||

I have the same problem.

MS WinXP Pro sp2 (latest patches as of 9.26.2006)

SQL Server 2005

VS2005

error:TITLE: SQL Server Import and Export Wizard The operation could not be completed. ADDITIONAL INFORMATION: The ExistsOnSQLServer method has encountered OLE DB error code 0x80004005 (Client unable to establish connection). The SQL statement issued has failed. BUTTONS: OK

The error is generated when I try to save the SISS package to the SQL server instance mentioned above.

I was able to save the SISS package using the filesystem option.

Is Installing SQL05dev and VS05pro on the same machine supported?

Hello,

When SQL05dev is installed a SQL05 version of Visual Studio (SQL05-VS) is also installed (called the “SQL Server Business Intelligence Development Studio”). The SQL05-VS installs files into a “C:\Program Files\Microsoft SQL Server\90\Tools\binn\VSShell\Common7\IDE” directory (and other directories - not described here).

When the full version VS05pro is installed it installs/uses files in a “C:\Program Files\Microsoft Visual Studio 8\Common7\IDE” directory.

The number of files in these two directories is different – the directory for VS05pro has (of course) many many more files than the directory for SQL05-VS. On the surface this seems ok since the install of VS05pro should supersede the install of the SQL05-VS and when VS05 is started it utilizes the files from the VS05pro directory and picks up the functions from the SQL05-VS (like SSIS, SSAS, SSRS and such).

But what about the SQL05-VS Common7/IDE directory? In this directory are 64 files that exist in both directores (556 files are not found in the VS05pro Common7/IDE directory). Additionally, there are 10 files that have different versions (mostly having to do with SQL-CE) – newer versions are in the SQL05-VS directory.

I’m confused. Is Microsoft going to support revision changes (Service Packs and such) to both directories? I suppose so, but this introduces possible versioning problems when SQL is updated but VS is not or VS is updated but SQL is not.

I guess I do not understand the rational for not maintaining a single VS directory structure and the problems that this creates. Microsoft is utilizing VS as the IDE for SQL but to not have a really good matching installation layout with the full version of VS is wacky – to say the least. Maybe M$ considers maintaing the versions of 64 files to be unimportant for the correct functioning of VS?

Is Installing SQL05dev and VS05pro on the same machine supported?

MikeC

Installing VS 2005 (and flavor) and SQL 2005 on the same machine is supported.

SQL installs what we call the Premier Partner Edition, which is just the basic IDE with no langauges. SQL then installs its own packages on top of the IDE.

The additional files are SQL specific. The Premier Partner Edition and any VS flavor will install to one location. If you install SQL first, when installing VS, VS will "lock" you to install to a specific directory and won't allow you to install anywhere you want.

That way, you only have one version of the file, its serviced in one place, and is properly ref counted.

|||

QuanT,

You said, "Installing VS 2005 (and flavor) and SQL 2005 on the same machine is supported.”

If this is the case, then I would like to see Microsoft fix the problems with SQL05 when VS and SQL05 are installed on the same machine – *but not to the C: volume*. That is - installing full VS05 (without SQL Express) and SQL05 to a non-C: volume on a freshly formatted/installed version of Windows 2003R2.

You said “If you install SQL first, when installing VS, VS will "lock" you to install to a specific directory and won't allow you to install anywhere you want."

It does not matter which you install first, installing VS to a non-C: volume after SQL is installed to a non-C: volume broke SSIS and the copy db wizard (I did not do any checking beyond these show-stoppers…)

Installing VS first (to a non-C: volume) allows the SQL install to install more components to a non-C: volume, but the problems still arise. Installing in this order should also be supported.

Installing VS to C: and SQL to E: works, but then RS has issues...

It appears that very little SQL05 installation testing was done to anything other than a C: volume - when VS05 is also installed on the same machine - as would be the case on development boxes. On a production db server it is unlikly that I would install the full VS, but who knows, it might be necessary, and should be possible without worry that SQL05 will be broken.

MikeC

Error from create SSIS package (save to server):
===================================

No description found (Microsoft Visual Studio)
Program Location: at Microsoft.SqlServer.Dts.Runtime.Application.SaveToSqlServerAs(Package package, IDTSEvents events, String packagePath, String serverName, String serverUserName, String serverPassword) at Microsoft.DataTransformationServices.Controls.PackageLocationControl.SavePackage(Package package) at Microsoft.DataTransformationServices.Design.Controls.PackageSaveCopyForm.PackageSaveCopyForm_FormClosing(Object sender, FormClosingEventArgs e)

===================================

Error from copy db wizard:
===================================

No description found (Copy Database Wizard)
Program Location: at Microsoft.SqlServer.Dts.Runtime.Application.SaveToSqlServerAs(Package package, IDTSEvents events, String packagePath, String serverName, String
serverUserName, String serverPassword) at Microsoft.SqlServer.Management.CopyDatabaseWizard.PackageCreator.SavePackage()

===================================

|||

Thanks for the feedback Mike.

I'm moving this to the SQL Setup alias to get comments from the SQL Team.

|||

Mike,

is your issue resolved? I would like to know what the resolution was if it has been resolved. Iam encountering the same issue now.

My setup is:

1. Installed SQL2000 (default instance)

2. Installed SQL2005 (named instance)

All on C:

I was able to save SSIS packages to the DB until recently using "Save Copy of <pkg> As".

Now I'm encountering the above error (No decription found etc..). I don't even remember anymore if I specified the <machine name> OR <machine name>\<Instance Name> for the "Server" when I had it working.

But I tried with both and I get different errors:

<machine name>\<Instance Name> : No decription found etc.

<machine name> :

======================
The ExistsOnSQLServer method has encountered OLE DB error code 0x80004005 (Client unable to establish connection). The SQL statement issued has failed.
(Microsoft Visual Studio)

=======================

For "Protection Level", I have tried different options, but it doesn't seem to matter.

Another thing is that I suspect this may have started happening after I was trying to install VS05 (other components) on top of the default version that was installed along with SQL05. I didn't go ahead with the VS install and canceled it half way through the initial install setup.

Any inputs are appreciated.

Thanks.

|||

Sql_Rv,

I have an open support call with M$ for the last week or so about the "can't save package" problem. This problem with saving packages absolutely has something to do with installing VS05 on the same machine that has SQL05 installed. Works without VS05, fails with VS05 installed.

To fix your installation (without a complete wipe of the house-of-cards that is Windows ), I suggest installing VS05 all the way! Then run the VS05 uninstall. This is the only way to get the VS05 install/uninstall program to run and remove the all the bits of VS05 that M$ stashes all over the place - especially the registry. I would hope that an aborted VS05 install would back-out any changes, but given the somewhat buggy state of Win03r2, MMCv3, VS05 and SQL05 tools… Really, I don’t think M$ has it altogether any more, the testers likely do not have initiative to try anything slightly out of line…

Lets see - ALL third party and M$ products like ISA04 that use MMC cause the new MMC v3 to crash on WinR2 - really - what kind of testing is M$ doing? I suppose we are doing the testing for them...

It would be nice if M$ (and other M$ app mfg) would wake up and see the simplicity of installing all executables of an application in ONE directory tree, and have a minimal registry footprint. A manifest of files would be nice also - but no, we get this horrific splat of install logs that lists what files were installed - and the number of registry entries that get added by SQL05 is obscene. Really, it is too much to ask for list of files and their versions needed to maintain a SQL05 installation? Tracking revisions must be a fuzzy concept at M$...

Anyway - M$ support is slow on the testing and the wonderfully informative error message "no description found" goes a long way in pointing to the problem - not.

Question: What version of Windows are you running? Is it a domain controller? Are SQL services running with a domain account?

MikeC

|||

Mike,

Thanks for taking the time to respond. I appreciate it.

This is on my dev box which is running XP Pro. No, it is not a domain controller. Yes, the services are running with a domain account that has admin privileges on this box.

btw, to get around this problem, I tried saving it from a different machine and it worked. This is what I did:

box1\2K5 - Unable to save the pkg to this DB from box1.

box2 - Has a 2K5 instance too. I used this to save it to box1\2K5 by doing a save as and specifying box1\2K5 as the SQLServer name - and it saved successfully.

Thanks,

RV

|||

I have the same problem.

MS WinXP Pro sp2 (latest patches as of 9.26.2006)

SQL Server 2005

VS2005

error:TITLE: SQL Server Import and Export Wizard The operation could not be completed. ADDITIONAL INFORMATION: The ExistsOnSQLServer method has encountered OLE DB error code 0x80004005 (Client unable to establish connection). The SQL statement issued has failed. BUTTONS: OK

The error is generated when I try to save the SISS package to the SQL server instance mentioned above.

I was able to save the SISS package using the filesystem option.

Is Installing SQL05dev and VS05pro on the same machine supported?

Hello,

When SQL05dev is installed a SQL05 version of Visual Studio (SQL05-VS) is also installed (called the “SQL Server Business Intelligence Development Studio”). The SQL05-VS installs files into a “C:\Program Files\Microsoft SQL Server\90\Tools\binn\VSShell\Common7\IDE” directory (and other directories - not described here).

When the full version VS05pro is installed it installs/uses files in a “C:\Program Files\Microsoft Visual Studio 8\Common7\IDE” directory.

The number of files in these two directories is different – the directory for VS05pro has (of course) many many more files than the directory for SQL05-VS. On the surface this seems ok since the install of VS05pro should supersede the install of the SQL05-VS and when VS05 is started it utilizes the files from the VS05pro directory and picks up the functions from the SQL05-VS (like SSIS, SSAS, SSRS and such).

But what about the SQL05-VS Common7/IDE directory? In this directory are 64 files that exist in both directores (556 files are not found in the VS05pro Common7/IDE directory). Additionally, there are 10 files that have different versions (mostly having to do with SQL-CE) – newer versions are in the SQL05-VS directory.

I’m confused. Is Microsoft going to support revision changes (Service Packs and such) to both directories? I suppose so, but this introduces possible versioning problems when SQL is updated but VS is not or VS is updated but SQL is not.

I guess I do not understand the rational for not maintaining a single VS directory structure and the problems that this creates. Microsoft is utilizing VS as the IDE for SQL but to not have a really good matching installation layout with the full version of VS is wacky – to say the least. Maybe M$ considers maintaing the versions of 64 files to be unimportant for the correct functioning of VS?

Is Installing SQL05dev and VS05pro on the same machine supported?

MikeC

Installing VS 2005 (and flavor) and SQL 2005 on the same machine is supported.

SQL installs what we call the Premier Partner Edition, which is just the basic IDE with no langauges. SQL then installs its own packages on top of the IDE.

The additional files are SQL specific. The Premier Partner Edition and any VS flavor will install to one location. If you install SQL first, when installing VS, VS will "lock" you to install to a specific directory and won't allow you to install anywhere you want.

That way, you only have one version of the file, its serviced in one place, and is properly ref counted.

|||

QuanT,

You said, "Installing VS 2005 (and flavor) and SQL 2005 on the same machine is supported.”

If this is the case, then I would like to see Microsoft fix the problems with SQL05 when VS and SQL05 are installed on the same machine – *but not to the C: volume*. That is - installing full VS05 (without SQL Express) and SQL05 to a non-C: volume on a freshly formatted/installed version of Windows 2003R2.

You said “If you install SQL first, when installing VS, VS will "lock" you to install to a specific directory and won't allow you to install anywhere you want."

It does not matter which you install first, installing VS to a non-C: volume after SQL is installed to a non-C: volume broke SSIS and the copy db wizard (I did not do any checking beyond these show-stoppers…)

Installing VS first (to a non-C: volume) allows the SQL install to install more components to a non-C: volume, but the problems still arise. Installing in this order should also be supported.

Installing VS to C: and SQL to E: works, but then RS has issues...

It appears that very little SQL05 installation testing was done to anything other than a C: volume - when VS05 is also installed on the same machine - as would be the case on development boxes. On a production db server it is unlikly that I would install the full VS, but who knows, it might be necessary, and should be possible without worry that SQL05 will be broken.

MikeC

Error from create SSIS package (save to server):
===================================

No description found (Microsoft Visual Studio)
Program Location: at Microsoft.SqlServer.Dts.Runtime.Application.SaveToSqlServerAs(Package package, IDTSEvents events, String packagePath, String serverName, String serverUserName, String serverPassword) at Microsoft.DataTransformationServices.Controls.PackageLocationControl.SavePackage(Package package) at Microsoft.DataTransformationServices.Design.Controls.PackageSaveCopyForm.PackageSaveCopyForm_FormClosing(Object sender, FormClosingEventArgs e)

===================================

Error from copy db wizard:
===================================

No description found (Copy Database Wizard)
Program Location: at Microsoft.SqlServer.Dts.Runtime.Application.SaveToSqlServerAs(Package package, IDTSEvents events, String packagePath, String serverName, String
serverUserName, String serverPassword) at Microsoft.SqlServer.Management.CopyDatabaseWizard.PackageCreator.SavePackage()

===================================

|||

Thanks for the feedback Mike.

I'm moving this to the SQL Setup alias to get comments from the SQL Team.

|||

Mike,

is your issue resolved? I would like to know what the resolution was if it has been resolved. Iam encountering the same issue now.

My setup is:

1. Installed SQL2000 (default instance)

2. Installed SQL2005 (named instance)

All on C:

I was able to save SSIS packages to the DB until recently using "Save Copy of <pkg> As".

Now I'm encountering the above error (No decription found etc..). I don't even remember anymore if I specified the <machine name> OR <machine name>\<Instance Name> for the "Server" when I had it working.

But I tried with both and I get different errors:

<machine name>\<Instance Name> : No decription found etc.

<machine name> :

======================
The ExistsOnSQLServer method has encountered OLE DB error code 0x80004005 (Client unable to establish connection). The SQL statement issued has failed.
(Microsoft Visual Studio)

=======================

For "Protection Level", I have tried different options, but it doesn't seem to matter.

Another thing is that I suspect this may have started happening after I was trying to install VS05 (other components) on top of the default version that was installed along with SQL05. I didn't go ahead with the VS install and canceled it half way through the initial install setup.

Any inputs are appreciated.

Thanks.

|||

Sql_Rv,

I have an open support call with M$ for the last week or so about the "can't save package" problem. This problem with saving packages absolutely has something to do with installing VS05 on the same machine that has SQL05 installed. Works without VS05, fails with VS05 installed.

To fix your installation (without a complete wipe of the house-of-cards that is Windows ), I suggest installing VS05 all the way! Then run the VS05 uninstall. This is the only way to get the VS05 install/uninstall program to run and remove the all the bits of VS05 that M$ stashes all over the place - especially the registry. I would hope that an aborted VS05 install would back-out any changes, but given the somewhat buggy state of Win03r2, MMCv3, VS05 and SQL05 tools… Really, I don’t think M$ has it altogether any more, the testers likely do not have initiative to try anything slightly out of line…

Lets see - ALL third party and M$ products like ISA04 that use MMC cause the new MMC v3 to crash on WinR2 - really - what kind of testing is M$ doing? I suppose we are doing the testing for them...

It would be nice if M$ (and other M$ app mfg) would wake up and see the simplicity of installing all executables of an application in ONE directory tree, and have a minimal registry footprint. A manifest of files would be nice also - but no, we get this horrific splat of install logs that lists what files were installed - and the number of registry entries that get added by SQL05 is obscene. Really, it is too much to ask for list of files and their versions needed to maintain a SQL05 installation? Tracking revisions must be a fuzzy concept at M$...

Anyway - M$ support is slow on the testing and the wonderfully informative error message "no description found" goes a long way in pointing to the problem - not.

Question: What version of Windows are you running? Is it a domain controller? Are SQL services running with a domain account?

MikeC

|||

Mike,

Thanks for taking the time to respond. I appreciate it.

This is on my dev box which is running XP Pro. No, it is not a domain controller. Yes, the services are running with a domain account that has admin privileges on this box.

btw, to get around this problem, I tried saving it from a different machine and it worked. This is what I did:

box1\2K5 - Unable to save the pkg to this DB from box1.

box2 - Has a 2K5 instance too. I used this to save it to box1\2K5 by doing a save as and specifying box1\2K5 as the SQLServer name - and it saved successfully.

Thanks,

RV

|||

I have the same problem.

MS WinXP Pro sp2 (latest patches as of 9.26.2006)

SQL Server 2005

VS2005

error:TITLE: SQL Server Import and Export Wizard The operation could not be completed. ADDITIONAL INFORMATION: The ExistsOnSQLServer method has encountered OLE DB error code 0x80004005 (Client unable to establish connection). The SQL statement issued has failed. BUTTONS: OK

The error is generated when I try to save the SISS package to the SQL server instance mentioned above.

I was able to save the SISS package using the filesystem option.

Is database mirroring the solution for this scenario?

We have an OLTP database handling our business production operations.
Our reporting team wants to extract from the OLTP db every 15 min, but
that will hammer the OLTP db I/O-wise, breaking the system. The
reporting team wants a copy of the OLTP system to do their extractions.
The copy should be kept up-to-date with the OLTP system on a near
continuous basis and be fully readable for extraction (At no time should
the copy ever become unavailable during sync activities). We do not
want to use SQL replication, and are looking at various alternatives
involving SAN snapshot technologies. Due to our requirements, several
of the SAN vendors have recommended using the built-in database
mirroring feature in 2005. I was under the impression that the mirror
was not available for use while it was being kept in sync and once the
mirror was made available, it would have to be reinitialized to resume
syncing. Am I correct, or is there a way to have the mirrored copy
available but still syncing?
You are right that the mirror database itself isn't available for reporting.
However, a snapshot from the mirror can provide a read-only view of the
database at a particular point in time. My guess is that this is what the
SAN vendors are suggesting.
Hope this helps.
Dan Guzman
SQL Server MVP
"DotComDBA" <noreply@.nospam.com> wrote in message
news:uFMrCrtKHHA.536@.TK2MSFTNGP02.phx.gbl...
> We have an OLTP database handling our business production operations. Our
> reporting team wants to extract from the OLTP db every 15 min, but that
> will hammer the OLTP db I/O-wise, breaking the system. The reporting team
> wants a copy of the OLTP system to do their extractions. The copy should
> be kept up-to-date with the OLTP system on a near continuous basis and be
> fully readable for extraction (At no time should the copy ever become
> unavailable during sync activities). We do not want to use SQL
> replication, and are looking at various alternatives involving SAN
> snapshot technologies. Due to our requirements, several of the SAN
> vendors have recommended using the built-in database mirroring feature in
> 2005. I was under the impression that the mirror was not available for
> use while it was being kept in sync and once the mirror was made
> available, it would have to be reinitialized to resume syncing. Am I
> correct, or is there a way to have the mirrored copy available but still
> syncing?
|||I was the DBA on an OLTP system for 10 years (yes a dotcom) and I must
question this "poll every 15 minutes that hammers the system" statement.
There should be NOTHING you should be pulling every 15 minutes that could
take more than a few seconds (if that) that is not going to be a waste.
What are they asking for? All sales? All hits? Promo pages? Are you dumping
everything every time? Put an index on the dattime field of the parent table
and dump the activity since the last dump.
I'm guessing they stuck you with RAID 5, or 6 too - write penalty and all.
RAID 0 is my prefered, 1 01 & 10 are OK. And keep the database files away
from everything else - like the temp directory, spooler and transaction logs.
Make a list of their needs, not what they say they want, but find out what
they are using and actually need. Then, if necessarg, build a seperate
database (call it a markting system) and dump data to it incremently.
Seperate the databases by transfering data via files, or perhaps dedicate a
crssover tcp/ip cable.
Whatever you do, keep them off the production server. They have a budget,
have them pay for what they need.
"DotComDBA" wrote:

> We have an OLTP database handling our business production operations.
> Our reporting team wants to extract from the OLTP db every 15 min, but
> that will hammer the OLTP db I/O-wise, breaking the system. The
> reporting team wants a copy of the OLTP system to do their extractions.
> The copy should be kept up-to-date with the OLTP system on a near
> continuous basis and be fully readable for extraction (At no time should
> the copy ever become unavailable during sync activities). We do not
> want to use SQL replication, and are looking at various alternatives
> involving SAN snapshot technologies. Due to our requirements, several
> of the SAN vendors have recommended using the built-in database
> mirroring feature in 2005. I was under the impression that the mirror
> was not available for use while it was being kept in sync and once the
> mirror was made available, it would have to be reinitialized to resume
> syncing. Am I correct, or is there a way to have the mirrored copy
> available but still syncing?
>
|||We have a similar need & setup (i.e. OLTP + operational reporting / MIS
needs), and do get significant performance gains for both OLTP and
reporting by mirroring - have found that running reports on the OLTP
server can esp hammer counters like the buffer hit ratios etc
Mirroring (e.g. Asynch in SQL 2005) works fine without loading the OLTP
server
If you do "use" your read-only slave, you might need to consider
licensing issues / costs.
You might also look at using regular log shipping
e.g. we roll our OLTP Enterprise Ed SQL logs forward onto a Std Ed
reporting server at 30 minute intervals, and at the same time copy the
logs off site as a DR safety precaution.
We do have a few "real time" reports which we do allow on the live OLTP
server (but you need to set stringent criteria on such reports as per
other poster). The rest (~500 reports) are run off the slave.
The one 'draw back' of log shipping is that you will need to boot all
connections off your slave reporting database slave every time you roll
forward.
The other alternative considered was replication - on the upside it
allowed creation of different indices (mirroring / log shipping
duplicates indices, meaning you have to create your MIS indices on the
OLTP server as well ... ). On the downside, there seemed no real
'guarantees' on the data synchronisation (i.e. for Disaster recovery we
sleep better if using Mirroring or Log Shipping to the slave).
We didn't meet with much success on the SAN Snapshots (unless you e.g.
use a permanent 'mirror') - depending on the size of the disks you need
to snapshot, the SAN still has a finite bandwidth - (our 5 yo SAN can
data transfer was at only around 500GB per hour), and doing the
snapshot does chew up the SAN resources.
Regards
Stuart

Is database mirroring the solution for this scenario?

We have an OLTP database handling our business production operations.
Our reporting team wants to extract from the OLTP db every 15 min, but
that will hammer the OLTP db I/O-wise, breaking the system. The
reporting team wants a copy of the OLTP system to do their extractions.
The copy should be kept up-to-date with the OLTP system on a near
continuous basis and be fully readable for extraction (At no time should
the copy ever become unavailable during sync activities). We do not
want to use SQL replication, and are looking at various alternatives
involving SAN snapshot technologies. Due to our requirements, several
of the SAN vendors have recommended using the built-in database
mirroring feature in 2005. I was under the impression that the mirror
was not available for use while it was being kept in sync and once the
mirror was made available, it would have to be reinitialized to resume
syncing. Am I correct, or is there a way to have the mirrored copy
available but still syncing?You are right that the mirror database itself isn't available for reporting.
However, a snapshot from the mirror can provide a read-only view of the
database at a particular point in time. My guess is that this is what the
SAN vendors are suggesting.
Hope this helps.
Dan Guzman
SQL Server MVP
"DotComDBA" <noreply@.nospam.com> wrote in message
news:uFMrCrtKHHA.536@.TK2MSFTNGP02.phx.gbl...
> We have an OLTP database handling our business production operations. Our
> reporting team wants to extract from the OLTP db every 15 min, but that
> will hammer the OLTP db I/O-wise, breaking the system. The reporting team
> wants a copy of the OLTP system to do their extractions. The copy should
> be kept up-to-date with the OLTP system on a near continuous basis and be
> fully readable for extraction (At no time should the copy ever become
> unavailable during sync activities). We do not want to use SQL
> replication, and are looking at various alternatives involving SAN
> snapshot technologies. Due to our requirements, several of the SAN
> vendors have recommended using the built-in database mirroring feature in
> 2005. I was under the impression that the mirror was not available for
> use while it was being kept in sync and once the mirror was made
> available, it would have to be reinitialized to resume syncing. Am I
> correct, or is there a way to have the mirrored copy available but still
> syncing?|||I was the DBA on an OLTP system for 10 years (yes a dotcom) and I must
question this "poll every 15 minutes that hammers the system" statement.
There should be NOTHING you should be pulling every 15 minutes that could
take more than a few seconds (if that) that is not going to be a waste.
What are they asking for? All sales? All hits? Promo pages? Are you dumping
everything every time? Put an index on the dattime field of the parent table
and dump the activity since the last dump.
I'm guessing they stuck you with RAID 5, or 6 too - write penalty and all.
RAID 0 is my prefered, 1 01 & 10 are OK. And keep the database files away
from everything else - like the temp directory, spooler and transaction logs
.
Make a list of their needs, not what they say they want, but find out what
they are using and actually need. Then, if necessarg, build a seperate
database (call it a markting system) and dump data to it incremently.
Seperate the databases by transfering data via files, or perhaps dedicate a
crssover tcp/ip cable.
Whatever you do, keep them off the production server. They have a budget,
have them pay for what they need.
"DotComDBA" wrote:

> We have an OLTP database handling our business production operations.
> Our reporting team wants to extract from the OLTP db every 15 min, but
> that will hammer the OLTP db I/O-wise, breaking the system. The
> reporting team wants a copy of the OLTP system to do their extractions.
> The copy should be kept up-to-date with the OLTP system on a near
> continuous basis and be fully readable for extraction (At no time should
> the copy ever become unavailable during sync activities). We do not
> want to use SQL replication, and are looking at various alternatives
> involving SAN snapshot technologies. Due to our requirements, several
> of the SAN vendors have recommended using the built-in database
> mirroring feature in 2005. I was under the impression that the mirror
> was not available for use while it was being kept in sync and once the
> mirror was made available, it would have to be reinitialized to resume
> syncing. Am I correct, or is there a way to have the mirrored copy
> available but still syncing?
>|||We have a similar need & setup (i.e. OLTP + operational reporting / MIS
needs), and do get significant performance gains for both OLTP and
reporting by mirroring - have found that running reports on the OLTP
server can esp hammer counters like the buffer hit ratios etc
Mirroring (e.g. Asynch in SQL 2005) works fine without loading the OLTP
server
If you do "use" your read-only slave, you might need to consider
licensing issues / costs.
You might also look at using regular log shipping
e.g. we roll our OLTP Enterprise Ed SQL logs forward onto a Std Ed
reporting server at 30 minute intervals, and at the same time copy the
logs off site as a DR safety precaution.
We do have a few "real time" reports which we do allow on the live OLTP
server (but you need to set stringent criteria on such reports as per
other poster). The rest (~500 reports) are run off the slave.
The one 'draw back' of log shipping is that you will need to boot all
connections off your slave reporting database slave every time you roll
forward.
The other alternative considered was replication - on the upside it
allowed creation of different indices (mirroring / log shipping
duplicates indices, meaning you have to create your MIS indices on the
OLTP server as well ... ). On the downside, there seemed no real
'guarantees' on the data synchronisation (i.e. for Disaster recovery we
sleep better if using Mirroring or Log Shipping to the slave).
We didn't meet with much success on the SAN Snapshots (unless you e.g.
use a permanent 'mirror') - depending on the size of the disks you need
to snapshot, the SAN still has a finite bandwidth - (our 5 yo SAN can
data transfer was at only around 500GB per hour), and doing the
snapshot does chew up the SAN resources.
Regards
Stuart

Is database mirroring the solution for this scenario?

We have an OLTP database handling our business production operations.
Our reporting team wants to extract from the OLTP db every 15 min, but
that will hammer the OLTP db I/O-wise, breaking the system. The
reporting team wants a copy of the OLTP system to do their extractions.
The copy should be kept up-to-date with the OLTP system on a near
continuous basis and be fully readable for extraction (At no time should
the copy ever become unavailable during sync activities). We do not
want to use SQL replication, and are looking at various alternatives
involving SAN snapshot technologies. Due to our requirements, several
of the SAN vendors have recommended using the built-in database
mirroring feature in 2005. I was under the impression that the mirror
was not available for use while it was being kept in sync and once the
mirror was made available, it would have to be reinitialized to resume
syncing. Am I correct, or is there a way to have the mirrored copy
available but still syncing?You are right that the mirror database itself isn't available for reporting.
However, a snapshot from the mirror can provide a read-only view of the
database at a particular point in time. My guess is that this is what the
SAN vendors are suggesting.
--
Hope this helps.
Dan Guzman
SQL Server MVP
"DotComDBA" <noreply@.nospam.com> wrote in message
news:uFMrCrtKHHA.536@.TK2MSFTNGP02.phx.gbl...
> We have an OLTP database handling our business production operations. Our
> reporting team wants to extract from the OLTP db every 15 min, but that
> will hammer the OLTP db I/O-wise, breaking the system. The reporting team
> wants a copy of the OLTP system to do their extractions. The copy should
> be kept up-to-date with the OLTP system on a near continuous basis and be
> fully readable for extraction (At no time should the copy ever become
> unavailable during sync activities). We do not want to use SQL
> replication, and are looking at various alternatives involving SAN
> snapshot technologies. Due to our requirements, several of the SAN
> vendors have recommended using the built-in database mirroring feature in
> 2005. I was under the impression that the mirror was not available for
> use while it was being kept in sync and once the mirror was made
> available, it would have to be reinitialized to resume syncing. Am I
> correct, or is there a way to have the mirrored copy available but still
> syncing?|||I was the DBA on an OLTP system for 10 years (yes a dotcom) and I must
question this "poll every 15 minutes that hammers the system" statement.
There should be NOTHING you should be pulling every 15 minutes that could
take more than a few seconds (if that) that is not going to be a waste.
What are they asking for? All sales? All hits? Promo pages? Are you dumping
everything every time? Put an index on the dattime field of the parent table
and dump the activity since the last dump.
I'm guessing they stuck you with RAID 5, or 6 too - write penalty and all.
RAID 0 is my prefered, 1 01 & 10 are OK. And keep the database files away
from everything else - like the temp directory, spooler and transaction logs.
Make a list of their needs, not what they say they want, but find out what
they are using and actually need. Then, if necessarg, build a seperate
database (call it a markting system) and dump data to it incremently.
Seperate the databases by transfering data via files, or perhaps dedicate a
crssover tcp/ip cable.
Whatever you do, keep them off the production server. They have a budget,
have them pay for what they need.
"DotComDBA" wrote:
> We have an OLTP database handling our business production operations.
> Our reporting team wants to extract from the OLTP db every 15 min, but
> that will hammer the OLTP db I/O-wise, breaking the system. The
> reporting team wants a copy of the OLTP system to do their extractions.
> The copy should be kept up-to-date with the OLTP system on a near
> continuous basis and be fully readable for extraction (At no time should
> the copy ever become unavailable during sync activities). We do not
> want to use SQL replication, and are looking at various alternatives
> involving SAN snapshot technologies. Due to our requirements, several
> of the SAN vendors have recommended using the built-in database
> mirroring feature in 2005. I was under the impression that the mirror
> was not available for use while it was being kept in sync and once the
> mirror was made available, it would have to be reinitialized to resume
> syncing. Am I correct, or is there a way to have the mirrored copy
> available but still syncing?
>|||We have a similar need & setup (i.e. OLTP + operational reporting / MIS
needs), and do get significant performance gains for both OLTP and
reporting by mirroring - have found that running reports on the OLTP
server can esp hammer counters like the buffer hit ratios etc
Mirroring (e.g. Asynch in SQL 2005) works fine without loading the OLTP
server
If you do "use" your read-only slave, you might need to consider
licensing issues / costs.
You might also look at using regular log shipping
e.g. we roll our OLTP Enterprise Ed SQL logs forward onto a Std Ed
reporting server at 30 minute intervals, and at the same time copy the
logs off site as a DR safety precaution.
We do have a few "real time" reports which we do allow on the live OLTP
server (but you need to set stringent criteria on such reports as per
other poster). The rest (~500 reports) are run off the slave.
The one 'draw back' of log shipping is that you will need to boot all
connections off your slave reporting database slave every time you roll
forward.
The other alternative considered was replication - on the upside it
allowed creation of different indices (mirroring / log shipping
duplicates indices, meaning you have to create your MIS indices on the
OLTP server as well ... ). On the downside, there seemed no real
'guarantees' on the data synchronisation (i.e. for Disaster recovery we
sleep better if using Mirroring or Log Shipping to the slave).
We didn't meet with much success on the SAN Snapshots (unless you e.g.
use a permanent 'mirror') - depending on the size of the disks you need
to snapshot, the SAN still has a finite bandwidth - (our 5 yo SAN can
data transfer was at only around 500GB per hour), and doing the
snapshot does chew up the SAN resources.
Regards
Stuart

Is Arcserve 2000 backing up my SQL server properly?

I recently installed arcserve small business version for a client who
is running SQL server. It seems that at the beginning of the backup
cycle the files are skipped due to a sharing violation (I mean the
database files). Later during the part when the SQL agent backs up
files it seems to back up fine. Is this normal or is something wrong
here. Below is a log...sorry if it is a little long. Thanks so much
for youe help.
20030701 010009 16 Run Backup Job Scheduled for 7/01/03 at 1:00 AM.
20030701 010009 16 Start Backup Operation. (QUEUE=1, JOB=2)
20030701 010010 16 Overwrite media Monthly2, ID DBA9, sequence #1
20030701 010037 TAPE Tape Engine finished formatting media.(new name:
Monthly2, old name: Monthly2)
20030701 010037 Begin cleaning database.
20030701 010044 Session is cleaned. (MEDIA=Monthly2, ID=FFFFDBA9,
SES=1, RECS=18130)
20030701 010047 Session is cleaned. (MEDIA=Monthly2, ID=FFFFDBA9,
SES=2, RECS=11705)
20030701 010048 TAPE Format Successful!
20030701 010048 16 Use media Monthly2, ID 2542, sequence #1
20030701 010054 Session is cleaned. (MEDIA=Monthly2, ID=FFFFDBA9,
SES=3, RECS=27896)
20030701 010129 16 Source Directory: C:
20030701 010129 16 Back up Session 1 on Media Monthly2
20030701 010129 16 Backed up volume disk quota.
20030701 010154 Session is cleaned. (MEDIA=Monthly2, ID=FFFFDBA9,
SES=4, RECS=151242)
20030701 010154 Session is cleaned. (MEDIA=Monthly2, ID=FFFFDBA9,
SES=5, RECS=7)
20030701 010154 Session is cleaned. (MEDIA=Monthly2, ID=FFFFDBA9,
SES=6, RECS=12)
20030701 010154 Session is cleaned. (MEDIA=Monthly2, ID=FFFFDBA9,
SES=7, RECS=12)
20030701 010154 Session is cleaned. (MEDIA=Monthly2, ID=FFFFDBA9,
SES=8, RECS=12)
20030701 010154 Session is cleaned. (MEDIA=Monthly2, ID=FFFFDBA9,
SES=9, RECS=12)
20030701 010154 Session is cleaned. (MEDIA=Monthly2, ID=FFFFDBA9,
SES=10, RECS=12)
20030701 010154 Session is cleaned. (MEDIA=Monthly2, ID=FFFFDBA9,
SES=11, RECS=12)
20030701 010159 Session is cleaned. (MEDIA=Monthly2, ID=FFFFDBA9,
SES=12, RECS=13291)
20030701 010159 Session is cleaned. (MEDIA=Monthly2, ID=FFFFDBA9,
SES=13, RECS=225)
20030701 010159 Session is cleaned. (MEDIA=Monthly2, ID=FFFFDBA9,
SES=14, RECS=123)
20030701 010159 End cleaning database. (CLEANED=222691)
20030701 010233 16 W3404 Unable to open file. (FILE=C:\Documents and
Settings\All Users\Application
Data\Microsoft\Network\Downloader\qmgr0.dat, EC=SHARING VIOLATION)
20030701 010233 16 W3404 Unable to open file. (FILE=C:\Documents and
Settings\All Users\Application
Data\Microsoft\Network\Downloader\qmgr1.dat, EC=SHARING VIOLATION)
20030701 010338 16 W3404 Unable to open file. (FILE=C:\Program
Files\Microsoft SQL Server\MSSQL$MSGPSBM\Data\GPSDYNAMICSDat.mdf,
EC=SHARING VIOLATION)
20030701 010338 16 W3404 Unable to open file. (FILE=C:\Program
Files\Microsoft SQL Server\MSSQL$MSGPSBM\Data\GPSDYNAMICSLog.ldf,
EC=SHARING VIOLATION)
20030701 010338 16 W3404 Unable to open file. (FILE=C:\Program
Files\Microsoft SQL Server\MSSQL$MSGPSBM\Data\GPSSBM01Dat.mdf,
EC=SHARING VIOLATION)
20030701 010338 16 W3404 Unable to open file. (FILE=C:\Program
Files\Microsoft SQL Server\MSSQL$MSGPSBM\Data\GPSSBM01Log.ldf,
EC=SHARING VIOLATION)
20030701 010338 16 W3404 Unable to open file. (FILE=C:\Program
Files\Microsoft SQL Server\MSSQL$MSGPSBM\Data\GPSTWODat.mdf,
EC=SHARING VIOLATION)
20030701 010338 16 W3404 Unable to open file. (FILE=C:\Program
Files\Microsoft SQL Server\MSSQL$MSGPSBM\Data\GPSTWOLog.ldf,
EC=SHARING VIOLATION)
20030701 010601 16 Catalog File Backed Up
20030701 010601 16 Registry Files Backed Up
20030701 010601 16 1,049 Directories 17,088 Files (1,404.55 MB) Backed
Up to Media.
20030701 010601 16 8 Directories/Files Skipped.
20030701 010601 16 1,463.31 MB Written to Media.
20030701 010601 16 Elapsed Time: 4m 30s
20030701 010601 16 Average Throughput: 325.17 MB/min
20030701 010601 16 Number of Errors/Warnings: 0/8
20030701 010611 16 Source Directory: E:
20030701 010611 16 Back up Session 2 on Media Monthly2
20030701 010611 16 Backed up volume disk quota.
20030701 011115 16 Catalog File Backed Up
20030701 011115 16 563 Directories 11,142 Files (1,254.87 MB) Backed
Up to Media.
20030701 011115 16 1,292.68 MB Written to Media.
20030701 011115 16 Elapsed Time: 5m 0s
20030701 011115 16 Average Throughput: 258.53 MB/min
20030701 011201 16 Source Directory: F:
20030701 011201 16 Back up Session 3 on Media Monthly2
20030701 011201 16 Backed up volume disk quota.
20030701 012213 16 Catalog File Backed Up
20030701 012213 16 4,665 Directories 23,262 Files (3,229.25 MB) Backed
Up to Media.
20030701 012213 16 3,320.18 MB Written to Media.
20030701 012213 16 Elapsed Time: 10m 9s
20030701 012213 16 Average Throughput: 327.11 MB/min
20030701 012213 16 Source Directory: Registry
20030701 012213 16 Back up Session 4 on Media Monthly2
20030701 012244 16 Registry Files Backed Up
20030701 012244 16 54,946 Directories 96,295 Files (21.42 MB) Backed
Up to Media.
20030701 012244 16 404.87 MB Written to Media.
20030701 012244 16 Elapsed Time: 28s
20030701 012244 16 Average Throughput: 867.58 MB/min
20030701 012244 16 Source Directory: dbaexchis\First Storage Group
20030701 012244 16 Back up Session 5 on Media Monthly2
20030701 012301 16 1 Databases/Transaction Logs (103.04 MB) Backed Up
to Media.
20030701 012301 16 103.12 MB Written to Media.
20030701 012301 16 Elapsed Time: 15s
20030701 012301 16 Average Throughput: 412.50 MB/min
20030701 012302 16 Source Directory: dbasql@.MSGPSBM\TWO
20030701 012302 16 Back up Session 6 on Media Monthly2
20030701 012311 16 1 Databases/Transaction Logs (90.07 MB) Backed Up
to Media.
20030701 012311 16 90.18 MB Written to Media.
20030701 012311 16 Elapsed Time: 7s
20030701 012311 16 Average Throughput: 773.03 MB/min
20030701 012311 16 Source Directory: dbasql@.MSGPSBM\SBM01
20030701 012311 16 Back up Session 7 on Media Monthly2
20030701 012355 16 1 Databases/Transaction Logs (548.07 MB) Backed Up
to Media.
20030701 012355 16 548.37 MB Written to Media.
20030701 012355 16 Elapsed Time: 42s
20030701 012355 16 Average Throughput: 783.39 MB/min
20030701 012355 16 Source Directory: dbasql@.MSGPSBM\msdb
20030701 012355 16 Back up Session 8 on Media Monthly2
20030701 012357 16 1 Databases/Transaction Logs (2.32 MB) Backed Up to
Media.
20030701 012357 16 2.37 MB Written to Media.
20030701 012357 16 Elapsed Time: 1s
20030701 012357 16 Average Throughput: 142.50 MB/min
20030701 012357 16 Source Directory: dbasql@.MSGPSBM\model
20030701 012357 16 Back up Session 9 on Media Monthly2
20030701 012400 16 1 Databases/Transaction Logs (721 KB) Backed Up to
Media.
20030701 012400 16 768 KB Written to Media.
20030701 012400 16 Elapsed Time: 1s
20030701 012400 16 Average Throughput: 45.00 MB/min
20030701 012400 16 Source Directory: dbasql@.MSGPSBM\master
20030701 012400 16 Back up Session 10 on Media Monthly2
20030701 012407 16 1 Databases/Transaction Logs (10.51 MB) Backed Up
to Media.
20030701 012407 16 10.56 MB Written to Media.
20030701 012407 16 Elapsed Time: 0s
20030701 012407 16 Average Throughput: 633.75 MB/min
20030701 012407 16 Source Directory: dbasql@.MSGPSBM\DYNAMICS
20030701 012407 16 Back up Session 11 on Media Monthly2
20030701 012412 16 1 Databases/Transaction Logs (29.95 MB) Backed Up
to Media.
20030701 012412 16 30.00 MB Written to Media.
20030701 012412 16 Elapsed Time: 3s
20030701 012412 16 Average Throughput: 600.00 MB/min
20030701 012413 16 Source Directory: System State
20030701 012413 16 Back up Session 12 on Media Monthly2
20030701 012413 16 Backing Up Files : Boot and System Protected Files
20030701 012445 16 Backing Up Files : Active Directory
20030701 012448 16 Backing Up Files : SysVol
20030701 012448 16 Backing Up Files : COM+ Class Registration Database
20030701 012448 16 Backing Up Files : Registry
20030701 012455 16 Registry Files Backed Up
20030701 012455 16 91 Directories 1,963 Files (287.99 MB) Backed Up to
Media.
20030701 012455 16 294.56 MB Written to Media.
20030701 012455 16 Elapsed Time: 39s
20030701 012455 16 Average Throughput: 453.17 MB/min
20030701 012455 16 Source Directory: dbaxchg2
20030701 012455 16 Back up Session 13 on Media Monthly2
20030701 012516 16 11 Databases/Transaction Logs (40.19 MB) Backed Up
to Media.
20030701 012516 16 40.50 MB Written to Media.
20030701 012516 16 Elapsed Time: 19s
20030701 012516 16 Average Throughput: 127.89 MB/min
20030701 012516 16 ** Summary for My Computer **
20030701 012516 16 13 Sessions.
20030701 012516 16 61,314 Directories 149,750 Files (6,198.15 MB)
Backed Up to Media.
20030701 012516 16 18 Databases/Transaction Logs (824.89 MB) Backed Up
to Media.
20030701 012516 16 8 Directories/Files Skipped.
20030701 012516 16 7,601.50 MB Written to Media.
20030701 012516 16 Elapsed Time: 22m 14s
20030701 012516 16 Average Throughput: 341.89 MB/min
20030701 012516 16 Number of Errors/Warnings: 0/8
20030701 012519 16 Backup ARCserve Database...
20030701 012520 16 Source Directory: C:\Program
Files\ComputerAssociates\ARCserve\DATABASE
20030701 012520 16 Back up Session 14 on Media Monthly2
20030701 012529 16 Catalog File Backed Up
20030701 012529 16 1 Directories 118 Files (104.17 MB) Backed Up to
Media.
20030701 012529 16 104.62 MB Written to Media.
20030701 012529 16 Elapsed Time: 7s
20030701 012529 16 Average Throughput: 896.78 MB/min
20030701 012529 16 ARCServe Database Backed Up
20030701 012538 [CAT] Monthly2 [ID:2542,SESSION:1] is
merged.(files=17088)
20030701 012542 [CAT] Monthly2 [ID:2542,SESSION:2] is
merged.(files=11142)
20030701 012555 [CAT] Monthly2 [ID:2542,SESSION:3] is
merged.(files=23262)
20030701 012631 16 ** Summary for Job **
20030701 012631 16 14 Sessions.
20030701 012631 16 61,315 Directories 149,868 Files (6,302.33 MB)
Backed Up to Media.
20030701 012631 16 18 Databases/Transaction Logs (824.89 MB) Backed Up
to Media.
20030701 012631 16 8 Directories/Files Skipped.
20030701 012631 16 7,706.12 MB Written to Media.
20030701 012631 16 Elapsed Time: 22m 21s
20030701 012631 16 Average Throughput: 344.79 MB/min
20030701 012631 16 Number of Errors/Warnings: 0/8
20030701 012631 16 Backup Operation Incomplete.
20030701 012702 [CAT] Monthly2 [ID:2542,SESSION:4] is
merged.(files=96295)
20030701 012702 [CAT] Monthly2 [ID:2542,SESSION:5] is merged.(files=5)
20030701 012702 [CAT] Monthly2 [ID:2542,SESSION:6] is merged.(files=3)
20030701 012702 [CAT] Monthly2 [ID:2542,SESSION:7] is merged.(files=3)
20030701 012702 [CAT] Monthly2 [ID:2542,SESSION:8] is merged.(files=3)
20030701 012702 [CAT] Monthly2 [ID:2542,SESSION:9] is merged.(files=3)
20030701 012702 [CAT] Monthly2 [ID:2542,SESSION:10] is
merged.(files=3)
20030701 012702 [CAT] Monthly2 [ID:2542,SESSION:11] is
merged.(files=3)
20030701 012708 [CAT] Monthly2 [ID:2542,SESSION:12] is
merged.(files=1963)
20030701 012708 [CAT] Monthly2 [ID:2542,SESSION:13] is
merged.(files=110)
20030701 012708 [CAT] Monthly2 [ID:2542,SESSION:14] is
merged.(files=118)
20030701 012709 16 Reschedule Backup Job for 7/02/03 at 1:00 AM.You can't normally backup the database files with ArcServe since they are
always in use. I believe they have a way to bypass that but then what good
is backing up a file that is constantly changing. You can't restore the db
using these backups made from Arcserve since they are not consistent. What
you can do is basically one of 2 things. Either use the SQL Server plug-in
for ArcServe to have it issue the equivalent of a sql server backup or don't
even attempt to backup the database files with Arcserve and have it backup
the files generated by the SQL Server backup.
--
Andrew J. Kelly
SQL Server MVP
"Devin G" <devin@.spamhole.com> wrote in message
news:495ba422.0307021902.4a418a32@.posting.google.com...
> I recently installed arcserve small business version for a client who
> is running SQL server. It seems that at the beginning of the backup
> cycle the files are skipped due to a sharing violation (I mean the
> database files). Later during the part when the SQL agent backs up
> files it seems to back up fine. Is this normal or is something wrong
> here. Below is a log...sorry if it is a little long. Thanks so much
> for youe help.
>
> 20030701 010009 16 Run Backup Job Scheduled for 7/01/03 at 1:00 AM.
> 20030701 010009 16 Start Backup Operation. (QUEUE=1, JOB=2)
> 20030701 010010 16 Overwrite media Monthly2, ID DBA9, sequence #1
> 20030701 010037 TAPE Tape Engine finished formatting media.(new name:
> Monthly2, old name: Monthly2)
> 20030701 010037 Begin cleaning database.
> 20030701 010044 Session is cleaned. (MEDIA=Monthly2, ID=FFFFDBA9,
> SES=1, RECS=18130)
> 20030701 010047 Session is cleaned. (MEDIA=Monthly2, ID=FFFFDBA9,
> SES=2, RECS=11705)
> 20030701 010048 TAPE Format Successful!
> 20030701 010048 16 Use media Monthly2, ID 2542, sequence #1
> 20030701 010054 Session is cleaned. (MEDIA=Monthly2, ID=FFFFDBA9,
> SES=3, RECS=27896)
> 20030701 010129 16 Source Directory: C:
> 20030701 010129 16 Back up Session 1 on Media Monthly2
> 20030701 010129 16 Backed up volume disk quota.
> 20030701 010154 Session is cleaned. (MEDIA=Monthly2, ID=FFFFDBA9,
> SES=4, RECS=151242)
> 20030701 010154 Session is cleaned. (MEDIA=Monthly2, ID=FFFFDBA9,
> SES=5, RECS=7)
> 20030701 010154 Session is cleaned. (MEDIA=Monthly2, ID=FFFFDBA9,
> SES=6, RECS=12)
> 20030701 010154 Session is cleaned. (MEDIA=Monthly2, ID=FFFFDBA9,
> SES=7, RECS=12)
> 20030701 010154 Session is cleaned. (MEDIA=Monthly2, ID=FFFFDBA9,
> SES=8, RECS=12)
> 20030701 010154 Session is cleaned. (MEDIA=Monthly2, ID=FFFFDBA9,
> SES=9, RECS=12)
> 20030701 010154 Session is cleaned. (MEDIA=Monthly2, ID=FFFFDBA9,
> SES=10, RECS=12)
> 20030701 010154 Session is cleaned. (MEDIA=Monthly2, ID=FFFFDBA9,
> SES=11, RECS=12)
> 20030701 010159 Session is cleaned. (MEDIA=Monthly2, ID=FFFFDBA9,
> SES=12, RECS=13291)
> 20030701 010159 Session is cleaned. (MEDIA=Monthly2, ID=FFFFDBA9,
> SES=13, RECS=225)
> 20030701 010159 Session is cleaned. (MEDIA=Monthly2, ID=FFFFDBA9,
> SES=14, RECS=123)
> 20030701 010159 End cleaning database. (CLEANED=222691)
> 20030701 010233 16 W3404 Unable to open file. (FILE=C:\Documents and
> Settings\All Users\Application
> Data\Microsoft\Network\Downloader\qmgr0.dat, EC=SHARING VIOLATION)
> 20030701 010233 16 W3404 Unable to open file. (FILE=C:\Documents and
> Settings\All Users\Application
> Data\Microsoft\Network\Downloader\qmgr1.dat, EC=SHARING VIOLATION)
> 20030701 010338 16 W3404 Unable to open file. (FILE=C:\Program
> Files\Microsoft SQL Server\MSSQL$MSGPSBM\Data\GPSDYNAMICSDat.mdf,
> EC=SHARING VIOLATION)
> 20030701 010338 16 W3404 Unable to open file. (FILE=C:\Program
> Files\Microsoft SQL Server\MSSQL$MSGPSBM\Data\GPSDYNAMICSLog.ldf,
> EC=SHARING VIOLATION)
> 20030701 010338 16 W3404 Unable to open file. (FILE=C:\Program
> Files\Microsoft SQL Server\MSSQL$MSGPSBM\Data\GPSSBM01Dat.mdf,
> EC=SHARING VIOLATION)
> 20030701 010338 16 W3404 Unable to open file. (FILE=C:\Program
> Files\Microsoft SQL Server\MSSQL$MSGPSBM\Data\GPSSBM01Log.ldf,
> EC=SHARING VIOLATION)
> 20030701 010338 16 W3404 Unable to open file. (FILE=C:\Program
> Files\Microsoft SQL Server\MSSQL$MSGPSBM\Data\GPSTWODat.mdf,
> EC=SHARING VIOLATION)
> 20030701 010338 16 W3404 Unable to open file. (FILE=C:\Program
> Files\Microsoft SQL Server\MSSQL$MSGPSBM\Data\GPSTWOLog.ldf,
> EC=SHARING VIOLATION)
> 20030701 010601 16 Catalog File Backed Up
> 20030701 010601 16 Registry Files Backed Up
> 20030701 010601 16 1,049 Directories 17,088 Files (1,404.55 MB) Backed
> Up to Media.
> 20030701 010601 16 8 Directories/Files Skipped.
> 20030701 010601 16 1,463.31 MB Written to Media.
> 20030701 010601 16 Elapsed Time: 4m 30s
> 20030701 010601 16 Average Throughput: 325.17 MB/min
> 20030701 010601 16 Number of Errors/Warnings: 0/8
> 20030701 010611 16 Source Directory: E:
> 20030701 010611 16 Back up Session 2 on Media Monthly2
> 20030701 010611 16 Backed up volume disk quota.
> 20030701 011115 16 Catalog File Backed Up
> 20030701 011115 16 563 Directories 11,142 Files (1,254.87 MB) Backed
> Up to Media.
> 20030701 011115 16 1,292.68 MB Written to Media.
> 20030701 011115 16 Elapsed Time: 5m 0s
> 20030701 011115 16 Average Throughput: 258.53 MB/min
> 20030701 011201 16 Source Directory: F:
> 20030701 011201 16 Back up Session 3 on Media Monthly2
> 20030701 011201 16 Backed up volume disk quota.
> 20030701 012213 16 Catalog File Backed Up
> 20030701 012213 16 4,665 Directories 23,262 Files (3,229.25 MB) Backed
> Up to Media.
> 20030701 012213 16 3,320.18 MB Written to Media.
> 20030701 012213 16 Elapsed Time: 10m 9s
> 20030701 012213 16 Average Throughput: 327.11 MB/min
> 20030701 012213 16 Source Directory: Registry
> 20030701 012213 16 Back up Session 4 on Media Monthly2
> 20030701 012244 16 Registry Files Backed Up
> 20030701 012244 16 54,946 Directories 96,295 Files (21.42 MB) Backed
> Up to Media.
> 20030701 012244 16 404.87 MB Written to Media.
> 20030701 012244 16 Elapsed Time: 28s
> 20030701 012244 16 Average Throughput: 867.58 MB/min
> 20030701 012244 16 Source Directory: dbaexchis\First Storage Group
> 20030701 012244 16 Back up Session 5 on Media Monthly2
> 20030701 012301 16 1 Databases/Transaction Logs (103.04 MB) Backed Up
> to Media.
> 20030701 012301 16 103.12 MB Written to Media.
> 20030701 012301 16 Elapsed Time: 15s
> 20030701 012301 16 Average Throughput: 412.50 MB/min
> 20030701 012302 16 Source Directory: dbasql@.MSGPSBM\TWO
> 20030701 012302 16 Back up Session 6 on Media Monthly2
> 20030701 012311 16 1 Databases/Transaction Logs (90.07 MB) Backed Up
> to Media.
> 20030701 012311 16 90.18 MB Written to Media.
> 20030701 012311 16 Elapsed Time: 7s
> 20030701 012311 16 Average Throughput: 773.03 MB/min
> 20030701 012311 16 Source Directory: dbasql@.MSGPSBM\SBM01
> 20030701 012311 16 Back up Session 7 on Media Monthly2
> 20030701 012355 16 1 Databases/Transaction Logs (548.07 MB) Backed Up
> to Media.
> 20030701 012355 16 548.37 MB Written to Media.
> 20030701 012355 16 Elapsed Time: 42s
> 20030701 012355 16 Average Throughput: 783.39 MB/min
> 20030701 012355 16 Source Directory: dbasql@.MSGPSBM\msdb
> 20030701 012355 16 Back up Session 8 on Media Monthly2
> 20030701 012357 16 1 Databases/Transaction Logs (2.32 MB) Backed Up to
> Media.
> 20030701 012357 16 2.37 MB Written to Media.
> 20030701 012357 16 Elapsed Time: 1s
> 20030701 012357 16 Average Throughput: 142.50 MB/min
> 20030701 012357 16 Source Directory: dbasql@.MSGPSBM\model
> 20030701 012357 16 Back up Session 9 on Media Monthly2
> 20030701 012400 16 1 Databases/Transaction Logs (721 KB) Backed Up to
> Media.
> 20030701 012400 16 768 KB Written to Media.
> 20030701 012400 16 Elapsed Time: 1s
> 20030701 012400 16 Average Throughput: 45.00 MB/min
> 20030701 012400 16 Source Directory: dbasql@.MSGPSBM\master
> 20030701 012400 16 Back up Session 10 on Media Monthly2
> 20030701 012407 16 1 Databases/Transaction Logs (10.51 MB) Backed Up
> to Media.
> 20030701 012407 16 10.56 MB Written to Media.
> 20030701 012407 16 Elapsed Time: 0s
> 20030701 012407 16 Average Throughput: 633.75 MB/min
> 20030701 012407 16 Source Directory: dbasql@.MSGPSBM\DYNAMICS
> 20030701 012407 16 Back up Session 11 on Media Monthly2
> 20030701 012412 16 1 Databases/Transaction Logs (29.95 MB) Backed Up
> to Media.
> 20030701 012412 16 30.00 MB Written to Media.
> 20030701 012412 16 Elapsed Time: 3s
> 20030701 012412 16 Average Throughput: 600.00 MB/min
> 20030701 012413 16 Source Directory: System State
> 20030701 012413 16 Back up Session 12 on Media Monthly2
> 20030701 012413 16 Backing Up Files : Boot and System Protected Files
> 20030701 012445 16 Backing Up Files : Active Directory
> 20030701 012448 16 Backing Up Files : SysVol
> 20030701 012448 16 Backing Up Files : COM+ Class Registration Database
> 20030701 012448 16 Backing Up Files : Registry
> 20030701 012455 16 Registry Files Backed Up
> 20030701 012455 16 91 Directories 1,963 Files (287.99 MB) Backed Up to
> Media.
> 20030701 012455 16 294.56 MB Written to Media.
> 20030701 012455 16 Elapsed Time: 39s
> 20030701 012455 16 Average Throughput: 453.17 MB/min
> 20030701 012455 16 Source Directory: dbaxchg2
> 20030701 012455 16 Back up Session 13 on Media Monthly2
> 20030701 012516 16 11 Databases/Transaction Logs (40.19 MB) Backed Up
> to Media.
> 20030701 012516 16 40.50 MB Written to Media.
> 20030701 012516 16 Elapsed Time: 19s
> 20030701 012516 16 Average Throughput: 127.89 MB/min
> 20030701 012516 16 ** Summary for My Computer **
> 20030701 012516 16 13 Sessions.
> 20030701 012516 16 61,314 Directories 149,750 Files (6,198.15 MB)
> Backed Up to Media.
> 20030701 012516 16 18 Databases/Transaction Logs (824.89 MB) Backed Up
> to Media.
> 20030701 012516 16 8 Directories/Files Skipped.
> 20030701 012516 16 7,601.50 MB Written to Media.
> 20030701 012516 16 Elapsed Time: 22m 14s
> 20030701 012516 16 Average Throughput: 341.89 MB/min
> 20030701 012516 16 Number of Errors/Warnings: 0/8
> 20030701 012519 16 Backup ARCserve Database...
> 20030701 012520 16 Source Directory: C:\Program
> Files\ComputerAssociates\ARCserve\DATABASE
> 20030701 012520 16 Back up Session 14 on Media Monthly2
> 20030701 012529 16 Catalog File Backed Up
> 20030701 012529 16 1 Directories 118 Files (104.17 MB) Backed Up to
> Media.
> 20030701 012529 16 104.62 MB Written to Media.
> 20030701 012529 16 Elapsed Time: 7s
> 20030701 012529 16 Average Throughput: 896.78 MB/min
> 20030701 012529 16 ARCServe Database Backed Up
> 20030701 012538 [CAT] Monthly2 [ID:2542,SESSION:1] is
> merged.(files=17088)
> 20030701 012542 [CAT] Monthly2 [ID:2542,SESSION:2] is
> merged.(files=11142)
> 20030701 012555 [CAT] Monthly2 [ID:2542,SESSION:3] is
> merged.(files=23262)
> 20030701 012631 16 ** Summary for Job **
> 20030701 012631 16 14 Sessions.
> 20030701 012631 16 61,315 Directories 149,868 Files (6,302.33 MB)
> Backed Up to Media.
> 20030701 012631 16 18 Databases/Transaction Logs (824.89 MB) Backed Up
> to Media.
> 20030701 012631 16 8 Directories/Files Skipped.
> 20030701 012631 16 7,706.12 MB Written to Media.
> 20030701 012631 16 Elapsed Time: 22m 21s
> 20030701 012631 16 Average Throughput: 344.79 MB/min
> 20030701 012631 16 Number of Errors/Warnings: 0/8
> 20030701 012631 16 Backup Operation Incomplete.
> 20030701 012702 [CAT] Monthly2 [ID:2542,SESSION:4] is
> merged.(files=96295)
> 20030701 012702 [CAT] Monthly2 [ID:2542,SESSION:5] is merged.(files=5)
> 20030701 012702 [CAT] Monthly2 [ID:2542,SESSION:6] is merged.(files=3)
> 20030701 012702 [CAT] Monthly2 [ID:2542,SESSION:7] is merged.(files=3)
> 20030701 012702 [CAT] Monthly2 [ID:2542,SESSION:8] is merged.(files=3)
> 20030701 012702 [CAT] Monthly2 [ID:2542,SESSION:9] is merged.(files=3)
> 20030701 012702 [CAT] Monthly2 [ID:2542,SESSION:10] is
> merged.(files=3)
> 20030701 012702 [CAT] Monthly2 [ID:2542,SESSION:11] is
> merged.(files=3)
> 20030701 012708 [CAT] Monthly2 [ID:2542,SESSION:12] is
> merged.(files=1963)
> 20030701 012708 [CAT] Monthly2 [ID:2542,SESSION:13] is
> merged.(files=110)
> 20030701 012708 [CAT] Monthly2 [ID:2542,SESSION:14] is
> merged.(files=118)
> 20030701 012709 16 Reschedule Backup Job for 7/02/03 at 1:00 AM.|||Hello,
Arcserver has an Open File Agent, as do most of these large backup software
products. This is supposed to allow the backing up of files that Andrew
says are always in use. It is my experience that this can be a hit and miss
affair and is one that I am not comfortable with. Yes I have been bitten by
it. I always now backup using SQL Server to a .bak file and have Arcserve.*
back that file up.
Allan Mitchell (Microsoft SQL Server MVP)
MCSE,MCDBA
www.SQLDTS.com
I support PASS - the definitive, global community
for SQL Server professionals - http://www.sqlpass.org
: You can't normally backup the database files with ArcServe since they are
: always in use. I believe they have a way to bypass that but then what
good
: is backing up a file that is constantly changing. You can't restore the
db
: using these backups made from Arcserve since they are not consistent.
What
: you can do is basically one of 2 things. Either use the SQL Server
plug-in
: for ArcServe to have it issue the equivalent of a sql server backup or
don't
: even attempt to backup the database files with Arcserve and have it backup
: the files generated by the SQL Server backup.
-- Microsoft Outlook Express 6.00.2800.1158|||Yes that is what I meant by bypass. Poor choice of word but it will allow
it to backup up the file anyway. That does no one any good since it is in
an inconsistent state database wise.
--
Andrew J. Kelly
SQL Server MVP
"Allan Mitchell" <allan@.no-spam.sqldts.com> wrote in message
news:OK7gauSQDHA.2852@.tk2msftngp13.phx.gbl...
> Hello,
> Arcserver has an Open File Agent, as do most of these large backup
software
> products. This is supposed to allow the backing up of files that Andrew
> says are always in use. It is my experience that this can be a hit and
miss
> affair and is one that I am not comfortable with. Yes I have been bitten
by
> it. I always now backup using SQL Server to a .bak file and have
Arcserve.*
> back that file up.
>
> --
> Allan Mitchell (Microsoft SQL Server MVP)
> MCSE,MCDBA
> www.SQLDTS.com
> I support PASS - the definitive, global community
> for SQL Server professionals - http://www.sqlpass.org
> : You can't normally backup the database files with ArcServe since they
are
> : always in use. I believe they have a way to bypass that but then what
> good
> : is backing up a file that is constantly changing. You can't restore the
> db
> : using these backups made from Arcserve since they are not consistent.
> What
> : you can do is basically one of 2 things. Either use the SQL Server
> plug-in
> : for ArcServe to have it issue the equivalent of a sql server backup or
> don't
> : even attempt to backup the database files with Arcserve and have it
backup
> : the files generated by the SQL Server backup.
> -- Microsoft Outlook Express 6.00.2800.1158
>|||it might behoove you to test the viability of your recovery resources.
"Devin G" <devin@.spamhole.com> wrote in message
news:495ba422.0307031210.57474c7@.posting.google.com...
> From what I think:
> 1) The error messages during the beginning are because Arcserve is
> trying to backup the files on C:. These particular files are skipped
> doe to them being open and in use.
> 2) Later on during the backup I -think- Arcserve is backing up the
> database using the SQL agent which I installed. I can see that in the
> log.
>
> I was just wondering if this looks normal. Has anyone else used
> Arcserve? Is it normal to have the files skipped during the C: but
> then (it looks like) backed up during the SQL agent runs?
> Thanks|||I agree with that assessment but like I said, why bother to have it attempt
to backup those files (in the beginning) if you know they will only fail and
are useless anyway? And as nttp states, it wouldn't be a bad idea to
restore your backups somewhere to see if it's really doing what you hope it
is.
--
Andrew J. Kelly
SQL Server MVP
"Devin G" <devin@.spamhole.com> wrote in message
news:495ba422.0307031210.57474c7@.posting.google.com...
> From what I think:
> 1) The error messages during the beginning are because Arcserve is
> trying to backup the files on C:. These particular files are skipped
> doe to them being open and in use.
> 2) Later on during the backup I -think- Arcserve is backing up the
> database using the SQL agent which I installed. I can see that in the
> log.
>
> I was just wondering if this looks normal. Has anyone else used
> Arcserve? Is it normal to have the files skipped during the C: but
> then (it looks like) backed up during the SQL agent runs?
> Thanks