Database Backups

can I get someones opinion of full backups? I currently have full backups 3
days a w and t-logs every hour. I was thinking about switching to full
bakcups every day. Is there a problem with this strategy?Depends on your database size, available disk space, etc.
All of my clients are currently doing at least one full backup a day, some
more...:-) Most of them have database sizes under 20GB.
Kevin Hill
President
3NF Consulting
www.3nf-inc.com/NewsGroups.htm
"Lontae Jones" <LontaeJones@.discussions.microsoft.com> wrote in message
news:15C5AC5A-A72A-4C5A-A5A4-63A5EE948575@.microsoft.com...
> can I get someones opinion of full backups? I currently have full backups
> 3
> days a w and t-logs every hour. I was thinking about switching to full
> bakcups every day. Is there a problem with this strategy?|||There is no problem with the new strategy if the off-peak duration of your
database is more than the time taken by full database backup. Let ms explain
with an example: Suppose Full Backup of the database takes 2 hours, and only
a few user activites happen in the database from 00:00 Hours to 04:00 Hours.
Thus scheduling a Full Backup every day is a very good decision.
"Lontae Jones" wrote:

> can I get someones opinion of full backups? I currently have full backups
3
> days a w and t-logs every hour. I was thinking about switching to full
> bakcups every day. Is there a problem with this strategy?|||Thanks for all replies.
My disk space is 100 Gb and my fullbackups would be 91.GB. ALso what if I
lose a backup or something happens then I dont have logs right?
"Kevin3NF" wrote:

