curious phenomenon when differential backup

Hello,
when i backup my database on one day in week with a full backup and the
other day with a differential backup (for example: full on sunday, all
other days differential) i think the differential archive from friday
should be bigger than the differential archive from tuesday(when noting
is erased and only datas where changed). but it isnt.
what can be happend?
for example the differential backup from tuesday is nearly 2 GB and the
differential archive is nearly 400 MB. Fullbackup only made on Sunday
and there is no other backup running on the system.
thx for every ideaWhat you describe sounds impossible, from a theoretical standpoint. I would start checking the
backup* history tables in the msdb to be absolutely 100% certain that a database backup haven't been
performed in between.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Werner Stiglbrunner" <werner_stiglbrunner@.at.ibm.com> wrote in message
news:ua4tXt82GHA.1292@.TK2MSFTNGP03.phx.gbl...
> Hello,
> when i backup my database on one day in week with a full backup and the other day with a
> differential backup (for example: full on sunday, all other days differential) i think the
> differential archive from friday should be bigger than the differential archive from tuesday(when
> noting is erased and only datas where changed). but it isnt.
> what can be happend?
> for example the differential backup from tuesday is nearly 2 GB and the differential archive is
> nearly 400 MB. Fullbackup only made on Sunday and there is no other backup running on the system.
> thx for every idea|||Tibor Karaszi schrieb:
> What you describe sounds impossible, from a theoretical standpoint. I would start checking the
> backup* history tables in the msdb to be absolutely 100% certain that a database backup haven't been
> performed in between.
>
your right i also think that this is impossible.
i will research this situation on the next days and hope that i find a
"simple" declaration.

curious phenomenon when differential backup

Hello,
when i backup my database on one day in week with a full backup and the
other day with a differential backup (for example: full on sunday, all
other days differential) i think the differential archive from friday
should be bigger than the differential archive from tuesday(when noting
is erased and only datas where changed). but it isnt.
what can be happend?
for example the differential backup from tuesday is nearly 2 GB and the
differential archive is nearly 400 MB. Fullbackup only made on Sunday
and there is no other backup running on the system.
thx for every idea
What you describe sounds impossible, from a theoretical standpoint. I would start checking the
backup* history tables in the msdb to be absolutely 100% certain that a database backup haven't been
performed in between.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Werner Stiglbrunner" <werner_stiglbrunner@.at.ibm.com> wrote in message
news:ua4tXt82GHA.1292@.TK2MSFTNGP03.phx.gbl...
> Hello,
> when i backup my database on one day in week with a full backup and the other day with a
> differential backup (for example: full on sunday, all other days differential) i think the
> differential archive from friday should be bigger than the differential archive from tuesday(when
> noting is erased and only datas where changed). but it isnt.
> what can be happend?
> for example the differential backup from tuesday is nearly 2 GB and the differential archive is
> nearly 400 MB. Fullbackup only made on Sunday and there is no other backup running on the system.
> thx for every idea
|||Tibor Karaszi schrieb:
> What you describe sounds impossible, from a theoretical standpoint. I would start checking the
> backup* history tables in the msdb to be absolutely 100% certain that a database backup haven't been
> performed in between.
>
your right i also think that this is impossible.
i will research this situation on the next days and hope that i find a
"simple" declaration.

curious phenomenon when differential backup

