A differential backup that seems to darn big...

I have a db that is currently about 7 gb. It is currently on a test
instance of SQL 2005. It is not being used by anyone but me for the
purpose of learning one or two things about 2005. Here is what I deem
odd:
If i do a full backup of the database, I get a backup of 7 gb.
If I then IMMEDIATELY do a differential backup, I get a backup of 4.7
gb.
If I then IMMEDIATELY do a differential backup, I get a backup of 4.7
gb.
If I then IMMEDIATELY do a differential backup, I get a backup of 4.7
gb.
I was started to see a pattern. I can guarantee there are no other
users and that I didn't change the database in between backups.
tia,
Steve"Not the Face" <nottheface@.gmail.com> wrote in message
news:1166552868.097104.258360@.73g2000cwn.googlegroups.com...
>I have a db that is currently about 7 gb. It is currently on a test
> instance of SQL 2005. It is not being used by anyone but me for the
> purpose of learning one or two things about 2005. Here is what I deem
> odd:
> If i do a full backup of the database, I get a backup of 7 gb.
> If I then IMMEDIATELY do a differential backup, I get a backup of 4.7
> gb.
> If I then IMMEDIATELY do a differential backup, I get a backup of 4.7
> gb.
> If I then IMMEDIATELY do a differential backup, I get a backup of 4.7
> gb.
>
How large is the transaction log?
I believe it's backing up the entire transaction log PLUS any changes in the
database.
> I was started to see a pattern. I can guarantee there are no other
> users and that I didn't change the database in between backups.
> tia,
> Steve
>|||Sorry about the lag and I appreciate the responses.
The DB is currently ~7.6 gb.
The Transaction Log is currently 5 mb.
I have tried shrinking the DB and Log files (shrinking the whole DB and
each file individually)
This is on a test system, so I have control over the database changing.
It isn't. I was literally doing the differential immediately after
the full backup.
Thanks for your help.
Steve.
Greg D. Moore (Strider) wrote:
> "Not the Face" <nottheface@.gmail.com> wrote in message
> news:1166552868.097104.258360@.73g2000cwn.googlegroups.com...
> >I have a db that is currently about 7 gb. It is currently on a test
> > instance of SQL 2005. It is not being used by anyone but me for the
> > purpose of learning one or two things about 2005. Here is what I deem
> > odd:
> >
> > If i do a full backup of the database, I get a backup of 7 gb.
> > If I then IMMEDIATELY do a differential backup, I get a backup of 4.7
> > gb.
> > If I then IMMEDIATELY do a differential backup, I get a backup of 4.7
> > gb.
> > If I then IMMEDIATELY do a differential backup, I get a backup of 4.7
> > gb.
> >
> How large is the transaction log?
> I believe it's backing up the entire transaction log PLUS any changes in the
> database.
>
> > I was started to see a pattern. I can guarantee there are no other
> > users and that I didn't change the database in between backups.
> >
> > tia,
> > Steve
> >|||Yeah. So here was the problem.
Turns out that if you Shrink the DB and Log files after the backup, it
wants to make a really large differential backup for some reason.
Even though you have *changed* the data at all.
You just *moved* the data around a bit. You know. All of it (most of
it anyway).
Woops. I moved the Shrinks in front of the backup and now my
differential is 1,121 kb. Seems a bit more reasonable.
Thanks for the pointing of the fingers in the right direction.
Steve.
On Jan 17, 10:45 am, John Bell <jbellnewspo...@.hotmail.com> wrote:
> Hi
> 4.7GB does seem large for a differential backup. If you ran the backups as a
> script such as:
> BACKUP DATABASE [AdventureWorks] TO DISK => N'C:\Backups\AdventureworksFull.bak' WITH NOFORMAT, NOINIT, NAME => N'AdventureWorks-Full Database Backup', SKIP, NOREWIND, NOUNLOAD, STATS = 10
> GO
> BACKUP DATABASE [AdventureWorks] TO DISK => N'C:\Backups\AdventureworksDiff1.bak' WITH DIFFERENTIAL , NOFORMAT, NOINIT,
> NAME = N'AdventureWorks-Differential Database Backup', SKIP, NOREWIND,
> NOUNLOAD, STATS = 10
> GO
> BACKUP DATABASE [AdventureWorks] TO DISK => N'C:\Backups\AdventureworksDiff2.bak' WITH DIFFERENTIAL , NOFORMAT, NOINIT,
> NAME = N'AdventureWorks-Differential Database Backup', SKIP, NOREWIND,
> NOUNLOAD, STATS = 10
> GO
> BACKUP DATABASE [AdventureWorks] TO DISK => N'C:\Backups\AdventureworksDiff3.bak' WITH DIFFERENTIAL , NOFORMAT, NOINIT,
> NAME = N'AdventureWorks-Differential Database Backup', SKIP, NOREWIND,
> NOUNLOAD, STATS = 10
> GO
> Then a directory of C:\backups gives
> Directory of C:\Backups
> 17/01/2007 15:18 <DIR> .
> 17/01/2007 15:18 <DIR> ..
> 17/01/2007 15:18 1,133,056 AdventureworksDiff1.bak
> 17/01/2007 15:18 1,133,056 AdventureworksDiff2.bak
> 17/01/2007 15:18 1,133,056 AdventureworksDiff3.bak
> 17/01/2007 15:18 171,002,368 AdventureworksFull.bak
> 4 File(s) 174,401,536 bytes
> 2 Dir(s) 1,241,235,456 bytes free
> This shows what you would expect.
> John
>
> "Not the Face" wrote:
> > Sorry about the lag and I appreciate the responses.
> > The DB is currently ~7.6 gb.
> > The Transaction Log is currently 5 mb.
> > I have tried shrinking the DB and Log files (shrinking the whole DB and
> > each file individually)
> > This is on a test system, so I have control over the database changing.
> > It isn't. I was literally doing the differential immediately after
> > the full backup.
> > Thanks for your help.
> > Steve.
> > Greg D. Moore (Strider) wrote:
> > > "Not the Face" <notthef...@.gmail.com> wrote in message
> > >news:1166552868.097104.258360@.73g2000cwn.googlegroups.com...
> > > >I have a db that is currently about 7 gb. It is currently on a test
> > > > instance of SQL 2005. It is not being used by anyone but me for the
> > > > purpose of learning one or two things about 2005. Here is what I deem
> > > > odd:
> > > > If i do a full backup of the database, I get a backup of 7 gb.
> > > > If I then IMMEDIATELY do a differential backup, I get a backup of 4.7
> > > > gb.
> > > > If I then IMMEDIATELY do a differential backup, I get a backup of 4.7
> > > > gb.
> > > > If I then IMMEDIATELY do a differential backup, I get a backup of 4.7
> > > > gb.
> > > How large is the transaction log?
> > > I believe it's backing up the entire transaction log PLUS any changes in the
> > > database.
> > > > I was started to see a pattern. I can guarantee there are no other
> > > > users and that I didn't change the database in between backups.
> > > > tia,
> > > > Steve- Hide quoted text -- Show quoted text -

