difference between filesize in Backupfile and backupset

Can anyone tell me the difference between the filesize values being logged
in the Backupfile and Backupset tables in the msdb database.
I am a little confused as the data for the backup on a same day registers
different file sizes. Also can anyone give me a little more idea on what
each of these tables are being used for.
Thanks
Hi
In BackupSet, there is a column 'backupsize'. This value isthe size, in
bytes, of the backup dumped to tape/disk.
In BackupFile, there is a column 'filesize'. This is the actual size of the
device files that are currently configured for the DB, that have been backed
up in the BackupSet..
Definitions from systbl.chm:
backupfile
Contains one row for each data or log file that is backed up. This table is
stored in the msdb database.
backupset
Contains a row for each backup set. This table is stored in the msdb database.
Regards
Mike
"Rahul Chatterjee" wrote:

> Can anyone tell me the difference between the filesize values being logged
> in the Backupfile and Backupset tables in the msdb database.
> I am a little confused as the data for the backup on a same day registers
> different file sizes. Also can anyone give me a little more idea on what
> each of these tables are being used for.
> Thanks
>
>

difference between filesize in Backupfile and backupset

Can anyone tell me the difference between the filesize values being logged
in the Backupfile and Backupset tables in the msdb database.
I am a little confused as the data for the backup on a same day registers
different file sizes. Also can anyone give me a little more idea on what
each of these tables are being used for.
ThanksHi
In BackupSet, there is a column 'backupsize'. This value isthe size, in
bytes, of the backup dumped to tape/disk.
In BackupFile, there is a column 'filesize'. This is the actual size of the
device files that are currently configured for the DB, that have been backed
up in the BackupSet..
Definitions from systbl.chm:
backupfile
Contains one row for each data or log file that is backed up. This table is
stored in the msdb database.
backupset
Contains a row for each backup set. This table is stored in the msdb database.
Regards
Mike
"Rahul Chatterjee" wrote:
> Can anyone tell me the difference between the filesize values being logged
> in the Backupfile and Backupset tables in the msdb database.
> I am a little confused as the data for the backup on a same day registers
> different file sizes. Also can anyone give me a little more idea on what
> each of these tables are being used for.
> Thanks
>
>

difference between filesize in Backupfile and backupset

Can anyone tell me the difference between the filesize values being logged
in the Backupfile and Backupset tables in the msdb database.
I am a little confused as the data for the backup on a same day registers
different file sizes. Also can anyone give me a little more idea on what
each of these tables are being used for.
ThanksHi
In BackupSet, there is a column 'backupsize'. This value isthe size, in
bytes, of the backup dumped to tape/disk.
In BackupFile, there is a column 'filesize'. This is the actual size of the
device files that are currently configured for the DB, that have been backed
up in the BackupSet..
Definitions from systbl.chm:
backupfile
Contains one row for each data or log file that is backed up. This table is
stored in the msdb database.
backupset
Contains a row for each backup set. This table is stored in the msdb databas
e.
Regards
Mike
"Rahul Chatterjee" wrote:

> Can anyone tell me the difference between the filesize values being logged
> in the Backupfile and Backupset tables in the msdb database.
> I am a little confused as the data for the backup on a same day registers
> different file sizes. Also can anyone give me a little more idea on what
> each of these tables are being used for.
> Thanks
>
>

device_type = 7 in backupmediafamily?

Does anyone know what device_type = 7 means in the
msdb..backupmediafamily table? The physical_device_name values are
strange (i.e., "model_00__9834ee39_40a6_4d36_9ba6_a65daaac40b9_").
Records for backups that I've initiated have device_type = 2 or 102
and the physical_device_name is the disk path of the backup file.
The SQL documentation shows six valid values for device_type: 2 or 102
= disk, 5 or 105 = tape, 6 or 106 = pipe.
Any insight is greatly appreciated.
TIA,
DougLooks like a virtual_device used to create backups using the VBDI API. The
Veritas SQL Server client uses this among others.
Sincerely,
Anthony Thomas
"Doug" wrote:
> Does anyone know what device_type = 7 means in the
> msdb..backupmediafamily table? The physical_device_name values are
> strange (i.e., "model_00__9834ee39_40a6_4d36_9ba6_a65daaac40b9_").
> Records for backups that I've initiated have device_type = 2 or 102
> and the physical_device_name is the disk path of the backup file.
> The SQL documentation shows six valid values for device_type: 2 or 102
> = disk, 5 or 105 = tape, 6 or 106 = pipe.
> Any insight is greatly appreciated.
> TIA,
> Doug
>