Hello,
when i backup my database on one day in week with a full backup and the
other day with a differential backup (for example: full on sunday, all
other days differential) i think the differential archive from friday
should be bigger than the differential archive from tuesday(when noting
is erased and only datas where changed). but it isnt.
what can be happend?
for example the differential backup from tuesday is nearly 2 GB and the
differential archive is nearly 400 MB. Fullbackup only made on Sunday
and there is no other backup running on the system.
thx for every ideaWhat you describe sounds impossible, from a theoretical standpoint. I would
start checking the
backup* history tables in the msdb to be absolutely 100% certain that a data
base backup haven't been
performed in between.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Werner Stiglbrunner" <werner_stiglbrunner@.at.ibm.com> wrote in message
news:ua4tXt82GHA.1292@.TK2MSFTNGP03.phx.gbl...
> Hello,
> when i backup my database on one day in week with a full backup and the ot
her day with a
> differential backup (for example: full on sunday, all other days different
ial) i think the
> differential archive from friday should be bigger than the differential ar
chive from tuesday(when
> noting is erased and only datas where changed). but it isnt.
> what can be happend?
> for example the differential backup from tuesday is nearly 2 GB and the di
fferential archive is
> nearly 400 MB. Fullbackup only made on Sunday and there is no other backup
running on the system.
> thx for every idea|||Tibor Karaszi schrieb:
> What you describe sounds impossible, from a theoretical standpoint. I woul
d start checking the
> backup* history tables in the msdb to be absolutely 100% certain that a da
tabase backup haven't been
> performed in between.
>
your right i also think that this is impossible.
i will research this situation on the next days and hope that i find a
"simple" declaration.

Cube backup job failed

Message
Executed as user: INTRANET\SSAgentTrendP1. ...ystem error: The following error occurred while the '\\?\H:\MSSQLDATA\TrendP1\Trend.0.db\Trend.0.cub\Claim Summary V.0.det\Claim Summary V.0.prt\8.fact.data' file was being copied to the 'G:\MSSQLDATA\TrendP1\Auto_before.abf' file: . at Microsoft.AnalysisServices.Xmla.XmlaClient.CheckForSoapFault(XmlReader reader, XmlaResult xmlaResult, Boolean throwIfError) at Microsoft.AnalysisServices.Xmla.XmlaClient.CheckForError(XmlReader reader, XmlaResult xmlaResult, Boolean throwIfError) at Microsoft.AnalysisServices.Xmla.XmlaClient.SendMessage(Boolean endReceivalIfException, Boolean readSession, Boolean readNamespaceCompatibility) at Microsoft.AnalysisServices.Xmla.XmlaClient.SendMessageAndReturnResult(String& result, Boolean skipResult) at Microsoft.AnalysisServices.Xmla.XmlaClient.Execute(String command, String properties, String& result, Boolean skipResult, Boolean propertiesXmlIsComplete) at Microsoft.SqlServer.Management.Smo.Olap.Soap. The step failed.

This is the job step definition:

<Backup xmlns="http://schemas.microsoft.com/analysisservices/2003/engine">
<Object>
<DatabaseID>Trend</DatabaseID>
</Object>
<File>G:\MSSQLDATA\TrendP1\Auto_before.abf</File>
<AllowOverwrite>true</AllowOverwrite>
<ApplyCompression>false</ApplyCompression>
</Backup>

This job has been running for a while. The problem started after I did a restore of the cube at one point of time.

|||

Further investigation reveals that one of the fact.data file had growed to 4G in size and the backup started to fail.

Is there a size limitation of individual partition's size in SQL Server 2005 OLAP serivice? I have searched the BOL but can't find any reference.

Thanks,

|||

according to MS it has been removed from 2 g from SSAS 2000 to no limit in SSAS 2005!! but facing same error message while backing up!!

Cube backup job failed

Message
Executed as user: INTRANET\SSAgentTrendP1. ...ystem error: The following error occurred while the '\\?\H:\MSSQLDATA\TrendP1\Trend.0.db\Trend.0.cub\Claim Summary V.0.det\Claim Summary V.0.prt\8.fact.data' file was being copied to the 'G:\MSSQLDATA\TrendP1\Auto_before.abf' file: . at Microsoft.AnalysisServices.Xmla.XmlaClient.CheckForSoapFault(XmlReader reader, XmlaResult xmlaResult, Boolean throwIfError) at Microsoft.AnalysisServices.Xmla.XmlaClient.CheckForError(XmlReader reader, XmlaResult xmlaResult, Boolean throwIfError) at Microsoft.AnalysisServices.Xmla.XmlaClient.SendMessage(Boolean endReceivalIfException, Boolean readSession, Boolean readNamespaceCompatibility) at Microsoft.AnalysisServices.Xmla.XmlaClient.SendMessageAndReturnResult(String& result, Boolean skipResult) at Microsoft.AnalysisServices.Xmla.XmlaClient.Execute(String command, String properties, String& result, Boolean skipResult, Boolean propertiesXmlIsComplete) at Microsoft.SqlServer.Management.Smo.Olap.Soap. The step failed.