A data source instance has not been supplied for the data source

Hi Guys,

I have create a report and it works in development mode. But when I call this report from aspx page it give me above error message. Please let me know how can I setup datasource of this report at runtime. Below is my code

Regards

ReportParameter[] rptPara = new ReportParameter[1];

rptPara[0] = new ReportParameter("rDate", WebDateChooser1.Text, false);

ReportViewer1.LocalReport.ReportPath = @."C:Business\RPT585.rdl";

ReportViewer1.LocalReport.SetParameters(rptPara);

ReportViewer1.LocalReport.Refresh();

Please anybody could let me guide here....

|||

This is how you can provide DataSource information to report at runtime.

Example:

ObjectDataSource objAdventureWorks = new ObjectDataSource("MyData", "GetDataAddress");

objAdventureWorks.ID = "Adventureworks";

this.Controls.Add(objAdventureWorks);

this.ReportViewer.LocalReport.DataSources.Add(new ReportDataSource("AdventureWorks2000", "Adventureworks"));

|||

I have added the datasource of my report but still keep getting this error message. Please let me guide how to fix this error. adn how to set data source instance. Below is my code

ReportParameter[] rptPara = new ReportParameter[1];

rptPara[0] = new ReportParameter("rDate", WebDateChooser1.Text, false);

ReportViewer1.LocalReport.ReportPath = @."C:\business\RPT528.rdl";

ReportViewer1.LocalReport.SetParameters(rptPara);

ReportViewer1.LocalReport.DataSources.Add(new ReportDataSource("dsCustomers"));

ReportViewer1.LocalReport.Refresh();

|||

http://blogs.msdn.com/bimusings/archive/2005/07/01/434659.aspx

I think this article should answer your question. I was experiencing the same error and Russell's work-around fixed it.

TF

A CLR SVF works on my DB instance but not on the other one

Hello,

I have scalar valued function that simply convert a date from UTC to LET by using the .NET functions..

The code is very simple:

PartialPublicClass UserFunction

<Microsoft.SqlServer.Server.SqlFunction(isDeterministic:=True, Name:="ConvertLETDatetoUTC")> _

PublicSharedFunction ConvertLETDatetoUTC(ByVal DateLETFormat As SqlDateTime) As DateTime

' Add your code here

Dim DateLETFormatToConvert AsDate

DateLETFormatToConvert = DateLETFormat.Value

Return DateLETFormatToConvert.ToUniversalTime

EndFunction
End Class

select ConvertLETDatetoUTC('2007-06-25 10:00:00')

Now the problem is that the function works properly on my sql server instanc but in the moment I deploy the same code on the sql server instance on a remote machine the conversion doesn't work that means that date I pass is not converted.

On the SQl server machine there the .net framework 1.1 and 2.0 ...

I really don't know what to check to solve the problem .. some idea?

Thank you

Can you debug the procedure ? I would use something like the Pipe.Send command to send some debbuging information if you are not able to debug the procedure right on the server. Its hard to tell where the problem is based on, so debugging using SQLPipe should be a good alternative for you.

Jens K. Suessmeyer.