> Depends on your database size, available disk space, etc.
> All of my clients are currently doing at least one full backup a day, some
> more...:-) Most of them have database sizes under 20GB.
> --
> Kevin Hill
> President
> 3NF Consulting
> www.3nf-inc.com/NewsGroups.htm
>
> "Lontae Jones" <LontaeJones@.discussions.microsoft.com> wrote in message
> news:15C5AC5A-A72A-4C5A-A5A4-63A5EE948575@.microsoft.com...
>
>|||You have logs if you are in Full Recovery mode, and you need to be backing
them up. If you are in simple recovery mode, your recoverability is limited
to the point of the last full backup.
With data size and space as you mention, you might want to look into a
backup compression utility such as SQL LiteSpeed (I'm a reseller) or SQLSafe
(no affiliation)...you can get anywhere form 50-90% compression and time
reduction using these.
HTH,
Kevin Hill
President
3NF Consulting
www.3nf-inc.com/NewsGroups.htm
"Lontae Jones" <LontaeJones@.discussions.microsoft.com> wrote in message
news:860DF5D5-9731-4D1F-A934-78A6EEA84555@.microsoft.com...
> Thanks for all replies.
> My disk space is 100 Gb and my fullbackups would be 91.GB. ALso what if I
> lose a backup or something happens then I dont have logs right?
> "Kevin3NF" wrote:
>

data type chose

I'd like your opinion or what Microsoft's position is on the following.
In MS Access you'll read a Tip that on phone numbers and other numbers you
don't intend to use for mathematical calculations to use a Text data type.
This may be because the system converts all compares to ascii string...this
isn't an actual reason given.
I read in various SQL Server books, magazines, etc to use the data type
appropriate to the data being stored. So if you have data that is all
numeric, it would seem a numerical type of data type should be used.
Should data not used for calculations be in character data types or are
numerical data types perfectly fine to use?
TIA,
Doug
Doug wrote:
> I'd like your opinion or what Microsoft's position is on the
> following.
> In MS Access you'll read a Tip that on phone numbers and other
> numbers you don't intend to use for mathematical calculations to use
> a Text data type. This may be because the system converts all
> compares to ascii string...this isn't an actual reason given.
> I read in various SQL Server books, magazines, etc to use the data
> type appropriate to the data being stored. So if you have data that
> is all numeric, it would seem a numerical type of data type should be
> used.
> Should data not used for calculations be in character data types or
> are numerical data types perfectly fine to use?
> TIA,
> Doug
I would say that a phone number is not a number at all despite is
having, most time, only a numeric component. Personally, I would never
store a phone number in anything other than a character type column. I'm
not sure what types of mathematical calculations you are going to do on
a phone number. You may have an app that uses the earea code and
exchange for specific processing and in that case, you may choose to
store your phone numbers as AreaCode, Exchange, Suffix. You could also
add country codes, extensions and all sorts of data that describes a
phone number. And you might remember the days when New Yorkers used
letters to tell others their phone numbers "KL6- 2133". Unless, you're
storing a number (value, amount, etc.) I would stick with character
columns.
David Gugick
Imceda Software
www.imceda.com

data type chose

I'd like your opinion or what Microsoft's position is on the following.
In MS Access you'll read a Tip that on phone numbers and other numbers you
don't intend to use for mathematical calculations to use a Text data type.
This may be because the system converts all compares to ascii string...this
isn't an actual reason given.
I read in various SQL Server books, magazines, etc to use the data type
appropriate to the data being stored. So if you have data that is all
numeric, it would seem a numerical type of data type should be used.
Should data not used for calculations be in character data types or are
numerical data types perfectly fine to use?
TIA,
DougDoug wrote:
> I'd like your opinion or what Microsoft's position is on the
> following.
> In MS Access you'll read a Tip that on phone numbers and other
> numbers you don't intend to use for mathematical calculations to use
> a Text data type. This may be because the system converts all
> compares to ascii string...this isn't an actual reason given.
> I read in various SQL Server books, magazines, etc to use the data
> type appropriate to the data being stored. So if you have data that
> is all numeric, it would seem a numerical type of data type should be
> used.
> Should data not used for calculations be in character data types or
> are numerical data types perfectly fine to use?
> TIA,
> Doug
I would say that a phone number is not a number at all despite is
having, most time, only a numeric component. Personally, I would never
store a phone number in anything other than a character type column. I'm
not sure what types of mathematical calculations you are going to do on
a phone number. You may have an app that uses the earea code and
exchange for specific processing and in that case, you may choose to
store your phone numbers as AreaCode, Exchange, Suffix. You could also
add country codes, extensions and all sorts of data that describes a
phone number. And you might remember the days when New Yorkers used
letters to tell others their phone numbers "KL6- 2133". Unless, you're
storing a number (value, amount, etc.) I would stick with character
columns.
David Gugick
Imceda Software
www.imceda.com

data type chose

I'd like your opinion or what Microsoft's position is on the following.
In MS Access you'll read a Tip that on phone numbers and other numbers you
don't intend to use for mathematical calculations to use a Text data type.
This may be because the system converts all compares to ascii string...this
isn't an actual reason given.
I read in various SQL Server books, magazines, etc to use the data type
appropriate to the data being stored. So if you have data that is all
numeric, it would seem a numerical type of data type should be used.
Should data not used for calculations be in character data types or are
numerical data types perfectly fine to use?
TIA,
DougDoug wrote:
> I'd like your opinion or what Microsoft's position is on the
> following.
> In MS Access you'll read a Tip that on phone numbers and other
> numbers you don't intend to use for mathematical calculations to use
> a Text data type. This may be because the system converts all
> compares to ascii string...this isn't an actual reason given.
> I read in various SQL Server books, magazines, etc to use the data
> type appropriate to the data being stored. So if you have data that
> is all numeric, it would seem a numerical type of data type should be
> used.
> Should data not used for calculations be in character data types or
> are numerical data types perfectly fine to use?
> TIA,
> Doug
I would say that a phone number is not a number at all despite is
having, most time, only a numeric component. Personally, I would never
store a phone number in anything other than a character type column. I'm
not sure what types of mathematical calculations you are going to do on
a phone number. You may have an app that uses the earea code and
exchange for specific processing and in that case, you may choose to
store your phone numbers as AreaCode, Exchange, Suffix. You could also
add country codes, extensions and all sorts of data that describes a
phone number. And you might remember the days when New Yorkers used
letters to tell others their phone numbers "KL6- 2133". Unless, you're
storing a number (value, amount, etc.) I would stick with character
columns.
--
David Gugick
Imceda Software
www.imceda.com

Data Transformation in Transactional Replication

I already put this set of questions to another group and oly one person
replied. I would appreciate if other people can share their opinion as well.
Thanks
=====================
I have a transactional replication set up from one system to another.
Subscriber has only read mode on data (Uni-directional Replication). I need
to do lots of transformation in the data while replication from Publisher to
Subcriber Like adding the same record in the other table as well or do some
denormalization etc.
Which route should I choose?
1. Modify Replicaiton procedures to have this business rule in-built.
2. Should I create indexed views and other tables on reporting server.
3. Should I create trigger on the reporting server and have the replication
procedure only do the insert and trigger do rest of the business rules
implementaion.
4. Can reporting services be used for such a transformation.
5. Should I have DTS as a part of replication.
-Nitin
Perhaps you should call PSS and get their input.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Now available on Amazon.com
http://www.amazon.com/gp/product/off...?condition=all
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Nitin" <Nitin@.discussions.microsoft.com> wrote in message
news:A2EE86E0-024D-4E1D-9051-6144C65B310F@.microsoft.com...
> I already put this set of questions to another group and oly one person
> replied. I would appreciate if other people can share their opinion as
well.
> Thanks
> =====================
> I have a transactional replication set up from one system to another.
> Subscriber has only read mode on data (Uni-directional Replication). I
need
> to do lots of transformation in the data while replication from Publisher
to
> Subcriber Like adding the same record in the other table as well or do
some
> denormalization etc.
> Which route should I choose?
> 1. Modify Replicaiton procedures to have this business rule in-built.
> 2. Should I create indexed views and other tables on reporting server.
> 3. Should I create trigger on the reporting server and have the
replication
> procedure only do the insert and trigger do rest of the business rules
> implementaion.
> 4. Can reporting services be used for such a transformation.
> 5. Should I have DTS as a part of replication.
> -Nitin