This is the job step definition:

<Backup xmlns="http://schemas.microsoft.com/analysisservices/2003/engine">
<Object>
<DatabaseID>Trend</DatabaseID>
</Object>
<File>G:\MSSQLDATA\TrendP1\Auto_before.abf</File>
<AllowOverwrite>true</AllowOverwrite>
<ApplyCompression>false</ApplyCompression>
</Backup>

This job has been running for a while. The problem started after I did a restore of the cube at one point of time.

|||

Further investigation reveals that one of the fact.data file had growed to 4G in size and the backup started to fail.

Is there a size limitation of individual partition's size in SQL Server 2005 OLAP serivice? I have searched the BOL but can't find any reference.

Thanks,

|||

according to MS it has been removed from 2 g from SSAS 2000 to no limit in SSAS 2005!! but facing same error message while backing up!!

Cube backup job failed

Message
Executed as user: INTRANET\SSAgentTrendP1. ...ystem error: The following error occurred while the '\\?\H:\MSSQLDATA\TrendP1\Trend.0.db\Trend.0.cub\Claim Summary V.0.det\Claim Summary V.0.prt\8.fact.data' file was being copied to the 'G:\MSSQLDATA\TrendP1\Auto_before.abf' file: . at Microsoft.AnalysisServices.Xmla.XmlaClient.CheckForSoapFault(XmlReader reader, XmlaResult xmlaResult, Boolean throwIfError) at Microsoft.AnalysisServices.Xmla.XmlaClient.CheckForError(XmlReader reader, XmlaResult xmlaResult, Boolean throwIfError) at Microsoft.AnalysisServices.Xmla.XmlaClient.SendMessage(Boolean endReceivalIfException, Boolean readSession, Boolean readNamespaceCompatibility) at Microsoft.AnalysisServices.Xmla.XmlaClient.SendMessageAndReturnResult(String& result, Boolean skipResult) at Microsoft.AnalysisServices.Xmla.XmlaClient.Execute(String command, String properties, String& result, Boolean skipResult, Boolean propertiesXmlIsComplete) at Microsoft.SqlServer.Management.Smo.Olap.Soap. The step failed.

This is the job step definition:

<Backup xmlns="http://schemas.microsoft.com/analysisservices/2003/engine">
<Object>
<DatabaseID>Trend</DatabaseID>
</Object>
<File>G:\MSSQLDATA\TrendP1\Auto_before.abf</File>
<AllowOverwrite>true</AllowOverwrite>
<ApplyCompression>false</ApplyCompression>
</Backup>

This job has been running for a while. The problem started after I did a restore of the cube at one point of time.

|||

Further investigation reveals that one of the fact.data file had growed to 4G in size and the backup started to fail.

Is there a size limitation of individual partition's size in SQL Server 2005 OLAP serivice? I have searched the BOL but can't find any reference.

Thanks,

|||

according to MS it has been removed from 2 g from SSAS 2000 to no limit in SSAS 2005!! but facing same error message while backing up!!

CTP version and release version

we have a backup of a database from a release version with version number 9.00.1399 and we wanted to restore it to a server with version number (9.00.1116) CTP release. we were issued a version incopatibility message. is it possible to backup from a 9.00.1399 release with a backup file compatible for a CTP release, is there an available option during backup? thanks!

CTP versions are no longer supported. You should be using the released version of the product.

Ideally, you should be at SP1, as we fixed quite a few bugs there.

Backup is a physical operation. If the structure of the database pages has changed in any way, we have no way to do the conversion during restore. For moving up, we have the logic in the startup code to re-apply the same changes that the upgrade would do. We don't support moving down in versions where the database format is incompatible.

|||thanks kevin