http://www.sqlserver2005.de
|||As Jens says, you probably should debuf the function - however I don't believe you can use SqlPipe in the function as it is a UDF. But, are you getting any errors, or is it just the wrong data coming back? If it is wrong data, what collation and default regional settings does the remote server have?

Niels
|||

Hi,

thank you for the reply...

I was able from my development environment to debug and the statement:

DateLETFormatToConvert.ToUniversalTime

doesn't change a comma to my date!!

It is really weird but I don't know which settings (windows or sql server) I should check..

Thankx

Marina

|||Check the Windows settings.

Niels
|||

Hello,

I checked the window settings and I found out that the PC where the SQL server instance that gives me problem, use as Date Time zone: (GMT) Casablanca,Monrovia

while my Date time zome is Amsterdam, Rome...

The DBA told met that all the server in test and production has this setting and it cannot be changed.

Could be this the reason of the difference?

If yes hor an I make my .net code run as it should?

Thank you

Marina B.

|||No, I don't think that's the issue. Do you know what the regional setting for dates etc is, not the actual timezone?

Niels
|||

On both server the Regional and Language Options use the English(United Kingdom) formats and the

sQL collation is:

SQL_Latin1_General_CP1_CI_AS

something to do maybe with the .Net framework installed?

ThankX

Marina B.

A CLR SVF works on my DB instance but not on the other one

Hello,

I have scalar valued function that simply convert a date from UTC to LET by using the .NET functions..

The code is very simple:

Partial Public Class UserFunction

<Microsoft.SqlServer.Server.SqlFunction(isDeterministic:=True, Name:="ConvertLETDatetoUTC")> _

Public Shared Function ConvertLETDatetoUTC(ByVal DateLETFormat As SqlDateTime) As DateTime

' Add your code here

Dim DateLETFormatToConvert As Date

DateLETFormatToConvert = DateLETFormat.Value

Return DateLETFormatToConvert.ToUniversalTime

End Function
End Class

select ConvertLETDatetoUTC('2007-06-25 10:00:00')

Now the problem is that the function works properly on my sql server instanc but in the moment I deploy the same code on the sql server instance on a remote machine the conversion doesn't work that means that date I pass is not converted.

On the SQl server machine there the .net framework 1.1 and 2.0 ...

I really don't know what to check to solve the problem .. some idea?

Thank you

Can you debug the procedure ? I would use something like the Pipe.Send command to send some debbuging information if you are not able to debug the procedure right on the server. Its hard to tell where the problem is based on, so debugging using SQLPipe should be a good alternative for you.

Jens K. Suessmeyer.

http://www.sqlserver2005.de
|||As Jens says, you probably should debuf the function - however I don't believe you can use SqlPipe in the function as it is a UDF. But, are you getting any errors, or is it just the wrong data coming back? If it is wrong data, what collation and default regional settings does the remote server have?

Niels
|||

Hi,

thank you for the reply...

I was able from my development environment to debug and the statement:

DateLETFormatToConvert.ToUniversalTime

doesn't change a comma to my date!!

It is really weird but I don't know which settings (windows or sql server) I should check..

Thankx

Marina

|||Check the Windows settings.

Niels
|||

Hello,

I checked the window settings and I found out that the PC where the SQL server instance that gives me problem, use as Date Time zone: (GMT) Casablanca,Monrovia

while my Date time zome is Amsterdam, Rome...

The DBA told met that all the server in test and production has this setting and it cannot be changed.

Could be this the reason of the difference?

If yes hor an I make my .net code run as it should?

Thank you

Marina B.

|||No, I don't think that's the issue. Do you know what the regional setting for dates etc is, not the actual timezone?

Niels
|||

On both server the Regional and Language Options use the English(United Kingdom) formats and the

sQL collation is:

SQL_Latin1_General_CP1_CI_AS

something to do maybe with the .Net framework installed?

ThankX

Marina B.

8.0 compatibility question