Device holding MASTER, MODEL, MSDB, and TempDB FULL

I have other drives that are quite large that I could move any one of these
to. Not sure how to do the move...this is a production server and down
time needs to be almost non-existent.
TempDB is taking up 1 gig, if there was a way to move it without bringing
down the server, that would be great (like adding a file to new drive, then
shrinking with EMPTY_FILE on old drive.....can this be done during
production or would it cause slowness or locking, etc.?)What version of SQL Server are you using ...?
Have you tried Shrinking it. DBCC SHRINKFILE
HTH
Ryan Waight, MCDBA, MCSE
"John Hamilton" <jhamil@.nowhere.com> wrote in message
news:ODt9rtJnDHA.2528@.TK2MSFTNGP12.phx.gbl...
> I have other drives that are quite large that I could move any one of
these
> to. Not sure how to do the move...this is a production server and down
> time needs to be almost non-existent.
> TempDB is taking up 1 gig, if there was a way to move it without bringing
> down the server, that would be great (like adding a file to new drive,
then
> shrinking with EMPTY_FILE on old drive.....can this be done during
> production or would it cause slowness or locking, etc.?)
>|||I'm using 2000, and I tried DBCC SHRINKFILE, it didn't change the size.
"Ryan Waight" <Ryan_Waight@.nospam.hotmail.com> wrote in message
news:eWnaIzJnDHA.2012@.TK2MSFTNGP12.phx.gbl...
> What version of SQL Server are you using ...?
> Have you tried Shrinking it. DBCC SHRINKFILE
>
> --
> HTH
> Ryan Waight, MCDBA, MCSE
> "John Hamilton" <jhamil@.nowhere.com> wrote in message
> news:ODt9rtJnDHA.2528@.TK2MSFTNGP12.phx.gbl...
> > I have other drives that are quite large that I could move any one of
> these
> > to. Not sure how to do the move...this is a production server and down
> > time needs to be almost non-existent.
> >
> > TempDB is taking up 1 gig, if there was a way to move it without
bringing
> > down the server, that would be great (like adding a file to new drive,
> then
> > shrinking with EMPTY_FILE on old drive.....can this be done during
> > production or would it cause slowness or locking, etc.?)
> >
> >
>|||Tried SHRINKFILE again and it worked this time....'?
"Ryan Waight" <Ryan_Waight@.nospam.hotmail.com> wrote in message
news:eWnaIzJnDHA.2012@.TK2MSFTNGP12.phx.gbl...
> What version of SQL Server are you using ...?
> Have you tried Shrinking it. DBCC SHRINKFILE
>
> --
> HTH
> Ryan Waight, MCDBA, MCSE
> "John Hamilton" <jhamil@.nowhere.com> wrote in message
> news:ODt9rtJnDHA.2528@.TK2MSFTNGP12.phx.gbl...
> > I have other drives that are quite large that I could move any one of
> these
> > to. Not sure how to do the move...this is a production server and down
> > time needs to be almost non-existent.
> >
> > TempDB is taking up 1 gig, if there was a way to move it without
bringing
> > down the server, that would be great (like adding a file to new drive,
> then
> > shrinking with EMPTY_FILE on old drive.....can this be done during
> > production or would it cause slowness or locking, etc.?)
> >
> >
>|||Have a look at this :- http://www.aspfaq.com/show.asp?id=2446
good for future reference..
--
HTH
Ryan Waight, MCDBA, MCSE
"John Hamilton" <jhamil@.nowhere.com> wrote in message
news:%234Iku4JnDHA.2080@.TK2MSFTNGP10.phx.gbl...
> Tried SHRINKFILE again and it worked this time....'?
>
> "Ryan Waight" <Ryan_Waight@.nospam.hotmail.com> wrote in message
> news:eWnaIzJnDHA.2012@.TK2MSFTNGP12.phx.gbl...
> > What version of SQL Server are you using ...?
> >
> > Have you tried Shrinking it. DBCC SHRINKFILE
> >
> >
> >
> > --
> > HTH
> > Ryan Waight, MCDBA, MCSE
> >
> > "John Hamilton" <jhamil@.nowhere.com> wrote in message
> > news:ODt9rtJnDHA.2528@.TK2MSFTNGP12.phx.gbl...
> > > I have other drives that are quite large that I could move any one of
> > these
> > > to. Not sure how to do the move...this is a production server and
down
> > > time needs to be almost non-existent.
> > >
> > > TempDB is taking up 1 gig, if there was a way to move it without
> bringing
> > > down the server, that would be great (like adding a file to new drive,
> > then
> > > shrinking with EMPTY_FILE on old drive.....can this be done during
> > > production or would it cause slowness or locking, etc.?)
> > >
> > >
> >
> >
>|||This would indicate an open transaction was preventing the shrink. DBCC
OPENTRAN shows any open transcations
--
HTH
Ryan Waight, MCDBA, MCSE
"John Hamilton" <jhamil@.nowhere.com> wrote in message
news:%234Iku4JnDHA.2080@.TK2MSFTNGP10.phx.gbl...
> Tried SHRINKFILE again and it worked this time....'?
>
> "Ryan Waight" <Ryan_Waight@.nospam.hotmail.com> wrote in message
> news:eWnaIzJnDHA.2012@.TK2MSFTNGP12.phx.gbl...
> > What version of SQL Server are you using ...?
> >
> > Have you tried Shrinking it. DBCC SHRINKFILE
> >
> >
> >
> > --
> > HTH
> > Ryan Waight, MCDBA, MCSE
> >
> > "John Hamilton" <jhamil@.nowhere.com> wrote in message
> > news:ODt9rtJnDHA.2528@.TK2MSFTNGP12.phx.gbl...
> > > I have other drives that are quite large that I could move any one of
> > these
> > > to. Not sure how to do the move...this is a production server and
down
> > > time needs to be almost non-existent.
> > >
> > > TempDB is taking up 1 gig, if there was a way to move it without
> bringing
> > > down the server, that would be great (like adding a file to new drive,
> > then
> > > shrinking with EMPTY_FILE on old drive.....can this be done during
> > > production or would it cause slowness or locking, etc.?)
> > >
> > >
> >
> >
>