All,
I am upgrading an instance of SQL 2000 to SQL 2005.
Two of my applications have databases in this instance. According to their
vendors, these two applications are not compatible with SQL 2005.
However, these databases, although running in SQL Server 2005, are using 8.0
compatibility mode. I learned that databases stay in their original
compatibility mode when upgraded to 2005.
So my question is - if these databases remain in 8.0 compatibility mode
after an upgrade, doesn't that mean they will still work as if they were
running on SQL 2000 once I upgrade to 2005? And doesn't that mean they WON'T
break, which would save me the torture of porting them to a separate named
2000 instance and maintaining that instance?
Please, if anyone has any insight on this, let me know."Ant-nee" <Antnee@.discussions.microsoft.com> wrote in message
news:51F67FB1-BF4D-46F0-B6FB-31DEF7EEDF86@.microsoft.com...
> All,
> I am upgrading an instance of SQL 2000 to SQL 2005.
> Two of my applications have databases in this instance. According to
> their
> vendors, these two applications are not compatible with SQL 2005.
> However, these databases, although running in SQL Server 2005, are using
> 8.0
> compatibility mode. I learned that databases stay in their original
> compatibility mode when upgraded to 2005.
> So my question is - if these databases remain in 8.0 compatibility mode
> after an upgrade, doesn't that mean they will still work as if they were
> running on SQL 2000 once I upgrade to 2005? And doesn't that mean they
> WON'T
> break, which would save me the torture of porting them to a separate named
> 2000 instance and maintaining that instance?
>
8.0 Compatibility Mode is designed to minimize upgrade problems with SQL
2000 applications, running them in an environment as similar to SQL 2000 as
possible. However you still need to work with your application vendor to
make sure that they support your configuration.
David|||Unfortunately no. When you upgrade to 2005 the database structure is
changed. The 8.0 compatibility mode just turns off some of the new
features - it doesn't leave the database in SQL 2000 format.
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"Ant-nee" <Antnee@.discussions.microsoft.com> wrote in message
news:51F67FB1-BF4D-46F0-B6FB-31DEF7EEDF86@.microsoft.com...
> All,
> I am upgrading an instance of SQL 2000 to SQL 2005.
> Two of my applications have databases in this instance. According to
> their
> vendors, these two applications are not compatible with SQL 2005.
> However, these databases, although running in SQL Server 2005, are using
> 8.0
> compatibility mode. I learned that databases stay in their original
> compatibility mode when upgraded to 2005.
> So my question is - if these databases remain in 8.0 compatibility mode
> after an upgrade, doesn't that mean they will still work as if they were
> running on SQL 2000 once I upgrade to 2005? And doesn't that mean they
> WON'T
> break, which would save me the torture of porting them to a separate named
> 2000 instance and maintaining that instance?
> Please, if anyone has any insight on this, let me know.

8.0 compatibility question

All,
I am upgrading an instance of SQL 2000 to SQL 2005.
Two of my applications have databases in this instance. According to their
vendors, these two applications are not compatible with SQL 2005.
However, these databases, although running in SQL Server 2005, are using 8.0
compatibility mode. I learned that databases stay in their original
compatibility mode when upgraded to 2005.
So my question is - if these databases remain in 8.0 compatibility mode
after an upgrade, doesn't that mean they will still work as if they were
running on SQL 2000 once I upgrade to 2005? And doesn't that mean they WON'T
break, which would save me the torture of porting them to a separate named
2000 instance and maintaining that instance?
Please, if anyone has any insight on this, let me know.
"Ant-nee" <Antnee@.discussions.microsoft.com> wrote in message
news:51F67FB1-BF4D-46F0-B6FB-31DEF7EEDF86@.microsoft.com...
> All,
> I am upgrading an instance of SQL 2000 to SQL 2005.
> Two of my applications have databases in this instance. According to
> their
> vendors, these two applications are not compatible with SQL 2005.
> However, these databases, although running in SQL Server 2005, are using
> 8.0
> compatibility mode. I learned that databases stay in their original
> compatibility mode when upgraded to 2005.
> So my question is - if these databases remain in 8.0 compatibility mode
> after an upgrade, doesn't that mean they will still work as if they were
> running on SQL 2000 once I upgrade to 2005? And doesn't that mean they
> WON'T
> break, which would save me the torture of porting them to a separate named
> 2000 instance and maintaining that instance?
>
8.0 Compatibility Mode is designed to minimize upgrade problems with SQL
2000 applications, running them in an environment as similar to SQL 2000 as
possible. However you still need to work with your application vendor to
make sure that they support your configuration.
David
|||Unfortunately no. When you upgrade to 2005 the database structure is
changed. The 8.0 compatibility mode just turns off some of the new
features - it doesn't leave the database in SQL 2000 format.
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"Ant-nee" <Antnee@.discussions.microsoft.com> wrote in message
news:51F67FB1-BF4D-46F0-B6FB-31DEF7EEDF86@.microsoft.com...
> All,
> I am upgrading an instance of SQL 2000 to SQL 2005.
> Two of my applications have databases in this instance. According to
> their
> vendors, these two applications are not compatible with SQL 2005.
> However, these databases, although running in SQL Server 2005, are using
> 8.0
> compatibility mode. I learned that databases stay in their original
> compatibility mode when upgraded to 2005.
> So my question is - if these databases remain in 8.0 compatibility mode
> after an upgrade, doesn't that mean they will still work as if they were
> running on SQL 2000 once I upgrade to 2005? And doesn't that mean they
> WON'T
> break, which would save me the torture of porting them to a separate named
> 2000 instance and maintaining that instance?
> Please, if anyone has any insight on this, let me know.

8.0 compatibility question

All,
I am upgrading an instance of SQL 2000 to SQL 2005.
Two of my applications have databases in this instance. According to their
vendors, these two applications are not compatible with SQL 2005.
However, these databases, although running in SQL Server 2005, are using 8.0
compatibility mode. I learned that databases stay in their original
compatibility mode when upgraded to 2005.
So my question is - if these databases remain in 8.0 compatibility mode
after an upgrade, doesn't that mean they will still work as if they were
running on SQL 2000 once I upgrade to 2005? And doesn't that mean they WON'
T
break, which would save me the torture of porting them to a separate named
2000 instance and maintaining that instance?
Please, if anyone has any insight on this, let me know."Ant-nee" <Antnee@.discussions.microsoft.com> wrote in message
news:51F67FB1-BF4D-46F0-B6FB-31DEF7EEDF86@.microsoft.com...
> All,
> I am upgrading an instance of SQL 2000 to SQL 2005.
> Two of my applications have databases in this instance. According to
> their
> vendors, these two applications are not compatible with SQL 2005.
> However, these databases, although running in SQL Server 2005, are using
> 8.0
> compatibility mode. I learned that databases stay in their original
> compatibility mode when upgraded to 2005.
> So my question is - if these databases remain in 8.0 compatibility mode
> after an upgrade, doesn't that mean they will still work as if they were
> running on SQL 2000 once I upgrade to 2005? And doesn't that mean they
> WON'T
> break, which would save me the torture of porting them to a separate named
> 2000 instance and maintaining that instance?
>
8.0 Compatibility Mode is designed to minimize upgrade problems with SQL
2000 applications, running them in an environment as similar to SQL 2000 as
possible. However you still need to work with your application vendor to
make sure that they support your configuration.
David|||Unfortunately no. When you upgrade to 2005 the database structure is
changed. The 8.0 compatibility mode just turns off some of the new
features - it doesn't leave the database in SQL 2000 format.
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"Ant-nee" <Antnee@.discussions.microsoft.com> wrote in message
news:51F67FB1-BF4D-46F0-B6FB-31DEF7EEDF86@.microsoft.com...
> All,
> I am upgrading an instance of SQL 2000 to SQL 2005.
> Two of my applications have databases in this instance. According to
> their
> vendors, these two applications are not compatible with SQL 2005.
> However, these databases, although running in SQL Server 2005, are using
> 8.0
> compatibility mode. I learned that databases stay in their original
> compatibility mode when upgraded to 2005.
> So my question is - if these databases remain in 8.0 compatibility mode
> after an upgrade, doesn't that mean they will still work as if they were
> running on SQL 2000 once I upgrade to 2005? And doesn't that mean they
> WON'T
> break, which would save me the torture of porting them to a separate named
> 2000 instance and maintaining that instance?
> Please, if anyone has any insight on this, let me know.

7619 error message when you run a full text query that contains certain Turkish character

I receive a 7619 error message when I run a full text query that
contains certain Turkish character strings on an instance of SQL Server
2000 that is running on a Windows 2000-based computer. How can I solve
this problem?
The parser is interpreting these characters as noise or noise words. Which
word breaker are you using? I am assuming you are using the neutral word
breaker.
If this is the case the problem could be in your code page setting in the
web page. You should set the session.codepage to match the lcid for Turkish.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Ismail H. AYDIN" <dicisay@.hotmail.com> wrote in message
news:1117203863.089340.322710@.g49g2000cwa.googlegr oups.com...
>I receive a 7619 error message when I run a full text query that
> contains certain Turkish character strings on an instance of SQL Server
> 2000 that is running on a Windows 2000-based computer. How can I solve
> this problem?
>
|||I am running the query from SQL Query Analyzer and then error occurs.
Not from asp.net or asp page. The noise word is 'Ak'. And the other
noise charactes are '', '', ''.
*** Sent via Developersdex http://www.codecomments.com ***

7.0 and 2000 .BAK incompatibility?

i just got a disk w/ a .bak file on it. when i tried to restore it on
my 2000 sql server instance it said the format was invalid. so, would i
get this error if the .bak version was created using version 7.0?
thanks,
arthur
Arthur,
7 --> 2000 shouldn't be a problem. Try using the HEADERONLY and
FILELISTONLY arguments of the RESTORE statement for the backup.
HTH
Jerry
"arthur" <alangham@.gmail.com> wrote in message
news:1129679111.225814.302070@.g14g2000cwa.googlegr oups.com...
>i just got a disk w/ a .bak file on it. when i tried to restore it on
> my 2000 sql server instance it said the format was invalid. so, would i
> get this error if the .bak version was created using version 7.0?
> thanks,
> arthur
>
|||the specific error i'm getting is RESTORE HEADERONLY is terminating
abnormally. i have no idea what the filelists are in the file. i'm
going to get w/ the peeps that made this file and see what's up. thanks.
|||Hi,
Then try using RESTORE FILELISTONLY OR use Enterprise manager -- All
tasks -- Restore
Filelistonly usage:-
Restore filelistonly from DISK='C:\Backup\backupfile.bak'
Thanks
Hari
SQL Server MVP
"arthur" <alangham@.gmail.com> wrote in message
news:1129680445.762037.102890@.g47g2000cwa.googlegr oups.com...
> the specific error i'm getting is RESTORE HEADERONLY is terminating
> abnormally. i have no idea what the filelists are in the file. i'm
> going to get w/ the peeps that made this file and see what's up. thanks.
>
|||Are you certain this is indeed a SQL Server backup file? It could just have been created with a beta
of SQL Server 7.0, but I think that SQL Server 2000 would give a more descriptive error message.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"arthur" <alangham@.gmail.com> wrote in message
news:1129680445.762037.102890@.g47g2000cwa.googlegr oups.com...
> the specific error i'm getting is RESTORE HEADERONLY is terminating
> abnormally. i have no idea what the filelists are in the file. i'm
> going to get w/ the peeps that made this file and see what's up. thanks.
>