Developer and DTS rights

To adhere to corporate security policies we have removed the guest
account from msdb. This has resulted in developers not having the
ability to view any dts packages on the server. We have multiple
development groups and a large amount of databases on the server.
Does anyone have a solution to this situation that we could use?
Thanks in advance, Markassign a security group a login to the sql server,
grant dbaccess to the msdb database for that user.
Regards,
Dandy Weyn
MCSE, MCSA, MCDBA, MCT
www.dandyman.net
"Mark Anderson" <magnm01@.wellsfargo.com> wrote in message
news:ac3d559a.0401141350.68879fa9@.posting.google.com...
> To adhere to corporate security policies we have removed the guest
> account from msdb. This has resulted in developers not having the
> ability to view any dts packages on the server. We have multiple
> development groups and a large amount of databases on the server.
> Does anyone have a solution to this situation that we could use?
> Thanks in advance, Mark

Developer and DTS rights

To adhere to corporate security policies we have removed the guest
account from msdb. This has resulted in developers not having the
ability to view any dts packages on the server. We have multiple
development groups and a large amount of databases on the server.
Does anyone have a solution to this situation that we could use?
Thanks in advance, Markassign a security group a login to the sql server,
grant dbaccess to the msdb database for that user.
Regards,
Dandy Weyn
MCSE, MCSA, MCDBA, MCT
www.dandyman.net
"Mark Anderson" <magnm01@.wellsfargo.com> wrote in message
news:ac3d559a.0401141350.68879fa9@.posting.google.com...

quote:

---

> To adhere to corporate security policies we have removed the guest
> account from msdb. This has resulted in developers not having the
> ability to view any dts packages on the server. We have multiple
> development groups and a large amount of databases on the server.
> Does anyone have a solution to this situation that we could use?
> Thanks in advance, Mark

---