7.0 and 2000 .BAK incompatibility?

i just got a disk w/ a .bak file on it. when i tried to restore it on
my 2000 sql server instance it said the format was invalid. so, would i
get this error if the .bak version was created using version 7.0?
thanks,
arthurArthur,
7 --> 2000 shouldn't be a problem. Try using the HEADERONLY and
FILELISTONLY arguments of the RESTORE statement for the backup.
HTH
Jerry
"arthur" <alangham@.gmail.com> wrote in message
news:1129679111.225814.302070@.g14g2000cwa.googlegroups.com...
>i just got a disk w/ a .bak file on it. when i tried to restore it on
> my 2000 sql server instance it said the format was invalid. so, would i
> get this error if the .bak version was created using version 7.0?
> thanks,
> arthur
>|||the specific error i'm getting is RESTORE HEADERONLY is terminating
abnormally. i have no idea what the filelists are in the file. i'm
going to get w/ the peeps that made this file and see what's up. thanks.|||Hi,
Then try using RESTORE FILELISTONLY OR use Enterprise manager -- All
tasks -- Restore
Filelistonly usage:-
Restore filelistonly from DISK='C:\Backup\backupfile.bak'
Thanks
Hari
SQL Server MVP
"arthur" <alangham@.gmail.com> wrote in message
news:1129680445.762037.102890@.g47g2000cwa.googlegroups.com...
> the specific error i'm getting is RESTORE HEADERONLY is terminating
> abnormally. i have no idea what the filelists are in the file. i'm
> going to get w/ the peeps that made this file and see what's up. thanks.
>|||Are you certain this is indeed a SQL Server backup file? It could just have
been created with a beta
of SQL Server 7.0, but I think that SQL Server 2000 would give a more descri
ptive error message.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"arthur" <alangham@.gmail.com> wrote in message
news:1129680445.762037.102890@.g47g2000cwa.googlegroups.com...
> the specific error i'm getting is RESTORE HEADERONLY is terminating
> abnormally. i have no idea what the filelists are in the file. i'm
> going to get w/ the peeps that made this file and see what's up. thanks.
>

7.0 and 2000 .BAK incompatibility?

i just got a disk w/ a .bak file on it. when i tried to restore it on
my 2000 sql server instance it said the format was invalid. so, would i
get this error if the .bak version was created using version 7.0?
thanks,
arthurArthur,
7 --> 2000 shouldn't be a problem. Try using the HEADERONLY and
FILELISTONLY arguments of the RESTORE statement for the backup.
HTH
Jerry
"arthur" <alangham@.gmail.com> wrote in message
news:1129679111.225814.302070@.g14g2000cwa.googlegroups.com...
>i just got a disk w/ a .bak file on it. when i tried to restore it on
> my 2000 sql server instance it said the format was invalid. so, would i
> get this error if the .bak version was created using version 7.0?
> thanks,
> arthur
>|||the specific error i'm getting is RESTORE HEADERONLY is terminating
abnormally. i have no idea what the filelists are in the file. i'm
going to get w/ the peeps that made this file and see what's up. thanks.|||Hi,
Then try using RESTORE FILELISTONLY OR use Enterprise manager -- All
tasks -- Restore
Filelistonly usage:-
Restore filelistonly from DISK='C:\Backup\backupfile.bak'
Thanks
Hari
SQL Server MVP
"arthur" <alangham@.gmail.com> wrote in message
news:1129680445.762037.102890@.g47g2000cwa.googlegroups.com...
> the specific error i'm getting is RESTORE HEADERONLY is terminating
> abnormally. i have no idea what the filelists are in the file. i'm
> going to get w/ the peeps that made this file and see what's up. thanks.
>|||Are you certain this is indeed a SQL Server backup file? It could just have been created with a beta
of SQL Server 7.0, but I think that SQL Server 2000 would give a more descriptive error message.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"arthur" <alangham@.gmail.com> wrote in message
news:1129680445.762037.102890@.g47g2000cwa.googlegroups.com...
> the specific error i'm getting is RESTORE HEADERONLY is terminating
> abnormally. i have no idea what the filelists are in the file. i'm
> going to get w/ the peeps that made this file and see what's up. thanks.
>

64-bit Server (clustered) 128 GB ram - 155 GB used

It seems the Server itself shows 155GB used, even though one Instance has 91 GB limit and the other 31 GB limit?

The server only has 128 GB of RAM with a 30+ GB Virtual Swap File.

What do I check to see if there is a problem? What perfmon do I use?

We are testing on this server and the CPUs are only at 5-10% max. Some testing brought the CPUs to 80-90%.

There are no errors.

Thanks,

Thomas

If you have two instances on one server, they will use all the memory up to the Max memory limit that you set for SQL Server in each instance.

You also need to make sure that you have given the "Lock Pages in Memory" right to the SQL Server service account. My blog post has more details:

http://glennberrysqlperformance.spaces.live.com/blog/cns!45041418ECCAA960!115.entry

If you are concerned about memory pressure, buffer cache hit ratio and page life expectancy, and memory grants pending are three places to start looking.

|||

Where are you getting the 155GB value from? Can you try DBCC memorystatus on both instances and paste the results?

Thanks, Ron D.

64-bit Server (clustered) 128 GB ram - 155 GB used

It seems the Server itself shows 155GB used, even though one Instance has 91 GB limit and the other 31 GB limit?

The server only has 128 GB of RAM with a 30+ GB Virtual Swap File.

What do I check to see if there is a problem? What perfmon do I use?

We are testing on this server and the CPUs are only at 5-10% max. Some testing brought the CPUs to 80-90%.

There are no errors.

Thanks,

Thomas

If you have two instances on one server, they will use all the memory up to the Max memory limit that you set for SQL Server in each instance.

You also need to make sure that you have given the "Lock Pages in Memory" right to the SQL Server service account. My blog post has more details:

http://glennberrysqlperformance.spaces.live.com/blog/cns!45041418ECCAA960!115.entry

If you are concerned about memory pressure, buffer cache hit ratio and page life expectancy, and memory grants pending are three places to start looking.

|||

Where are you getting the 155GB value from? Can you try DBCC memorystatus on both instances and paste the results?

Thanks, Ron D.

64-Bit Connectivity Issues

We are migrating from a botched 64-bit SQL Server setup to a new 64-bit SQL Server Setup (One instance versus 2). Things that worked on the first server, don't work on the new. My speculation is that the AS400 drivers installation is botched, but asking for feedback.

Am running a scheduled job that simply executes an SSIS package. There is a package configuration for the connection strings to AS400 and SQL Server. The package runs fine when you run it from DTEXECUI (obviously adding configuration file to run). The job is setup exactly the same as on the original server but gets the following errors:

Side question: Why does the job history errors conflict with the SQL Server logging from the package? Very frustrating.

Job History Error (I found these to be very inaccurate in the past):

Executed as user: bfusa\mfgsql. ...rsion 9.00.3042.00 for 64-bit Copyright (C) Microsoft Corp 1984-2005. All rights reserved. Started: 9:45:06 AM Error: 2007-04-11 09:45:06.76 Code: 0xC0016016 Source: Description: Failed to decrypt protected XML node "DTSassword" with error 0x80070002 "The system cannot find the file specified.". You may not be authorized to access this information. This error occurs when there is a cryptographic error. Verify that the correct key is available. End Error Error: 2007-04-11 09:45:06.78 Code: 0xC0016016 Source: Description: Failed to decrypt protected XML node "DTSassword" with error 0x80070002 "The system cannot find the file specified.". You may not be authorized to access this information. This error occurs when there is a cryptographic error. Verify that the correct key is available. End Error Progress: 2007-04-11 09:45:16.34 Source: DFT_PESGRVSL Validating: 0% complete En... The package execution fa... The step failed.

SQL Server Package Logging:

System.InvalidOperationException: The 'IBMDA400.DataSource.1' provider is not registered on the local machine.

BTW, I tried using a cmdexec step to force it run in 32-bit mode, and still received errors. If it is in fact a driver error, why does it run fine in DTEXECUI? I know that always runs in 32-bit mode, but I tried to force a 32-bit mode also.

This might not be the answer but for that error "The system cannot find the file specified." on 64-bit I've opened the package, recompiled all my scripts, saved and ran again and it fixed it. This seems to happen less often in SP2 (or at least in SP2 you will get a warning in 32-bit mode that it is missing a binary for a script).

Based on the rest of your error message its probably not the correct answer but it can't hurt

|||

Two issues here.

1. 32 bit vs. 64 bit package execution

The job history pasted in the message shows that the job is /was running under 64 bit. But even when that is fixed to run under 32 bit (as you apparently did in a cmdexec step) , the execution would still not initiate because of the Package Protection level property setting, which is the second issue. As to the 32 vs 64 bit package execution via dtexec, here's what is displayed when running the two versions of dtexec.exe on the x64 platform (and you can see that the job history shows a 64 bit execution attempt).

"%ProgramFiles(x86)%\Microsoft SQL Server\90\DTS\Binn\dtexec.exe"
Microsoft (R) SQL Server Execute Package Utility
Version 9.00.3042.00 for 32-bit
Copyright (C) Microsoft Corp 1984-2005. All rights reserved.

At least one of the DTS, SQL, or File options must be specified.

"%ProgramFiles%\Microsoft SQL Server\90\DTS\Binn\dtexec.exe"
Microsoft (R) SQL Server Execute Package Utility
Version 9.00.3042.00 for 64-bit
Copyright (C) Microsoft Corp 1984-2005. All rights reserved.

At least one of the DTS, SQL, or File options must be specified.

That history shows it is running under 64 bit.

2. Package protection level

Even though you modified it to run in 32 bit mode, there are still errors. These have nothing to do with that platform, but rather, the PackageProtectionLevel. This issue is discussed ( with resolutions) in the following article: http://support.microsoft.com/kb/918760

|||A reinstallation of the DB2 drivers was done and this fixed the issue.

64-Bit Connectivity Issues

We are migrating from a botched 64-bit SQL Server setup to a new 64-bit SQL Server Setup (One instance versus 2). Things that worked on the first server, don't work on the new. My speculation is that the AS400 drivers installation is botched, but asking for feedback.

Am running a scheduled job that simply executes an SSIS package. There is a package configuration for the connection strings to AS400 and SQL Server. The package runs fine when you run it from DTEXECUI (obviously adding configuration file to run). The job is setup exactly the same as on the original server but gets the following errors:

Side question: Why does the job history errors conflict with the SQL Server logging from the package? Very frustrating.

Job History Error (I found these to be very inaccurate in the past):

Executed as user: bfusa\mfgsql. ...rsion 9.00.3042.00 for 64-bit Copyright (C) Microsoft Corp 1984-2005. All rights reserved. Started: 9:45:06 AM Error: 2007-04-11 09:45:06.76 Code: 0xC0016016 Source: Description: Failed to decrypt protected XML node "DTSassword" with error 0x80070002 "The system cannot find the file specified.". You may not be authorized to access this information. This error occurs when there is a cryptographic error. Verify that the correct key is available. End Error Error: 2007-04-11 09:45:06.78 Code: 0xC0016016 Source: Description: Failed to decrypt protected XML node "DTSassword" with error 0x80070002 "The system cannot find the file specified.". You may not be authorized to access this information. This error occurs when there is a cryptographic error. Verify that the correct key is available. End Error Progress: 2007-04-11 09:45:16.34 Source: DFT_PESGRVSL Validating: 0% complete En... The package execution fa... The step failed.

SQL Server Package Logging:

System.InvalidOperationException: The 'IBMDA400.DataSource.1' provider is not registered on the local machine.

BTW, I tried using a cmdexec step to force it run in 32-bit mode, and still received errors. If it is in fact a driver error, why does it run fine in DTEXECUI? I know that always runs in 32-bit mode, but I tried to force a 32-bit mode also.

This might not be the answer but for that error "The system cannot find the file specified." on 64-bit I've opened the package, recompiled all my scripts, saved and ran again and it fixed it. This seems to happen less often in SP2 (or at least in SP2 you will get a warning in 32-bit mode that it is missing a binary for a script).

Based on the rest of your error message its probably not the correct answer but it can't hurt

|||

Two issues here.

1. 32 bit vs. 64 bit package execution

The job history pasted in the message shows that the job is /was running under 64 bit. But even when that is fixed to run under 32 bit (as you apparently did in a cmdexec step) , the execution would still not initiate because of the Package Protection level property setting, which is the second issue. As to the 32 vs 64 bit package execution via dtexec, here's what is displayed when running the two versions of dtexec.exe on the x64 platform (and you can see that the job history shows a 64 bit execution attempt).

"%ProgramFiles(x86)%\Microsoft SQL Server\90\DTS\Binn\dtexec.exe"
Microsoft (R) SQL Server Execute Package Utility
Version 9.00.3042.00 for 32-bit
Copyright (C) Microsoft Corp 1984-2005. All rights reserved.

At least one of the DTS, SQL, or File options must be specified.

"%ProgramFiles%\Microsoft SQL Server\90\DTS\Binn\dtexec.exe"
Microsoft (R) SQL Server Execute Package Utility
Version 9.00.3042.00 for 64-bit
Copyright (C) Microsoft Corp 1984-2005. All rights reserved.

At least one of the DTS, SQL, or File options must be specified.

That history shows it is running under 64 bit.

2. Package protection level

Even though you modified it to run in 32 bit mode, there are still errors. These have nothing to do with that platform, but rather, the PackageProtectionLevel. This issue is discussed ( with resolutions) in the following article: http://support.microsoft.com/kb/918760

|||A reinstallation of the DB2 drivers was done and this fixed the issue.

64 bit memory and AWE ?

Hi There

I have installed 64 bit Standard Edition SS 2005 on a 64 bit WOndows Server 2003 R2 platform.

When i go to Memory setting for this instance i set max server memory to 6 Gig.

I am presuming i do not have to enable AWE, sicne everything is 64 bit.

Is this correct ?

Thanx

AWE is used for 32-bit OS due to 32-bit system can only address 4GB memory in conventual way, so it need to set /PAE in boot.ini file and set AWE enabled in SQL server.

but for 64-bit OS and SQL server (both 2000 and 2005) do not need to set this option.

64 bit memory and AWE ?

Hi There

I have installed 64 bit Standard Edition SS 2005 on a 64 bit WOndows Server 2003 R2 platform.

When i go to Memory setting for this instance i set max server memory to 6 Gig.

I am presuming i do not have to enable AWE, sicne everything is 64 bit.

Is this correct ?

Thanx

AWE is used for 32-bit OS due to 32-bit system can only address 4GB memory in conventual way, so it need to set /PAE in boot.ini file and set AWE enabled in SQL server.

but for 64-bit OS and SQL server (both 2000 and 2005) do not need to set this option.