We're using SS2000. We do a lot of ETL (extract, transform, load) work and
don't really need logs. From advice received here and from reading the BOL,
it looks like using the simple recovery plan would work best for us. I found
this in the BOL:
a.. If the database is using the simple recovery model, an automatic
checkpoint is generated whenever the number of log records reaches the
lesser of these two values:
a.. The log becomes 70 percent full.
b.. The number of log records reaches the number SQL Server estimates it
can process during the time specified in the recovery interval option.
Automatic checkpoints truncate the unused portion of the transaction log if
the database is using the simple recovery model.
Long-Running Transactions
The active portion of the log must include every part of all uncommitted
transactions. An application that starts a transaction and does not commit
it or roll it back prevents SQL Server from advancing the MinLSN. This can
cause two types of problems:
a.. If the system is shut down after the transaction has performed many
uncommitted modifications, the recovery phase of the subsequent restart can
take considerably longer than the amount of time specified in the recovery
interval option.
b.. The log may grow very large because the log cannot be truncated past
the MinLSN. This happens even if the database is using the simple recovery
model, in which the transaction log is normally truncated on each automatic
checkpoint.
Since the checkpoint is issued when the size of the log becomes 70 percent
full, I'm thinking that if I create a small log file (1MB) and do not let it
grow then maybe the checkpoints will come quickly and so the log will never
grow very big. I'm assuming that doing this will mean the value for this
will be smaller than the value of "the number of log records reaches the
number SQL Server estimates it can process during the time specified in the
recovery interval option".
But if I do this I'm wondering what will happen in long transactions. BOL
says "The log may grow very large because the log cannot be truncated past
the MinLSN. This happens even if the database is using the simple recovery
model, in which the transaction log is normally truncated on each automatic
checkpoint." Do you think the log file will continue to grow even though
I've specified in database properties for it NOT to grow? If it does grow
for a large transaction it's ok. I'm assuming it will truncate when the
transactioin is finished. I just don't want the transaction to end before
it's finished because I've told it not to grow the transaction log.
One of the databases that we have has a table with about 55 million rows in
it. We add about 800,000 rows each month using a "select into" statement.
This is the table:
CREATE TABLE [tblDNCNational] (
[PHONE] [char] (10) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[STATE_FLAG] [char] (1) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[DATE_ENTERED] [smalldatetime] NULL
I don't know how big the transaction log would get by adding 800,000 rows
but I'm guessing that it would certainly exceed the 1MB size of the
tranaction log. So, I just want to be sure that the system will grow the log
file even though I've told it not to or it will truncate the file and keep
going. I could break the one transaction up into more transactions if
someone thinks that would help.
Any advice is appreciated,
Dan
I tested this and found out that I can't set the log file to 1M and then not
grow. A large transaction fills up the log. So, I have to let it grow.
However, under the simple recovery plan, the log file does truncate at the
end of every transaction. I'll probably do a shrinkfile every so often to
free up some storage room.
Dan
"Dan" <ddonahue@.archermalmo.com> wrote in message
news:ecv4FhCPEHA.2996@.TK2MSFTNGP12.phx.gbl...
> We're using SS2000. We do a lot of ETL (extract, transform, load) work and
> don't really need logs. From advice received here and from reading the
BOL,
> it looks like using the simple recovery plan would work best for us. I
found
> this in the BOL:
> a.. If the database is using the simple recovery model, an automatic
> checkpoint is generated whenever the number of log records reaches the
> lesser of these two values:
> a.. The log becomes 70 percent full.
> b.. The number of log records reaches the number SQL Server estimates it
> can process during the time specified in the recovery interval option.
> Automatic checkpoints truncate the unused portion of the transaction log
if
> the database is using the simple recovery model.
> Long-Running Transactions
> The active portion of the log must include every part of all uncommitted
> transactions. An application that starts a transaction and does not commit
> it or roll it back prevents SQL Server from advancing the MinLSN. This can
> cause two types of problems:
> a.. If the system is shut down after the transaction has performed many
> uncommitted modifications, the recovery phase of the subsequent restart
can
> take considerably longer than the amount of time specified in the recovery
> interval option.
>
> b.. The log may grow very large because the log cannot be truncated past
> the MinLSN. This happens even if the database is using the simple recovery
> model, in which the transaction log is normally truncated on each
automatic
> checkpoint.
> Since the checkpoint is issued when the size of the log becomes 70 percent
> full, I'm thinking that if I create a small log file (1MB) and do not let
it
> grow then maybe the checkpoints will come quickly and so the log will
never
> grow very big. I'm assuming that doing this will mean the value for this
> will be smaller than the value of "the number of log records reaches the
> number SQL Server estimates it can process during the time specified in
the
> recovery interval option".
> But if I do this I'm wondering what will happen in long transactions. BOL
> says "The log may grow very large because the log cannot be truncated past
> the MinLSN. This happens even if the database is using the simple recovery
> model, in which the transaction log is normally truncated on each
automatic
> checkpoint." Do you think the log file will continue to grow even though
> I've specified in database properties for it NOT to grow? If it does grow
> for a large transaction it's ok. I'm assuming it will truncate when the
> transactioin is finished. I just don't want the transaction to end before
> it's finished because I've told it not to grow the transaction log.
> One of the databases that we have has a table with about 55 million rows
in
> it. We add about 800,000 rows each month using a "select into" statement.
> This is the table:
> CREATE TABLE [tblDNCNational] (
> [PHONE] [char] (10) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
> [STATE_FLAG] [char] (1) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
> [DATE_ENTERED] [smalldatetime] NULL
> I don't know how big the transaction log would get by adding 800,000 rows
> but I'm guessing that it would certainly exceed the 1MB size of the
> tranaction log. So, I just want to be sure that the system will grow the
log
> file even though I've told it not to or it will truncate the file and keep
> going. I could break the one transaction up into more transactions if
> someone thinks that would help.
> Any advice is appreciated,
> Dan
>
|||Dan,
Your load will fail if SQL Server cannot write to the log because its full.
You will get a transaction log full error and the transaction will get
rolled back. Why not just size the log to the biggest you think you will
need and leave it at that? Shrinking and growing the log will just fragment
the log file.
If you can do your work in smaller transactions, then all the better for
your log size. You could use an INSERT...SELECT statement with an
appropriate WHERE clause in a WHILE loop to do your batch inserts in smaller
steps.
However, bear in mind that you will lose transactional consistency. i.e. if
the load fails half way through, then only uncommitted transactions get
rolled back. My preferred approach would be to set your log file to a larger
size, you then retain transactional consistency. You say that you don't need
the logs, but you really do, so that SQL Server knows what to roll
back/forward in the event of a server failure.
Mark Allison, SQL Server MVP
http://www.markallison.co.uk
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
"Dan" <ddonahue@.archermalmo.com> wrote in message
news:ecv4FhCPEHA.2996@.TK2MSFTNGP12.phx.gbl...
> We're using SS2000. We do a lot of ETL (extract, transform, load) work and
> don't really need logs. From advice received here and from reading the
BOL,
> it looks like using the simple recovery plan would work best for us. I
found
> this in the BOL:
> a.. If the database is using the simple recovery model, an automatic
> checkpoint is generated whenever the number of log records reaches the
> lesser of these two values:
> a.. The log becomes 70 percent full.
> b.. The number of log records reaches the number SQL Server estimates it
> can process during the time specified in the recovery interval option.
> Automatic checkpoints truncate the unused portion of the transaction log
if
> the database is using the simple recovery model.
> Long-Running Transactions
> The active portion of the log must include every part of all uncommitted
> transactions. An application that starts a transaction and does not commit
> it or roll it back prevents SQL Server from advancing the MinLSN. This can
> cause two types of problems:
> a.. If the system is shut down after the transaction has performed many
> uncommitted modifications, the recovery phase of the subsequent restart
can
> take considerably longer than the amount of time specified in the recovery
> interval option.
>
> b.. The log may grow very large because the log cannot be truncated past
> the MinLSN. This happens even if the database is using the simple recovery
> model, in which the transaction log is normally truncated on each
automatic
> checkpoint.
> Since the checkpoint is issued when the size of the log becomes 70 percent
> full, I'm thinking that if I create a small log file (1MB) and do not let
it
> grow then maybe the checkpoints will come quickly and so the log will
never
> grow very big. I'm assuming that doing this will mean the value for this
> will be smaller than the value of "the number of log records reaches the
> number SQL Server estimates it can process during the time specified in
the
> recovery interval option".
> But if I do this I'm wondering what will happen in long transactions. BOL
> says "The log may grow very large because the log cannot be truncated past
> the MinLSN. This happens even if the database is using the simple recovery
> model, in which the transaction log is normally truncated on each
automatic
> checkpoint." Do you think the log file will continue to grow even though
> I've specified in database properties for it NOT to grow? If it does grow
> for a large transaction it's ok. I'm assuming it will truncate when the
> transactioin is finished. I just don't want the transaction to end before
> it's finished because I've told it not to grow the transaction log.
> One of the databases that we have has a table with about 55 million rows
in
> it. We add about 800,000 rows each month using a "select into" statement.
> This is the table:
> CREATE TABLE [tblDNCNational] (
> [PHONE] [char] (10) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
> [STATE_FLAG] [char] (1) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
> [DATE_ENTERED] [smalldatetime] NULL
> I don't know how big the transaction log would get by adding 800,000 rows
> but I'm guessing that it would certainly exceed the 1MB size of the
> tranaction log. So, I just want to be sure that the system will grow the
log
> file even though I've told it not to or it will truncate the file and keep
> going. I could break the one transaction up into more transactions if
> someone thinks that would help.
> Any advice is appreciated,
> Dan
>
|||Hi Dan,
It is not advisable to restrict the growth of the Log file.
If you restrict the growth of the log file then, the active transactions
would be rolled back when the Log gets full, due to long running
transactions, and it is not able to expand it self to accomodate more
transaction.
Allow the log file to grow and you may set the recovery to simple, so that
the log is truncated on checkpoints.
HTH
Ashish
This posting is provided "AS IS" with no warranties, and confers no rights.
Showing posts with label logs. Show all posts
Showing posts with label logs. Show all posts
Thursday, March 8, 2012
another logging question
We're using SS2000. We do a lot of ETL (extract, transform, load) work and
don't really need logs. From advice received here and from reading the BOL,
it looks like using the simple recovery plan would work best for us. I found
this in the BOL:
a.. If the database is using the simple recovery model, an automatic
checkpoint is generated whenever the number of log records reaches the
lesser of these two values:
a.. The log becomes 70 percent full.
b.. The number of log records reaches the number SQL Server estimates it
can process during the time specified in the recovery interval option.
Automatic checkpoints truncate the unused portion of the transaction log if
the database is using the simple recovery model.
Long-Running Transactions
The active portion of the log must include every part of all uncommitted
transactions. An application that starts a transaction and does not commit
it or roll it back prevents SQL Server from advancing the MinLSN. This can
cause two types of problems:
a.. If the system is shut down after the transaction has performed many
uncommitted modifications, the recovery phase of the subsequent restart can
take considerably longer than the amount of time specified in the recovery
interval option.
b.. The log may grow very large because the log cannot be truncated past
the MinLSN. This happens even if the database is using the simple recovery
model, in which the transaction log is normally truncated on each automatic
checkpoint.
Since the checkpoint is issued when the size of the log becomes 70 percent
full, I'm thinking that if I create a small log file (1MB) and do not let it
grow then maybe the checkpoints will come quickly and so the log will never
grow very big. I'm assuming that doing this will mean the value for this
will be smaller than the value of "the number of log records reaches the
number SQL Server estimates it can process during the time specified in the
recovery interval option".
But if I do this I'm wondering what will happen in long transactions. BOL
says "The log may grow very large because the log cannot be truncated past
the MinLSN. This happens even if the database is using the simple recovery
model, in which the transaction log is normally truncated on each automatic
checkpoint." Do you think the log file will continue to grow even though
I've specified in database properties for it NOT to grow? If it does grow
for a large transaction it's ok. I'm assuming it will truncate when the
transactioin is finished. I just don't want the transaction to end before
it's finished because I've told it not to grow the transaction log.
One of the databases that we have has a table with about 55 million rows in
it. We add about 800,000 rows each month using a "select into" statement.
This is the table:
CREATE TABLE [tblDNCNational] (
[PHONE] [char] (10) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[STATE_FLAG] [char] (1) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[DATE_ENTERED] [smalldatetime] NULL
I don't know how big the transaction log would get by adding 800,000 rows
but I'm guessing that it would certainly exceed the 1MB size of the
tranaction log. So, I just want to be sure that the system will grow the log
file even though I've told it not to or it will truncate the file and keep
going. I could break the one transaction up into more transactions if
someone thinks that would help.
Any advice is appreciated,
DanI tested this and found out that I can't set the log file to 1M and then not
grow. A large transaction fills up the log. So, I have to let it grow.
However, under the simple recovery plan, the log file does truncate at the
end of every transaction. I'll probably do a shrinkfile every so often to
free up some storage room.
Dan
"Dan" <ddonahue@.archermalmo.com> wrote in message
news:ecv4FhCPEHA.2996@.TK2MSFTNGP12.phx.gbl...
> We're using SS2000. We do a lot of ETL (extract, transform, load) work and
> don't really need logs. From advice received here and from reading the
BOL,
> it looks like using the simple recovery plan would work best for us. I
found
> this in the BOL:
> a.. If the database is using the simple recovery model, an automatic
> checkpoint is generated whenever the number of log records reaches the
> lesser of these two values:
> a.. The log becomes 70 percent full.
> b.. The number of log records reaches the number SQL Server estimates it
> can process during the time specified in the recovery interval option.
> Automatic checkpoints truncate the unused portion of the transaction log
if
> the database is using the simple recovery model.
> Long-Running Transactions
> The active portion of the log must include every part of all uncommitted
> transactions. An application that starts a transaction and does not commit
> it or roll it back prevents SQL Server from advancing the MinLSN. This can
> cause two types of problems:
> a.. If the system is shut down after the transaction has performed many
> uncommitted modifications, the recovery phase of the subsequent restart
can
> take considerably longer than the amount of time specified in the recovery
> interval option.
>
> b.. The log may grow very large because the log cannot be truncated past
> the MinLSN. This happens even if the database is using the simple recovery
> model, in which the transaction log is normally truncated on each
automatic
> checkpoint.
> Since the checkpoint is issued when the size of the log becomes 70 percent
> full, I'm thinking that if I create a small log file (1MB) and do not let
it
> grow then maybe the checkpoints will come quickly and so the log will
never
> grow very big. I'm assuming that doing this will mean the value for this
> will be smaller than the value of "the number of log records reaches the
> number SQL Server estimates it can process during the time specified in
the
> recovery interval option".
> But if I do this I'm wondering what will happen in long transactions. BOL
> says "The log may grow very large because the log cannot be truncated past
> the MinLSN. This happens even if the database is using the simple recovery
> model, in which the transaction log is normally truncated on each
automatic
> checkpoint." Do you think the log file will continue to grow even though
> I've specified in database properties for it NOT to grow? If it does grow
> for a large transaction it's ok. I'm assuming it will truncate when the
> transactioin is finished. I just don't want the transaction to end before
> it's finished because I've told it not to grow the transaction log.
> One of the databases that we have has a table with about 55 million rows
in
> it. We add about 800,000 rows each month using a "select into" statement.
> This is the table:
> CREATE TABLE [tblDNCNational] (
> [PHONE] [char] (10) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
> [STATE_FLAG] [char] (1) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,
> [DATE_ENTERED] [smalldatetime] NULL
> I don't know how big the transaction log would get by adding 800,000 rows
> but I'm guessing that it would certainly exceed the 1MB size of the
> tranaction log. So, I just want to be sure that the system will grow the
log
> file even though I've told it not to or it will truncate the file and keep
> going. I could break the one transaction up into more transactions if
> someone thinks that would help.
> Any advice is appreciated,
> Dan
>|||Dan,
Your load will fail if SQL Server cannot write to the log because its full.
You will get a transaction log full error and the transaction will get
rolled back. Why not just size the log to the biggest you think you will
need and leave it at that? Shrinking and growing the log will just fragment
the log file.
If you can do your work in smaller transactions, then all the better for
your log size. You could use an INSERT...SELECT statement with an
appropriate WHERE clause in a WHILE loop to do your batch inserts in smaller
steps.
However, bear in mind that you will lose transactional consistency. i.e. if
the load fails half way through, then only uncommitted transactions get
rolled back. My preferred approach would be to set your log file to a larger
size, you then retain transactional consistency. You say that you don't need
the logs, but you really do, so that SQL Server knows what to roll
back/forward in the event of a server failure.
Mark Allison, SQL Server MVP
http://www.markallison.co.uk
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
"Dan" <ddonahue@.archermalmo.com> wrote in message
news:ecv4FhCPEHA.2996@.TK2MSFTNGP12.phx.gbl...
> We're using SS2000. We do a lot of ETL (extract, transform, load) work and
> don't really need logs. From advice received here and from reading the
BOL,
> it looks like using the simple recovery plan would work best for us. I
found
> this in the BOL:
> a.. If the database is using the simple recovery model, an automatic
> checkpoint is generated whenever the number of log records reaches the
> lesser of these two values:
> a.. The log becomes 70 percent full.
> b.. The number of log records reaches the number SQL Server estimates it
> can process during the time specified in the recovery interval option.
> Automatic checkpoints truncate the unused portion of the transaction log
if
> the database is using the simple recovery model.
> Long-Running Transactions
> The active portion of the log must include every part of all uncommitted
> transactions. An application that starts a transaction and does not commit
> it or roll it back prevents SQL Server from advancing the MinLSN. This can
> cause two types of problems:
> a.. If the system is shut down after the transaction has performed many
> uncommitted modifications, the recovery phase of the subsequent restart
can
> take considerably longer than the amount of time specified in the recovery
> interval option.
>
> b.. The log may grow very large because the log cannot be truncated past
> the MinLSN. This happens even if the database is using the simple recovery
> model, in which the transaction log is normally truncated on each
automatic
> checkpoint.
> Since the checkpoint is issued when the size of the log becomes 70 percent
> full, I'm thinking that if I create a small log file (1MB) and do not let
it
> grow then maybe the checkpoints will come quickly and so the log will
never
> grow very big. I'm assuming that doing this will mean the value for this
> will be smaller than the value of "the number of log records reaches the
> number SQL Server estimates it can process during the time specified in
the
> recovery interval option".
> But if I do this I'm wondering what will happen in long transactions. BOL
> says "The log may grow very large because the log cannot be truncated past
> the MinLSN. This happens even if the database is using the simple recovery
> model, in which the transaction log is normally truncated on each
automatic
> checkpoint." Do you think the log file will continue to grow even though
> I've specified in database properties for it NOT to grow? If it does grow
> for a large transaction it's ok. I'm assuming it will truncate when the
> transactioin is finished. I just don't want the transaction to end before
> it's finished because I've told it not to grow the transaction log.
> One of the databases that we have has a table with about 55 million rows
in
> it. We add about 800,000 rows each month using a "select into" statement.
> This is the table:
> CREATE TABLE [tblDNCNational] (
> [PHONE] [char] (10) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
> [STATE_FLAG] [char] (1) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,
> [DATE_ENTERED] [smalldatetime] NULL
> I don't know how big the transaction log would get by adding 800,000 rows
> but I'm guessing that it would certainly exceed the 1MB size of the
> tranaction log. So, I just want to be sure that the system will grow the
log
> file even though I've told it not to or it will truncate the file and keep
> going. I could break the one transaction up into more transactions if
> someone thinks that would help.
> Any advice is appreciated,
> Dan
>|||Hi Dan,
It is not advisable to restrict the growth of the Log file.
If you restrict the growth of the log file then, the active transactions
would be rolled back when the Log gets full, due to long running
transactions, and it is not able to expand it self to accomodate more
transaction.
Allow the log file to grow and you may set the recovery to simple, so that
the log is truncated on checkpoints.
HTH
Ashish
This posting is provided "AS IS" with no warranties, and confers no rights.
don't really need logs. From advice received here and from reading the BOL,
it looks like using the simple recovery plan would work best for us. I found
this in the BOL:
a.. If the database is using the simple recovery model, an automatic
checkpoint is generated whenever the number of log records reaches the
lesser of these two values:
a.. The log becomes 70 percent full.
b.. The number of log records reaches the number SQL Server estimates it
can process during the time specified in the recovery interval option.
Automatic checkpoints truncate the unused portion of the transaction log if
the database is using the simple recovery model.
Long-Running Transactions
The active portion of the log must include every part of all uncommitted
transactions. An application that starts a transaction and does not commit
it or roll it back prevents SQL Server from advancing the MinLSN. This can
cause two types of problems:
a.. If the system is shut down after the transaction has performed many
uncommitted modifications, the recovery phase of the subsequent restart can
take considerably longer than the amount of time specified in the recovery
interval option.
b.. The log may grow very large because the log cannot be truncated past
the MinLSN. This happens even if the database is using the simple recovery
model, in which the transaction log is normally truncated on each automatic
checkpoint.
Since the checkpoint is issued when the size of the log becomes 70 percent
full, I'm thinking that if I create a small log file (1MB) and do not let it
grow then maybe the checkpoints will come quickly and so the log will never
grow very big. I'm assuming that doing this will mean the value for this
will be smaller than the value of "the number of log records reaches the
number SQL Server estimates it can process during the time specified in the
recovery interval option".
But if I do this I'm wondering what will happen in long transactions. BOL
says "The log may grow very large because the log cannot be truncated past
the MinLSN. This happens even if the database is using the simple recovery
model, in which the transaction log is normally truncated on each automatic
checkpoint." Do you think the log file will continue to grow even though
I've specified in database properties for it NOT to grow? If it does grow
for a large transaction it's ok. I'm assuming it will truncate when the
transactioin is finished. I just don't want the transaction to end before
it's finished because I've told it not to grow the transaction log.
One of the databases that we have has a table with about 55 million rows in
it. We add about 800,000 rows each month using a "select into" statement.
This is the table:
CREATE TABLE [tblDNCNational] (
[PHONE] [char] (10) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[STATE_FLAG] [char] (1) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[DATE_ENTERED] [smalldatetime] NULL
I don't know how big the transaction log would get by adding 800,000 rows
but I'm guessing that it would certainly exceed the 1MB size of the
tranaction log. So, I just want to be sure that the system will grow the log
file even though I've told it not to or it will truncate the file and keep
going. I could break the one transaction up into more transactions if
someone thinks that would help.
Any advice is appreciated,
DanI tested this and found out that I can't set the log file to 1M and then not
grow. A large transaction fills up the log. So, I have to let it grow.
However, under the simple recovery plan, the log file does truncate at the
end of every transaction. I'll probably do a shrinkfile every so often to
free up some storage room.
Dan
"Dan" <ddonahue@.archermalmo.com> wrote in message
news:ecv4FhCPEHA.2996@.TK2MSFTNGP12.phx.gbl...
> We're using SS2000. We do a lot of ETL (extract, transform, load) work and
> don't really need logs. From advice received here and from reading the
BOL,
> it looks like using the simple recovery plan would work best for us. I
found
> this in the BOL:
> a.. If the database is using the simple recovery model, an automatic
> checkpoint is generated whenever the number of log records reaches the
> lesser of these two values:
> a.. The log becomes 70 percent full.
> b.. The number of log records reaches the number SQL Server estimates it
> can process during the time specified in the recovery interval option.
> Automatic checkpoints truncate the unused portion of the transaction log
if
> the database is using the simple recovery model.
> Long-Running Transactions
> The active portion of the log must include every part of all uncommitted
> transactions. An application that starts a transaction and does not commit
> it or roll it back prevents SQL Server from advancing the MinLSN. This can
> cause two types of problems:
> a.. If the system is shut down after the transaction has performed many
> uncommitted modifications, the recovery phase of the subsequent restart
can
> take considerably longer than the amount of time specified in the recovery
> interval option.
>
> b.. The log may grow very large because the log cannot be truncated past
> the MinLSN. This happens even if the database is using the simple recovery
> model, in which the transaction log is normally truncated on each
automatic
> checkpoint.
> Since the checkpoint is issued when the size of the log becomes 70 percent
> full, I'm thinking that if I create a small log file (1MB) and do not let
it
> grow then maybe the checkpoints will come quickly and so the log will
never
> grow very big. I'm assuming that doing this will mean the value for this
> will be smaller than the value of "the number of log records reaches the
> number SQL Server estimates it can process during the time specified in
the
> recovery interval option".
> But if I do this I'm wondering what will happen in long transactions. BOL
> says "The log may grow very large because the log cannot be truncated past
> the MinLSN. This happens even if the database is using the simple recovery
> model, in which the transaction log is normally truncated on each
automatic
> checkpoint." Do you think the log file will continue to grow even though
> I've specified in database properties for it NOT to grow? If it does grow
> for a large transaction it's ok. I'm assuming it will truncate when the
> transactioin is finished. I just don't want the transaction to end before
> it's finished because I've told it not to grow the transaction log.
> One of the databases that we have has a table with about 55 million rows
in
> it. We add about 800,000 rows each month using a "select into" statement.
> This is the table:
> CREATE TABLE [tblDNCNational] (
> [PHONE] [char] (10) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
> [STATE_FLAG] [char] (1) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,
> [DATE_ENTERED] [smalldatetime] NULL
> I don't know how big the transaction log would get by adding 800,000 rows
> but I'm guessing that it would certainly exceed the 1MB size of the
> tranaction log. So, I just want to be sure that the system will grow the
log
> file even though I've told it not to or it will truncate the file and keep
> going. I could break the one transaction up into more transactions if
> someone thinks that would help.
> Any advice is appreciated,
> Dan
>|||Dan,
Your load will fail if SQL Server cannot write to the log because its full.
You will get a transaction log full error and the transaction will get
rolled back. Why not just size the log to the biggest you think you will
need and leave it at that? Shrinking and growing the log will just fragment
the log file.
If you can do your work in smaller transactions, then all the better for
your log size. You could use an INSERT...SELECT statement with an
appropriate WHERE clause in a WHILE loop to do your batch inserts in smaller
steps.
However, bear in mind that you will lose transactional consistency. i.e. if
the load fails half way through, then only uncommitted transactions get
rolled back. My preferred approach would be to set your log file to a larger
size, you then retain transactional consistency. You say that you don't need
the logs, but you really do, so that SQL Server knows what to roll
back/forward in the event of a server failure.
Mark Allison, SQL Server MVP
http://www.markallison.co.uk
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
"Dan" <ddonahue@.archermalmo.com> wrote in message
news:ecv4FhCPEHA.2996@.TK2MSFTNGP12.phx.gbl...
> We're using SS2000. We do a lot of ETL (extract, transform, load) work and
> don't really need logs. From advice received here and from reading the
BOL,
> it looks like using the simple recovery plan would work best for us. I
found
> this in the BOL:
> a.. If the database is using the simple recovery model, an automatic
> checkpoint is generated whenever the number of log records reaches the
> lesser of these two values:
> a.. The log becomes 70 percent full.
> b.. The number of log records reaches the number SQL Server estimates it
> can process during the time specified in the recovery interval option.
> Automatic checkpoints truncate the unused portion of the transaction log
if
> the database is using the simple recovery model.
> Long-Running Transactions
> The active portion of the log must include every part of all uncommitted
> transactions. An application that starts a transaction and does not commit
> it or roll it back prevents SQL Server from advancing the MinLSN. This can
> cause two types of problems:
> a.. If the system is shut down after the transaction has performed many
> uncommitted modifications, the recovery phase of the subsequent restart
can
> take considerably longer than the amount of time specified in the recovery
> interval option.
>
> b.. The log may grow very large because the log cannot be truncated past
> the MinLSN. This happens even if the database is using the simple recovery
> model, in which the transaction log is normally truncated on each
automatic
> checkpoint.
> Since the checkpoint is issued when the size of the log becomes 70 percent
> full, I'm thinking that if I create a small log file (1MB) and do not let
it
> grow then maybe the checkpoints will come quickly and so the log will
never
> grow very big. I'm assuming that doing this will mean the value for this
> will be smaller than the value of "the number of log records reaches the
> number SQL Server estimates it can process during the time specified in
the
> recovery interval option".
> But if I do this I'm wondering what will happen in long transactions. BOL
> says "The log may grow very large because the log cannot be truncated past
> the MinLSN. This happens even if the database is using the simple recovery
> model, in which the transaction log is normally truncated on each
automatic
> checkpoint." Do you think the log file will continue to grow even though
> I've specified in database properties for it NOT to grow? If it does grow
> for a large transaction it's ok. I'm assuming it will truncate when the
> transactioin is finished. I just don't want the transaction to end before
> it's finished because I've told it not to grow the transaction log.
> One of the databases that we have has a table with about 55 million rows
in
> it. We add about 800,000 rows each month using a "select into" statement.
> This is the table:
> CREATE TABLE [tblDNCNational] (
> [PHONE] [char] (10) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
> [STATE_FLAG] [char] (1) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
,
> [DATE_ENTERED] [smalldatetime] NULL
> I don't know how big the transaction log would get by adding 800,000 rows
> but I'm guessing that it would certainly exceed the 1MB size of the
> tranaction log. So, I just want to be sure that the system will grow the
log
> file even though I've told it not to or it will truncate the file and keep
> going. I could break the one transaction up into more transactions if
> someone thinks that would help.
> Any advice is appreciated,
> Dan
>|||Hi Dan,
It is not advisable to restrict the growth of the Log file.
If you restrict the growth of the log file then, the active transactions
would be rolled back when the Log gets full, due to long running
transactions, and it is not able to expand it self to accomodate more
transaction.
Allow the log file to grow and you may set the recovery to simple, so that
the log is truncated on checkpoints.
HTH
Ashish
This posting is provided "AS IS" with no warranties, and confers no rights.
another logging question
We're using SS2000. We do a lot of ETL (extract, transform, load) work and
don't really need logs. From advice received here and from reading the BOL,
it looks like using the simple recovery plan would work best for us. I found
this in the BOL:
a.. If the database is using the simple recovery model, an automatic
checkpoint is generated whenever the number of log records reaches the
lesser of these two values:
a.. The log becomes 70 percent full.
b.. The number of log records reaches the number SQL Server estimates it
can process during the time specified in the recovery interval option.
Automatic checkpoints truncate the unused portion of the transaction log if
the database is using the simple recovery model.
Long-Running Transactions
The active portion of the log must include every part of all uncommitted
transactions. An application that starts a transaction and does not commit
it or roll it back prevents SQL Server from advancing the MinLSN. This can
cause two types of problems:
a.. If the system is shut down after the transaction has performed many
uncommitted modifications, the recovery phase of the subsequent restart can
take considerably longer than the amount of time specified in the recovery
interval option.
b.. The log may grow very large because the log cannot be truncated past
the MinLSN. This happens even if the database is using the simple recovery
model, in which the transaction log is normally truncated on each automatic
checkpoint.
Since the checkpoint is issued when the size of the log becomes 70 percent
full, I'm thinking that if I create a small log file (1MB) and do not let it
grow then maybe the checkpoints will come quickly and so the log will never
grow very big. I'm assuming that doing this will mean the value for this
will be smaller than the value of "the number of log records reaches the
number SQL Server estimates it can process during the time specified in the
recovery interval option".
But if I do this I'm wondering what will happen in long transactions. BOL
says "The log may grow very large because the log cannot be truncated past
the MinLSN. This happens even if the database is using the simple recovery
model, in which the transaction log is normally truncated on each automatic
checkpoint." Do you think the log file will continue to grow even though
I've specified in database properties for it NOT to grow? If it does grow
for a large transaction it's ok. I'm assuming it will truncate when the
transactioin is finished. I just don't want the transaction to end before
it's finished because I've told it not to grow the transaction log.
One of the databases that we have has a table with about 55 million rows in
it. We add about 800,000 rows each month using a "select into" statement.
This is the table:
CREATE TABLE [tblDNCNational] (
[PHONE] [char] (10) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[STATE_FLAG] [char] (1) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[DATE_ENTERED] [smalldatetime] NULL
I don't know how big the transaction log would get by adding 800,000 rows
but I'm guessing that it would certainly exceed the 1MB size of the
tranaction log. So, I just want to be sure that the system will grow the log
file even though I've told it not to or it will truncate the file and keep
going. I could break the one transaction up into more transactions if
someone thinks that would help.
Any advice is appreciated,
DanI tested this and found out that I can't set the log file to 1M and then not
grow. A large transaction fills up the log. So, I have to let it grow.
However, under the simple recovery plan, the log file does truncate at the
end of every transaction. I'll probably do a shrinkfile every so often to
free up some storage room.
Dan
"Dan" <ddonahue@.archermalmo.com> wrote in message
news:ecv4FhCPEHA.2996@.TK2MSFTNGP12.phx.gbl...
> We're using SS2000. We do a lot of ETL (extract, transform, load) work and
> don't really need logs. From advice received here and from reading the
BOL,
> it looks like using the simple recovery plan would work best for us. I
found
> this in the BOL:
> a.. If the database is using the simple recovery model, an automatic
> checkpoint is generated whenever the number of log records reaches the
> lesser of these two values:
> a.. The log becomes 70 percent full.
> b.. The number of log records reaches the number SQL Server estimates it
> can process during the time specified in the recovery interval option.
> Automatic checkpoints truncate the unused portion of the transaction log
if
> the database is using the simple recovery model.
> Long-Running Transactions
> The active portion of the log must include every part of all uncommitted
> transactions. An application that starts a transaction and does not commit
> it or roll it back prevents SQL Server from advancing the MinLSN. This can
> cause two types of problems:
> a.. If the system is shut down after the transaction has performed many
> uncommitted modifications, the recovery phase of the subsequent restart
can
> take considerably longer than the amount of time specified in the recovery
> interval option.
>
> b.. The log may grow very large because the log cannot be truncated past
> the MinLSN. This happens even if the database is using the simple recovery
> model, in which the transaction log is normally truncated on each
automatic
> checkpoint.
> Since the checkpoint is issued when the size of the log becomes 70 percent
> full, I'm thinking that if I create a small log file (1MB) and do not let
it
> grow then maybe the checkpoints will come quickly and so the log will
never
> grow very big. I'm assuming that doing this will mean the value for this
> will be smaller than the value of "the number of log records reaches the
> number SQL Server estimates it can process during the time specified in
the
> recovery interval option".
> But if I do this I'm wondering what will happen in long transactions. BOL
> says "The log may grow very large because the log cannot be truncated past
> the MinLSN. This happens even if the database is using the simple recovery
> model, in which the transaction log is normally truncated on each
automatic
> checkpoint." Do you think the log file will continue to grow even though
> I've specified in database properties for it NOT to grow? If it does grow
> for a large transaction it's ok. I'm assuming it will truncate when the
> transactioin is finished. I just don't want the transaction to end before
> it's finished because I've told it not to grow the transaction log.
> One of the databases that we have has a table with about 55 million rows
in
> it. We add about 800,000 rows each month using a "select into" statement.
> This is the table:
> CREATE TABLE [tblDNCNational] (
> [PHONE] [char] (10) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
> [STATE_FLAG] [char] (1) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
> [DATE_ENTERED] [smalldatetime] NULL
> I don't know how big the transaction log would get by adding 800,000 rows
> but I'm guessing that it would certainly exceed the 1MB size of the
> tranaction log. So, I just want to be sure that the system will grow the
log
> file even though I've told it not to or it will truncate the file and keep
> going. I could break the one transaction up into more transactions if
> someone thinks that would help.
> Any advice is appreciated,
> Dan
>|||Dan,
Your load will fail if SQL Server cannot write to the log because its full.
You will get a transaction log full error and the transaction will get
rolled back. Why not just size the log to the biggest you think you will
need and leave it at that? Shrinking and growing the log will just fragment
the log file.
If you can do your work in smaller transactions, then all the better for
your log size. You could use an INSERT...SELECT statement with an
appropriate WHERE clause in a WHILE loop to do your batch inserts in smaller
steps.
However, bear in mind that you will lose transactional consistency. i.e. if
the load fails half way through, then only uncommitted transactions get
rolled back. My preferred approach would be to set your log file to a larger
size, you then retain transactional consistency. You say that you don't need
the logs, but you really do, so that SQL Server knows what to roll
back/forward in the event of a server failure.
--
Mark Allison, SQL Server MVP
http://www.markallison.co.uk
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
"Dan" <ddonahue@.archermalmo.com> wrote in message
news:ecv4FhCPEHA.2996@.TK2MSFTNGP12.phx.gbl...
> We're using SS2000. We do a lot of ETL (extract, transform, load) work and
> don't really need logs. From advice received here and from reading the
BOL,
> it looks like using the simple recovery plan would work best for us. I
found
> this in the BOL:
> a.. If the database is using the simple recovery model, an automatic
> checkpoint is generated whenever the number of log records reaches the
> lesser of these two values:
> a.. The log becomes 70 percent full.
> b.. The number of log records reaches the number SQL Server estimates it
> can process during the time specified in the recovery interval option.
> Automatic checkpoints truncate the unused portion of the transaction log
if
> the database is using the simple recovery model.
> Long-Running Transactions
> The active portion of the log must include every part of all uncommitted
> transactions. An application that starts a transaction and does not commit
> it or roll it back prevents SQL Server from advancing the MinLSN. This can
> cause two types of problems:
> a.. If the system is shut down after the transaction has performed many
> uncommitted modifications, the recovery phase of the subsequent restart
can
> take considerably longer than the amount of time specified in the recovery
> interval option.
>
> b.. The log may grow very large because the log cannot be truncated past
> the MinLSN. This happens even if the database is using the simple recovery
> model, in which the transaction log is normally truncated on each
automatic
> checkpoint.
> Since the checkpoint is issued when the size of the log becomes 70 percent
> full, I'm thinking that if I create a small log file (1MB) and do not let
it
> grow then maybe the checkpoints will come quickly and so the log will
never
> grow very big. I'm assuming that doing this will mean the value for this
> will be smaller than the value of "the number of log records reaches the
> number SQL Server estimates it can process during the time specified in
the
> recovery interval option".
> But if I do this I'm wondering what will happen in long transactions. BOL
> says "The log may grow very large because the log cannot be truncated past
> the MinLSN. This happens even if the database is using the simple recovery
> model, in which the transaction log is normally truncated on each
automatic
> checkpoint." Do you think the log file will continue to grow even though
> I've specified in database properties for it NOT to grow? If it does grow
> for a large transaction it's ok. I'm assuming it will truncate when the
> transactioin is finished. I just don't want the transaction to end before
> it's finished because I've told it not to grow the transaction log.
> One of the databases that we have has a table with about 55 million rows
in
> it. We add about 800,000 rows each month using a "select into" statement.
> This is the table:
> CREATE TABLE [tblDNCNational] (
> [PHONE] [char] (10) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
> [STATE_FLAG] [char] (1) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
> [DATE_ENTERED] [smalldatetime] NULL
> I don't know how big the transaction log would get by adding 800,000 rows
> but I'm guessing that it would certainly exceed the 1MB size of the
> tranaction log. So, I just want to be sure that the system will grow the
log
> file even though I've told it not to or it will truncate the file and keep
> going. I could break the one transaction up into more transactions if
> someone thinks that would help.
> Any advice is appreciated,
> Dan
>|||Hi Dan,
It is not advisable to restrict the growth of the Log file.
If you restrict the growth of the log file then, the active transactions
would be rolled back when the Log gets full, due to long running
transactions, and it is not able to expand it self to accomodate more
transaction.
Allow the log file to grow and you may set the recovery to simple, so that
the log is truncated on checkpoints.
HTH
Ashish
This posting is provided "AS IS" with no warranties, and confers no rights.
don't really need logs. From advice received here and from reading the BOL,
it looks like using the simple recovery plan would work best for us. I found
this in the BOL:
a.. If the database is using the simple recovery model, an automatic
checkpoint is generated whenever the number of log records reaches the
lesser of these two values:
a.. The log becomes 70 percent full.
b.. The number of log records reaches the number SQL Server estimates it
can process during the time specified in the recovery interval option.
Automatic checkpoints truncate the unused portion of the transaction log if
the database is using the simple recovery model.
Long-Running Transactions
The active portion of the log must include every part of all uncommitted
transactions. An application that starts a transaction and does not commit
it or roll it back prevents SQL Server from advancing the MinLSN. This can
cause two types of problems:
a.. If the system is shut down after the transaction has performed many
uncommitted modifications, the recovery phase of the subsequent restart can
take considerably longer than the amount of time specified in the recovery
interval option.
b.. The log may grow very large because the log cannot be truncated past
the MinLSN. This happens even if the database is using the simple recovery
model, in which the transaction log is normally truncated on each automatic
checkpoint.
Since the checkpoint is issued when the size of the log becomes 70 percent
full, I'm thinking that if I create a small log file (1MB) and do not let it
grow then maybe the checkpoints will come quickly and so the log will never
grow very big. I'm assuming that doing this will mean the value for this
will be smaller than the value of "the number of log records reaches the
number SQL Server estimates it can process during the time specified in the
recovery interval option".
But if I do this I'm wondering what will happen in long transactions. BOL
says "The log may grow very large because the log cannot be truncated past
the MinLSN. This happens even if the database is using the simple recovery
model, in which the transaction log is normally truncated on each automatic
checkpoint." Do you think the log file will continue to grow even though
I've specified in database properties for it NOT to grow? If it does grow
for a large transaction it's ok. I'm assuming it will truncate when the
transactioin is finished. I just don't want the transaction to end before
it's finished because I've told it not to grow the transaction log.
One of the databases that we have has a table with about 55 million rows in
it. We add about 800,000 rows each month using a "select into" statement.
This is the table:
CREATE TABLE [tblDNCNational] (
[PHONE] [char] (10) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[STATE_FLAG] [char] (1) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[DATE_ENTERED] [smalldatetime] NULL
I don't know how big the transaction log would get by adding 800,000 rows
but I'm guessing that it would certainly exceed the 1MB size of the
tranaction log. So, I just want to be sure that the system will grow the log
file even though I've told it not to or it will truncate the file and keep
going. I could break the one transaction up into more transactions if
someone thinks that would help.
Any advice is appreciated,
DanI tested this and found out that I can't set the log file to 1M and then not
grow. A large transaction fills up the log. So, I have to let it grow.
However, under the simple recovery plan, the log file does truncate at the
end of every transaction. I'll probably do a shrinkfile every so often to
free up some storage room.
Dan
"Dan" <ddonahue@.archermalmo.com> wrote in message
news:ecv4FhCPEHA.2996@.TK2MSFTNGP12.phx.gbl...
> We're using SS2000. We do a lot of ETL (extract, transform, load) work and
> don't really need logs. From advice received here and from reading the
BOL,
> it looks like using the simple recovery plan would work best for us. I
found
> this in the BOL:
> a.. If the database is using the simple recovery model, an automatic
> checkpoint is generated whenever the number of log records reaches the
> lesser of these two values:
> a.. The log becomes 70 percent full.
> b.. The number of log records reaches the number SQL Server estimates it
> can process during the time specified in the recovery interval option.
> Automatic checkpoints truncate the unused portion of the transaction log
if
> the database is using the simple recovery model.
> Long-Running Transactions
> The active portion of the log must include every part of all uncommitted
> transactions. An application that starts a transaction and does not commit
> it or roll it back prevents SQL Server from advancing the MinLSN. This can
> cause two types of problems:
> a.. If the system is shut down after the transaction has performed many
> uncommitted modifications, the recovery phase of the subsequent restart
can
> take considerably longer than the amount of time specified in the recovery
> interval option.
>
> b.. The log may grow very large because the log cannot be truncated past
> the MinLSN. This happens even if the database is using the simple recovery
> model, in which the transaction log is normally truncated on each
automatic
> checkpoint.
> Since the checkpoint is issued when the size of the log becomes 70 percent
> full, I'm thinking that if I create a small log file (1MB) and do not let
it
> grow then maybe the checkpoints will come quickly and so the log will
never
> grow very big. I'm assuming that doing this will mean the value for this
> will be smaller than the value of "the number of log records reaches the
> number SQL Server estimates it can process during the time specified in
the
> recovery interval option".
> But if I do this I'm wondering what will happen in long transactions. BOL
> says "The log may grow very large because the log cannot be truncated past
> the MinLSN. This happens even if the database is using the simple recovery
> model, in which the transaction log is normally truncated on each
automatic
> checkpoint." Do you think the log file will continue to grow even though
> I've specified in database properties for it NOT to grow? If it does grow
> for a large transaction it's ok. I'm assuming it will truncate when the
> transactioin is finished. I just don't want the transaction to end before
> it's finished because I've told it not to grow the transaction log.
> One of the databases that we have has a table with about 55 million rows
in
> it. We add about 800,000 rows each month using a "select into" statement.
> This is the table:
> CREATE TABLE [tblDNCNational] (
> [PHONE] [char] (10) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
> [STATE_FLAG] [char] (1) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
> [DATE_ENTERED] [smalldatetime] NULL
> I don't know how big the transaction log would get by adding 800,000 rows
> but I'm guessing that it would certainly exceed the 1MB size of the
> tranaction log. So, I just want to be sure that the system will grow the
log
> file even though I've told it not to or it will truncate the file and keep
> going. I could break the one transaction up into more transactions if
> someone thinks that would help.
> Any advice is appreciated,
> Dan
>|||Dan,
Your load will fail if SQL Server cannot write to the log because its full.
You will get a transaction log full error and the transaction will get
rolled back. Why not just size the log to the biggest you think you will
need and leave it at that? Shrinking and growing the log will just fragment
the log file.
If you can do your work in smaller transactions, then all the better for
your log size. You could use an INSERT...SELECT statement with an
appropriate WHERE clause in a WHILE loop to do your batch inserts in smaller
steps.
However, bear in mind that you will lose transactional consistency. i.e. if
the load fails half way through, then only uncommitted transactions get
rolled back. My preferred approach would be to set your log file to a larger
size, you then retain transactional consistency. You say that you don't need
the logs, but you really do, so that SQL Server knows what to roll
back/forward in the event of a server failure.
--
Mark Allison, SQL Server MVP
http://www.markallison.co.uk
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
"Dan" <ddonahue@.archermalmo.com> wrote in message
news:ecv4FhCPEHA.2996@.TK2MSFTNGP12.phx.gbl...
> We're using SS2000. We do a lot of ETL (extract, transform, load) work and
> don't really need logs. From advice received here and from reading the
BOL,
> it looks like using the simple recovery plan would work best for us. I
found
> this in the BOL:
> a.. If the database is using the simple recovery model, an automatic
> checkpoint is generated whenever the number of log records reaches the
> lesser of these two values:
> a.. The log becomes 70 percent full.
> b.. The number of log records reaches the number SQL Server estimates it
> can process during the time specified in the recovery interval option.
> Automatic checkpoints truncate the unused portion of the transaction log
if
> the database is using the simple recovery model.
> Long-Running Transactions
> The active portion of the log must include every part of all uncommitted
> transactions. An application that starts a transaction and does not commit
> it or roll it back prevents SQL Server from advancing the MinLSN. This can
> cause two types of problems:
> a.. If the system is shut down after the transaction has performed many
> uncommitted modifications, the recovery phase of the subsequent restart
can
> take considerably longer than the amount of time specified in the recovery
> interval option.
>
> b.. The log may grow very large because the log cannot be truncated past
> the MinLSN. This happens even if the database is using the simple recovery
> model, in which the transaction log is normally truncated on each
automatic
> checkpoint.
> Since the checkpoint is issued when the size of the log becomes 70 percent
> full, I'm thinking that if I create a small log file (1MB) and do not let
it
> grow then maybe the checkpoints will come quickly and so the log will
never
> grow very big. I'm assuming that doing this will mean the value for this
> will be smaller than the value of "the number of log records reaches the
> number SQL Server estimates it can process during the time specified in
the
> recovery interval option".
> But if I do this I'm wondering what will happen in long transactions. BOL
> says "The log may grow very large because the log cannot be truncated past
> the MinLSN. This happens even if the database is using the simple recovery
> model, in which the transaction log is normally truncated on each
automatic
> checkpoint." Do you think the log file will continue to grow even though
> I've specified in database properties for it NOT to grow? If it does grow
> for a large transaction it's ok. I'm assuming it will truncate when the
> transactioin is finished. I just don't want the transaction to end before
> it's finished because I've told it not to grow the transaction log.
> One of the databases that we have has a table with about 55 million rows
in
> it. We add about 800,000 rows each month using a "select into" statement.
> This is the table:
> CREATE TABLE [tblDNCNational] (
> [PHONE] [char] (10) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
> [STATE_FLAG] [char] (1) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
> [DATE_ENTERED] [smalldatetime] NULL
> I don't know how big the transaction log would get by adding 800,000 rows
> but I'm guessing that it would certainly exceed the 1MB size of the
> tranaction log. So, I just want to be sure that the system will grow the
log
> file even though I've told it not to or it will truncate the file and keep
> going. I could break the one transaction up into more transactions if
> someone thinks that would help.
> Any advice is appreciated,
> Dan
>|||Hi Dan,
It is not advisable to restrict the growth of the Log file.
If you restrict the growth of the log file then, the active transactions
would be rolled back when the Log gets full, due to long running
transactions, and it is not able to expand it self to accomodate more
transaction.
Allow the log file to grow and you may set the recovery to simple, so that
the log is truncated on checkpoints.
HTH
Ashish
This posting is provided "AS IS" with no warranties, and confers no rights.
Another licensing question
Hi,
I have a question about SQL Server plus user CALs. What exactly is meant by
"user"? Is it a person that logs into my application or is it a user id
specified in connecion string?
Can I have one user CAL for X people, that are accessing SQL server through
identical userid in connection string?
for example:
users: John [logged into MyApplication at PC1], Mark[logged into
MyApplication at PC2], Bob[logged into MyApplication at PC3]
MyApplication is installed on everybody's PC (that is there are three copies
of MyApplication (PC1 and PC2 and PC3)).
Each installation of MyApplication is using this connection string to access
SQL Server:
ConnStr = "User ID=DEP_1;Password=abc;Persist Security Info=True;Connection
Timeout=15;Data Source=XXX;Initial Catalog=YYY"
Can I have one user CAL for user DEP_1 or do I need three user CALs for all
three users?
Thanks!
Hi
You needs CALS for all 3 users.
DEP_1 is just a security user and does not count in for CALS.
Regards
Mike
"Marek" wrote:
> Hi,
> I have a question about SQL Server plus user CALs. What exactly is meant by
> "user"? Is it a person that logs into my application or is it a user id
> specified in connecion string?
> Can I have one user CAL for X people, that are accessing SQL server through
> identical userid in connection string?
> for example:
> users: John [logged into MyApplication at PC1], Mark[logged into
> MyApplication at PC2], Bob[logged into MyApplication at PC3]
> MyApplication is installed on everybody's PC (that is there are three copies
> of MyApplication (PC1 and PC2 and PC3)).
> Each installation of MyApplication is using this connection string to access
> SQL Server:
> ConnStr = "User ID=DEP_1;Password=abc;Persist Security Info=True;Connection
> Timeout=15;Data Source=XXX;Initial Catalog=YYY"
> Can I have one user CAL for user DEP_1 or do I need three user CALs for all
> three users?
> Thanks!
|||Thanks Mike for quick answer!
1. Does this mean, that user CAL is nothing more than a paper?
2. Is user CAL somehow entered into SQL Server licensing properties? (I
found only licensing per-seat (device CAL) or per processor in my SQL Server
licensing setup)
3. How will Server know, if there are more users accessing server than are
defined in server licensing properties? (I will have only one CAL for DEP_1
and server will never know, who is currently logged into MyApplication)
4. Is user CAL always "mapped" (=issued) to real person?
5. What if MyApplication from previous post will be a windows service with
no UI interraction [no user logs into it. It will run on background on three
PCs and process some results]. Could it use only one user CAL then?
Bweh, I know, silly questions, but I'm lost in all these licensing options.
Thanks!
"Mike Epprecht (SQL MVP)" wrote:
[vbcol=seagreen]
> Hi
> You needs CALS for all 3 users.
> DEP_1 is just a security user and does not count in for CALS.
> Regards
> Mike
> "Marek" wrote:
|||1. Yes, but if you don't follow the paper rules, you get very expensive
paperwork from Microsoft layers when they catch you.
2. On The server, go to Administrative Tools > Licensing
3. It does not know, but you are responsible. Point 2 can help you report on
it.
4. A CAL can be for a physical user or device and by the licensing terms, it
can only be transferred once to another user/device.
5. As long as the service does not get used by another program or service to
connect through it to the SQL Server (multiplexing)
http://www.microsoft.com/sql/howtobuy/default.asp
http://www.microsoft.com/sql/howtobuy/faq.asp
The CAL actually says a lot:
http://download.microsoft.com/downlo...A9/caleula.pdf
Regards
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"Marek" <Marek@.discussions.microsoft.com> wrote in message
news:F588172A-B890-4D60-962B-8B211B7CD9C8@.microsoft.com...
> Thanks Mike for quick answer!
> 1. Does this mean, that user CAL is nothing more than a paper?
> 2. Is user CAL somehow entered into SQL Server licensing properties? (I
> found only licensing per-seat (device CAL) or per processor in my SQL
Server
> licensing setup)
> 3. How will Server know, if there are more users accessing server than are
> defined in server licensing properties? (I will have only one CAL for
DEP_1
> and server will never know, who is currently logged into MyApplication)
> 4. Is user CAL always "mapped" (=issued) to real person?
> 5. What if MyApplication from previous post will be a windows service with
> no UI interraction [no user logs into it. It will run on background on
three
> PCs and process some results]. Could it use only one user CAL then?
> Bweh, I know, silly questions, but I'm lost in all these licensing
options.[vbcol=seagreen]
> Thanks!
> "Mike Epprecht (SQL MVP)" wrote:
meant by[vbcol=seagreen]
id[vbcol=seagreen]
through[vbcol=seagreen]
copies[vbcol=seagreen]
access[vbcol=seagreen]
Info=True;Connection[vbcol=seagreen]
for all[vbcol=seagreen]
|||Prior to one of the service packs, not 3 or 3a, the number of CALs
restricted the number of concurrent user connections. You'd get errors
similar to those you see in MSDE when you exceed 8. Since the service pack,
however, the concurrent connections is limited only by a sp_configure
setting. However, there is nothing but paper that says you can't run
Developer Edition in production, but, then, that's why the paper was
written. The U.S. Constitution is nothing but paper, but if they catch you,
there's all sorts of pleasures waiting for you and your wallet.
Sincerely,
Anthony Thomas
"Mike Epprecht (SQL MVP)" <mike@.epprecht.net> wrote in message
news:uYtjOLCyEHA.3976@.TK2MSFTNGP09.phx.gbl...
> 1. Yes, but if you don't follow the paper rules, you get very expensive
> paperwork from Microsoft layers when they catch you.
> 2. On The server, go to Administrative Tools > Licensing
> 3. It does not know, but you are responsible. Point 2 can help you report
on
> it.
> 4. A CAL can be for a physical user or device and by the licensing terms,
it
> can only be transferred once to another user/device.
> 5. As long as the service does not get used by another program or service
to
> connect through it to the SQL Server (multiplexing)
> http://www.microsoft.com/sql/howtobuy/default.asp
> http://www.microsoft.com/sql/howtobuy/faq.asp
> The CAL actually says a lot:
>
http://download.microsoft.com/downlo...A9/caleula.pdf[vbcol=seagreen]
> Regards
> --
> Mike Epprecht, Microsoft SQL Server MVP
> Zurich, Switzerland
> IM: mike@.epprecht.net
> MVP Program: http://www.microsoft.com/mvp
> Blog: http://www.msmvps.com/epprecht/
> "Marek" <Marek@.discussions.microsoft.com> wrote in message
> news:F588172A-B890-4D60-962B-8B211B7CD9C8@.microsoft.com...
> Server
are[vbcol=seagreen]
> DEP_1
with[vbcol=seagreen]
> three
> options.
> meant by
> id
> through
three[vbcol=seagreen]
> copies
to
> access
> Info=True;Connection
> for all
>
I have a question about SQL Server plus user CALs. What exactly is meant by
"user"? Is it a person that logs into my application or is it a user id
specified in connecion string?
Can I have one user CAL for X people, that are accessing SQL server through
identical userid in connection string?
for example:
users: John [logged into MyApplication at PC1], Mark[logged into
MyApplication at PC2], Bob[logged into MyApplication at PC3]
MyApplication is installed on everybody's PC (that is there are three copies
of MyApplication (PC1 and PC2 and PC3)).
Each installation of MyApplication is using this connection string to access
SQL Server:
ConnStr = "User ID=DEP_1;Password=abc;Persist Security Info=True;Connection
Timeout=15;Data Source=XXX;Initial Catalog=YYY"
Can I have one user CAL for user DEP_1 or do I need three user CALs for all
three users?
Thanks!
Hi
You needs CALS for all 3 users.
DEP_1 is just a security user and does not count in for CALS.
Regards
Mike
"Marek" wrote:
> Hi,
> I have a question about SQL Server plus user CALs. What exactly is meant by
> "user"? Is it a person that logs into my application or is it a user id
> specified in connecion string?
> Can I have one user CAL for X people, that are accessing SQL server through
> identical userid in connection string?
> for example:
> users: John [logged into MyApplication at PC1], Mark[logged into
> MyApplication at PC2], Bob[logged into MyApplication at PC3]
> MyApplication is installed on everybody's PC (that is there are three copies
> of MyApplication (PC1 and PC2 and PC3)).
> Each installation of MyApplication is using this connection string to access
> SQL Server:
> ConnStr = "User ID=DEP_1;Password=abc;Persist Security Info=True;Connection
> Timeout=15;Data Source=XXX;Initial Catalog=YYY"
> Can I have one user CAL for user DEP_1 or do I need three user CALs for all
> three users?
> Thanks!
|||Thanks Mike for quick answer!
1. Does this mean, that user CAL is nothing more than a paper?
2. Is user CAL somehow entered into SQL Server licensing properties? (I
found only licensing per-seat (device CAL) or per processor in my SQL Server
licensing setup)
3. How will Server know, if there are more users accessing server than are
defined in server licensing properties? (I will have only one CAL for DEP_1
and server will never know, who is currently logged into MyApplication)
4. Is user CAL always "mapped" (=issued) to real person?
5. What if MyApplication from previous post will be a windows service with
no UI interraction [no user logs into it. It will run on background on three
PCs and process some results]. Could it use only one user CAL then?
Bweh, I know, silly questions, but I'm lost in all these licensing options.
Thanks!
"Mike Epprecht (SQL MVP)" wrote:
[vbcol=seagreen]
> Hi
> You needs CALS for all 3 users.
> DEP_1 is just a security user and does not count in for CALS.
> Regards
> Mike
> "Marek" wrote:
|||1. Yes, but if you don't follow the paper rules, you get very expensive
paperwork from Microsoft layers when they catch you.
2. On The server, go to Administrative Tools > Licensing
3. It does not know, but you are responsible. Point 2 can help you report on
it.
4. A CAL can be for a physical user or device and by the licensing terms, it
can only be transferred once to another user/device.
5. As long as the service does not get used by another program or service to
connect through it to the SQL Server (multiplexing)
http://www.microsoft.com/sql/howtobuy/default.asp
http://www.microsoft.com/sql/howtobuy/faq.asp
The CAL actually says a lot:
http://download.microsoft.com/downlo...A9/caleula.pdf
Regards
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"Marek" <Marek@.discussions.microsoft.com> wrote in message
news:F588172A-B890-4D60-962B-8B211B7CD9C8@.microsoft.com...
> Thanks Mike for quick answer!
> 1. Does this mean, that user CAL is nothing more than a paper?
> 2. Is user CAL somehow entered into SQL Server licensing properties? (I
> found only licensing per-seat (device CAL) or per processor in my SQL
Server
> licensing setup)
> 3. How will Server know, if there are more users accessing server than are
> defined in server licensing properties? (I will have only one CAL for
DEP_1
> and server will never know, who is currently logged into MyApplication)
> 4. Is user CAL always "mapped" (=issued) to real person?
> 5. What if MyApplication from previous post will be a windows service with
> no UI interraction [no user logs into it. It will run on background on
three
> PCs and process some results]. Could it use only one user CAL then?
> Bweh, I know, silly questions, but I'm lost in all these licensing
options.[vbcol=seagreen]
> Thanks!
> "Mike Epprecht (SQL MVP)" wrote:
meant by[vbcol=seagreen]
id[vbcol=seagreen]
through[vbcol=seagreen]
copies[vbcol=seagreen]
access[vbcol=seagreen]
Info=True;Connection[vbcol=seagreen]
for all[vbcol=seagreen]
|||Prior to one of the service packs, not 3 or 3a, the number of CALs
restricted the number of concurrent user connections. You'd get errors
similar to those you see in MSDE when you exceed 8. Since the service pack,
however, the concurrent connections is limited only by a sp_configure
setting. However, there is nothing but paper that says you can't run
Developer Edition in production, but, then, that's why the paper was
written. The U.S. Constitution is nothing but paper, but if they catch you,
there's all sorts of pleasures waiting for you and your wallet.
Sincerely,
Anthony Thomas
"Mike Epprecht (SQL MVP)" <mike@.epprecht.net> wrote in message
news:uYtjOLCyEHA.3976@.TK2MSFTNGP09.phx.gbl...
> 1. Yes, but if you don't follow the paper rules, you get very expensive
> paperwork from Microsoft layers when they catch you.
> 2. On The server, go to Administrative Tools > Licensing
> 3. It does not know, but you are responsible. Point 2 can help you report
on
> it.
> 4. A CAL can be for a physical user or device and by the licensing terms,
it
> can only be transferred once to another user/device.
> 5. As long as the service does not get used by another program or service
to
> connect through it to the SQL Server (multiplexing)
> http://www.microsoft.com/sql/howtobuy/default.asp
> http://www.microsoft.com/sql/howtobuy/faq.asp
> The CAL actually says a lot:
>
http://download.microsoft.com/downlo...A9/caleula.pdf[vbcol=seagreen]
> Regards
> --
> Mike Epprecht, Microsoft SQL Server MVP
> Zurich, Switzerland
> IM: mike@.epprecht.net
> MVP Program: http://www.microsoft.com/mvp
> Blog: http://www.msmvps.com/epprecht/
> "Marek" <Marek@.discussions.microsoft.com> wrote in message
> news:F588172A-B890-4D60-962B-8B211B7CD9C8@.microsoft.com...
> Server
are[vbcol=seagreen]
> DEP_1
with[vbcol=seagreen]
> three
> options.
> meant by
> id
> through
three[vbcol=seagreen]
> copies
to
> access
> Info=True;Connection
> for all
>
Another licensing question
Hi,
I have a question about SQL Server plus user CALs. What exactly is meant by
"user"? Is it a person that logs into my application or is it a user id
specified in connecion string?
Can I have one user CAL for X people, that are accessing SQL server through
identical userid in connection string?
for example:
users: John [logged into MyApplication at PC1], Mark[logged into
MyApplication at PC2], Bob[logged into MyApplication at PC3]
MyApplication is installed on everybody's PC (that is there are three copies
of MyApplication (PC1 and PC2 and PC3)).
Each installation of MyApplication is using this connection string to access
SQL Server:
ConnStr = "User ID=DEP_1;Password=abc;Persist Security Info=True;Connection
Timeout=15;Data Source=XXX;Initial Catalog=YYY"
Can I have one user CAL for user DEP_1 or do I need three user CALs for all
three users?
Thanks!Hi
You needs CALS for all 3 users.
DEP_1 is just a security user and does not count in for CALS.
Regards
Mike
"Marek" wrote:
> Hi,
> I have a question about SQL Server plus user CALs. What exactly is meant b
y
> "user"? Is it a person that logs into my application or is it a user id
> specified in connecion string?
> Can I have one user CAL for X people, that are accessing SQL server throug
h
> identical userid in connection string?
> for example:
> users: John [logged into MyApplication at PC1], Mark[logged into
> MyApplication at PC2], Bob[logged into MyApplication at PC3]
> MyApplication is installed on everybody's PC (that is there are three copi
es
> of MyApplication (PC1 and PC2 and PC3)).
> Each installation of MyApplication is using this connection string to acce
ss
> SQL Server:
> ConnStr = "User ID=DEP_1;Password=abc;Persist Security Info=True;Connectio
n
> Timeout=15;Data Source=XXX;Initial Catalog=YYY"
> Can I have one user CAL for user DEP_1 or do I need three user CALs for al
l
> three users?
> Thanks!|||Thanks Mike for quick answer!
1. Does this mean, that user CAL is nothing more than a paper?
2. Is user CAL somehow entered into SQL Server licensing properties? (I
found only licensing per-seat (device CAL) or per processor in my SQL Server
licensing setup)
3. How will Server know, if there are more users accessing server than are
defined in server licensing properties? (I will have only one CAL for DEP_1
and server will never know, who is currently logged into MyApplication)
4. Is user CAL always "mapped" (=issued) to real person?
5. What if MyApplication from previous post will be a windows service with
no UI interraction [no user logs into it. It will run on background on t
hree
PCs and process some results]. Could it use only one user CAL then?
Bweh, I know, silly questions, but I'm lost in all these licensing options.
Thanks!
"Mike Epprecht (SQL MVP)" wrote:
[vbcol=seagreen]
> Hi
> You needs CALS for all 3 users.
> DEP_1 is just a security user and does not count in for CALS.
> Regards
> Mike
> "Marek" wrote:
>|||1. Yes, but if you don't follow the paper rules, you get very expensive
paperwork from Microsoft layers when they catch you.
2. On The server, go to Administrative Tools > Licensing
3. It does not know, but you are responsible. Point 2 can help you report on
it.
4. A CAL can be for a physical user or device and by the licensing terms, it
can only be transferred once to another user/device.
5. As long as the service does not get used by another program or service to
connect through it to the SQL Server (multiplexing)
http://www.microsoft.com/sql/howtobuy/default.asp
http://www.microsoft.com/sql/howtobuy/faq.asp
The CAL actually says a lot:
http://download.microsoft.com/downl.../>
caleula.pdf
Regards
--
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"Marek" <Marek@.discussions.microsoft.com> wrote in message
news:F588172A-B890-4D60-962B-8B211B7CD9C8@.microsoft.com...
> Thanks Mike for quick answer!
> 1. Does this mean, that user CAL is nothing more than a paper?
> 2. Is user CAL somehow entered into SQL Server licensing properties? (I
> found only licensing per-seat (device CAL) or per processor in my SQL
Server
> licensing setup)
> 3. How will Server know, if there are more users accessing server than are
> defined in server licensing properties? (I will have only one CAL for
DEP_1
> and server will never know, who is currently logged into MyApplication)
> 4. Is user CAL always "mapped" (=issued) to real person?
> 5. What if MyApplication from previous post will be a windows service with
> no UI interraction [no user logs into it. It will run on background on
three
> PCs and process some results]. Could it use only one user CAL then?
> Bweh, I know, silly questions, but I'm lost in all these licensing
options.[vbcol=seagreen]
> Thanks!
> "Mike Epprecht (SQL MVP)" wrote:
>
meant by[vbcol=seagreen]
id[vbcol=seagreen]
through[vbcol=seagreen]
copies[vbcol=seagreen]
access[vbcol=seagreen]
Info=True;Connection[vbcol=seagreen]
for all[vbcol=seagreen]|||Prior to one of the service packs, not 3 or 3a, the number of CALs
restricted the number of concurrent user connections. You'd get errors
similar to those you see in MSDE when you exceed 8. Since the service pack,
however, the concurrent connections is limited only by a sp_configure
setting. However, there is nothing but paper that says you can't run
Developer Edition in production, but, then, that's why the paper was
written. The U.S. Constitution is nothing but paper, but if they catch you,
there's all sorts of pleasures waiting for you and your wallet.
Sincerely,
Anthony Thomas
"Mike Epprecht (SQL MVP)" <mike@.epprecht.net> wrote in message
news:uYtjOLCyEHA.3976@.TK2MSFTNGP09.phx.gbl...
> 1. Yes, but if you don't follow the paper rules, you get very expensive
> paperwork from Microsoft layers when they catch you.
> 2. On The server, go to Administrative Tools > Licensing
> 3. It does not know, but you are responsible. Point 2 can help you report
on
> it.
> 4. A CAL can be for a physical user or device and by the licensing terms,
it
> can only be transferred once to another user/device.
> 5. As long as the service does not get used by another program or service
to
> connect through it to the SQL Server (multiplexing)
> http://www.microsoft.com/sql/howtobuy/default.asp
> http://www.microsoft.com/sql/howtobuy/faq.asp
> The CAL actually says a lot:
>
> Regards
> --
> Mike Epprecht, Microsoft SQL Server MVP
> Zurich, Switzerland
> IM: mike@.epprecht.net
> MVP Program: [url]http://www.microsoft.com/mvp" target="_blank">http://download.microsoft.com/downl...crosoft.com/mvp
> Blog: http://www.msmvps.com/epprecht/
> "Marek" <Marek@.discussions.microsoft.com> wrote in message
> news:F588172A-B890-4D60-962B-8B211B7CD9C8@.microsoft.com...
> Server
are[vbcol=seagreen]
> DEP_1
with[vbcol=seagreen]
> three
> options.
> meant by
> id
> through
three[vbcol=seagreen]
> copies
to[vbcol=seagreen]
> access
> Info=True;Connection
> for all
>
I have a question about SQL Server plus user CALs. What exactly is meant by
"user"? Is it a person that logs into my application or is it a user id
specified in connecion string?
Can I have one user CAL for X people, that are accessing SQL server through
identical userid in connection string?
for example:
users: John [logged into MyApplication at PC1], Mark[logged into
MyApplication at PC2], Bob[logged into MyApplication at PC3]
MyApplication is installed on everybody's PC (that is there are three copies
of MyApplication (PC1 and PC2 and PC3)).
Each installation of MyApplication is using this connection string to access
SQL Server:
ConnStr = "User ID=DEP_1;Password=abc;Persist Security Info=True;Connection
Timeout=15;Data Source=XXX;Initial Catalog=YYY"
Can I have one user CAL for user DEP_1 or do I need three user CALs for all
three users?
Thanks!Hi
You needs CALS for all 3 users.
DEP_1 is just a security user and does not count in for CALS.
Regards
Mike
"Marek" wrote:
> Hi,
> I have a question about SQL Server plus user CALs. What exactly is meant b
y
> "user"? Is it a person that logs into my application or is it a user id
> specified in connecion string?
> Can I have one user CAL for X people, that are accessing SQL server throug
h
> identical userid in connection string?
> for example:
> users: John [logged into MyApplication at PC1], Mark[logged into
> MyApplication at PC2], Bob[logged into MyApplication at PC3]
> MyApplication is installed on everybody's PC (that is there are three copi
es
> of MyApplication (PC1 and PC2 and PC3)).
> Each installation of MyApplication is using this connection string to acce
ss
> SQL Server:
> ConnStr = "User ID=DEP_1;Password=abc;Persist Security Info=True;Connectio
n
> Timeout=15;Data Source=XXX;Initial Catalog=YYY"
> Can I have one user CAL for user DEP_1 or do I need three user CALs for al
l
> three users?
> Thanks!|||Thanks Mike for quick answer!
1. Does this mean, that user CAL is nothing more than a paper?
2. Is user CAL somehow entered into SQL Server licensing properties? (I
found only licensing per-seat (device CAL) or per processor in my SQL Server
licensing setup)
3. How will Server know, if there are more users accessing server than are
defined in server licensing properties? (I will have only one CAL for DEP_1
and server will never know, who is currently logged into MyApplication)
4. Is user CAL always "mapped" (=issued) to real person?
5. What if MyApplication from previous post will be a windows service with
no UI interraction [no user logs into it. It will run on background on t
hree
PCs and process some results]. Could it use only one user CAL then?
Bweh, I know, silly questions, but I'm lost in all these licensing options.
Thanks!
"Mike Epprecht (SQL MVP)" wrote:
[vbcol=seagreen]
> Hi
> You needs CALS for all 3 users.
> DEP_1 is just a security user and does not count in for CALS.
> Regards
> Mike
> "Marek" wrote:
>|||1. Yes, but if you don't follow the paper rules, you get very expensive
paperwork from Microsoft layers when they catch you.
2. On The server, go to Administrative Tools > Licensing
3. It does not know, but you are responsible. Point 2 can help you report on
it.
4. A CAL can be for a physical user or device and by the licensing terms, it
can only be transferred once to another user/device.
5. As long as the service does not get used by another program or service to
connect through it to the SQL Server (multiplexing)
http://www.microsoft.com/sql/howtobuy/default.asp
http://www.microsoft.com/sql/howtobuy/faq.asp
The CAL actually says a lot:
http://download.microsoft.com/downl.../>
caleula.pdf
Regards
--
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"Marek" <Marek@.discussions.microsoft.com> wrote in message
news:F588172A-B890-4D60-962B-8B211B7CD9C8@.microsoft.com...
> Thanks Mike for quick answer!
> 1. Does this mean, that user CAL is nothing more than a paper?
> 2. Is user CAL somehow entered into SQL Server licensing properties? (I
> found only licensing per-seat (device CAL) or per processor in my SQL
Server
> licensing setup)
> 3. How will Server know, if there are more users accessing server than are
> defined in server licensing properties? (I will have only one CAL for
DEP_1
> and server will never know, who is currently logged into MyApplication)
> 4. Is user CAL always "mapped" (=issued) to real person?
> 5. What if MyApplication from previous post will be a windows service with
> no UI interraction [no user logs into it. It will run on background on
three
> PCs and process some results]. Could it use only one user CAL then?
> Bweh, I know, silly questions, but I'm lost in all these licensing
options.[vbcol=seagreen]
> Thanks!
> "Mike Epprecht (SQL MVP)" wrote:
>
meant by[vbcol=seagreen]
id[vbcol=seagreen]
through[vbcol=seagreen]
copies[vbcol=seagreen]
access[vbcol=seagreen]
Info=True;Connection[vbcol=seagreen]
for all[vbcol=seagreen]|||Prior to one of the service packs, not 3 or 3a, the number of CALs
restricted the number of concurrent user connections. You'd get errors
similar to those you see in MSDE when you exceed 8. Since the service pack,
however, the concurrent connections is limited only by a sp_configure
setting. However, there is nothing but paper that says you can't run
Developer Edition in production, but, then, that's why the paper was
written. The U.S. Constitution is nothing but paper, but if they catch you,
there's all sorts of pleasures waiting for you and your wallet.
Sincerely,
Anthony Thomas
"Mike Epprecht (SQL MVP)" <mike@.epprecht.net> wrote in message
news:uYtjOLCyEHA.3976@.TK2MSFTNGP09.phx.gbl...
> 1. Yes, but if you don't follow the paper rules, you get very expensive
> paperwork from Microsoft layers when they catch you.
> 2. On The server, go to Administrative Tools > Licensing
> 3. It does not know, but you are responsible. Point 2 can help you report
on
> it.
> 4. A CAL can be for a physical user or device and by the licensing terms,
it
> can only be transferred once to another user/device.
> 5. As long as the service does not get used by another program or service
to
> connect through it to the SQL Server (multiplexing)
> http://www.microsoft.com/sql/howtobuy/default.asp
> http://www.microsoft.com/sql/howtobuy/faq.asp
> The CAL actually says a lot:
>
> Regards
> --
> Mike Epprecht, Microsoft SQL Server MVP
> Zurich, Switzerland
> IM: mike@.epprecht.net
> MVP Program: [url]http://www.microsoft.com/mvp" target="_blank">http://download.microsoft.com/downl...crosoft.com/mvp
> Blog: http://www.msmvps.com/epprecht/
> "Marek" <Marek@.discussions.microsoft.com> wrote in message
> news:F588172A-B890-4D60-962B-8B211B7CD9C8@.microsoft.com...
> Server
are[vbcol=seagreen]
> DEP_1
with[vbcol=seagreen]
> three
> options.
> meant by
> id
> through
three[vbcol=seagreen]
> copies
to[vbcol=seagreen]
> access
> Info=True;Connection
> for all
>
Another licensing question
Hi,
I have a question about SQL Server plus user CALs. What exactly is meant by
"user"? Is it a person that logs into my application or is it a user id
specified in connecion string?
Can I have one user CAL for X people, that are accessing SQL server through
identical userid in connection string?
for example:
users: John [logged into MyApplication at PC1], Mark[logged into
MyApplication at PC2], Bob[logged into MyApplication at PC3]
MyApplication is installed on everybody's PC (that is there are three copies
of MyApplication (PC1 and PC2 and PC3)).
Each installation of MyApplication is using this connection string to access
SQL Server:
ConnStr = "User ID=DEP_1;Password=abc;Persist Security Info=True;Connection
Timeout=15;Data Source=XXX;Initial Catalog=YYY"
Can I have one user CAL for user DEP_1 or do I need three user CALs for all
three users?
Thanks!Hi
You needs CALS for all 3 users.
DEP_1 is just a security user and does not count in for CALS.
Regards
Mike
"Marek" wrote:
> Hi,
> I have a question about SQL Server plus user CALs. What exactly is meant by
> "user"? Is it a person that logs into my application or is it a user id
> specified in connecion string?
> Can I have one user CAL for X people, that are accessing SQL server through
> identical userid in connection string?
> for example:
> users: John [logged into MyApplication at PC1], Mark[logged into
> MyApplication at PC2], Bob[logged into MyApplication at PC3]
> MyApplication is installed on everybody's PC (that is there are three copies
> of MyApplication (PC1 and PC2 and PC3)).
> Each installation of MyApplication is using this connection string to access
> SQL Server:
> ConnStr = "User ID=DEP_1;Password=abc;Persist Security Info=True;Connection
> Timeout=15;Data Source=XXX;Initial Catalog=YYY"
> Can I have one user CAL for user DEP_1 or do I need three user CALs for all
> three users?
> Thanks!|||Thanks Mike for quick answer!
1. Does this mean, that user CAL is nothing more than a paper?
2. Is user CAL somehow entered into SQL Server licensing properties? (I
found only licensing per-seat (device CAL) or per processor in my SQL Server
licensing setup)
3. How will Server know, if there are more users accessing server than are
defined in server licensing properties? (I will have only one CAL for DEP_1
and server will never know, who is currently logged into MyApplication)
4. Is user CAL always "mapped" (=issued) to real person?
5. What if MyApplication from previous post will be a windows service with
no UI interraction [no user logs into it. It will run on background on three
PCs and process some results]. Could it use only one user CAL then?
Bweh, I know, silly questions, but I'm lost in all these licensing options.
Thanks!
"Mike Epprecht (SQL MVP)" wrote:
> Hi
> You needs CALS for all 3 users.
> DEP_1 is just a security user and does not count in for CALS.
> Regards
> Mike
> "Marek" wrote:
> > Hi,
> >
> > I have a question about SQL Server plus user CALs. What exactly is meant by
> > "user"? Is it a person that logs into my application or is it a user id
> > specified in connecion string?
> >
> > Can I have one user CAL for X people, that are accessing SQL server through
> > identical userid in connection string?
> >
> > for example:
> >
> > users: John [logged into MyApplication at PC1], Mark[logged into
> > MyApplication at PC2], Bob[logged into MyApplication at PC3]
> >
> > MyApplication is installed on everybody's PC (that is there are three copies
> > of MyApplication (PC1 and PC2 and PC3)).
> >
> > Each installation of MyApplication is using this connection string to access
> > SQL Server:
> >
> > ConnStr = "User ID=DEP_1;Password=abc;Persist Security Info=True;Connection
> > Timeout=15;Data Source=XXX;Initial Catalog=YYY"
> >
> > Can I have one user CAL for user DEP_1 or do I need three user CALs for all
> > three users?
> >
> > Thanks!|||1. Yes, but if you don't follow the paper rules, you get very expensive
paperwork from Microsoft layers when they catch you.
2. On The server, go to Administrative Tools > Licensing
3. It does not know, but you are responsible. Point 2 can help you report on
it.
4. A CAL can be for a physical user or device and by the licensing terms, it
can only be transferred once to another user/device.
5. As long as the service does not get used by another program or service to
connect through it to the SQL Server (multiplexing)
http://www.microsoft.com/sql/howtobuy/default.asp
http://www.microsoft.com/sql/howtobuy/faq.asp
The CAL actually says a lot:
http://download.microsoft.com/download/5/E/7/5E7B79D4-90B8-4A3D-B964-8A72F49A21A9/caleula.pdf
Regards
--
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"Marek" <Marek@.discussions.microsoft.com> wrote in message
news:F588172A-B890-4D60-962B-8B211B7CD9C8@.microsoft.com...
> Thanks Mike for quick answer!
> 1. Does this mean, that user CAL is nothing more than a paper?
> 2. Is user CAL somehow entered into SQL Server licensing properties? (I
> found only licensing per-seat (device CAL) or per processor in my SQL
Server
> licensing setup)
> 3. How will Server know, if there are more users accessing server than are
> defined in server licensing properties? (I will have only one CAL for
DEP_1
> and server will never know, who is currently logged into MyApplication)
> 4. Is user CAL always "mapped" (=issued) to real person?
> 5. What if MyApplication from previous post will be a windows service with
> no UI interraction [no user logs into it. It will run on background on
three
> PCs and process some results]. Could it use only one user CAL then?
> Bweh, I know, silly questions, but I'm lost in all these licensing
options.
> Thanks!
> "Mike Epprecht (SQL MVP)" wrote:
> > Hi
> >
> > You needs CALS for all 3 users.
> > DEP_1 is just a security user and does not count in for CALS.
> >
> > Regards
> > Mike
> >
> > "Marek" wrote:
> >
> > > Hi,
> > >
> > > I have a question about SQL Server plus user CALs. What exactly is
meant by
> > > "user"? Is it a person that logs into my application or is it a user
id
> > > specified in connecion string?
> > >
> > > Can I have one user CAL for X people, that are accessing SQL server
through
> > > identical userid in connection string?
> > >
> > > for example:
> > >
> > > users: John [logged into MyApplication at PC1], Mark[logged into
> > > MyApplication at PC2], Bob[logged into MyApplication at PC3]
> > >
> > > MyApplication is installed on everybody's PC (that is there are three
copies
> > > of MyApplication (PC1 and PC2 and PC3)).
> > >
> > > Each installation of MyApplication is using this connection string to
access
> > > SQL Server:
> > >
> > > ConnStr = "User ID=DEP_1;Password=abc;Persist Security
Info=True;Connection
> > > Timeout=15;Data Source=XXX;Initial Catalog=YYY"
> > >
> > > Can I have one user CAL for user DEP_1 or do I need three user CALs
for all
> > > three users?
> > >
> > > Thanks!|||Prior to one of the service packs, not 3 or 3a, the number of CALs
restricted the number of concurrent user connections. You'd get errors
similar to those you see in MSDE when you exceed 8. Since the service pack,
however, the concurrent connections is limited only by a sp_configure
setting. However, there is nothing but paper that says you can't run
Developer Edition in production, but, then, that's why the paper was
written. The U.S. Constitution is nothing but paper, but if they catch you,
there's all sorts of pleasures waiting for you and your wallet.
Sincerely,
Anthony Thomas
"Mike Epprecht (SQL MVP)" <mike@.epprecht.net> wrote in message
news:uYtjOLCyEHA.3976@.TK2MSFTNGP09.phx.gbl...
> 1. Yes, but if you don't follow the paper rules, you get very expensive
> paperwork from Microsoft layers when they catch you.
> 2. On The server, go to Administrative Tools > Licensing
> 3. It does not know, but you are responsible. Point 2 can help you report
on
> it.
> 4. A CAL can be for a physical user or device and by the licensing terms,
it
> can only be transferred once to another user/device.
> 5. As long as the service does not get used by another program or service
to
> connect through it to the SQL Server (multiplexing)
> http://www.microsoft.com/sql/howtobuy/default.asp
> http://www.microsoft.com/sql/howtobuy/faq.asp
> The CAL actually says a lot:
>
http://download.microsoft.com/download/5/E/7/5E7B79D4-90B8-4A3D-B964-8A72F49A21A9/caleula.pdf
> Regards
> --
> Mike Epprecht, Microsoft SQL Server MVP
> Zurich, Switzerland
> IM: mike@.epprecht.net
> MVP Program: http://www.microsoft.com/mvp
> Blog: http://www.msmvps.com/epprecht/
> "Marek" <Marek@.discussions.microsoft.com> wrote in message
> news:F588172A-B890-4D60-962B-8B211B7CD9C8@.microsoft.com...
> > Thanks Mike for quick answer!
> >
> > 1. Does this mean, that user CAL is nothing more than a paper?
> >
> > 2. Is user CAL somehow entered into SQL Server licensing properties? (I
> > found only licensing per-seat (device CAL) or per processor in my SQL
> Server
> > licensing setup)
> >
> > 3. How will Server know, if there are more users accessing server than
are
> > defined in server licensing properties? (I will have only one CAL for
> DEP_1
> > and server will never know, who is currently logged into MyApplication)
> >
> > 4. Is user CAL always "mapped" (=issued) to real person?
> >
> > 5. What if MyApplication from previous post will be a windows service
with
> > no UI interraction [no user logs into it. It will run on background on
> three
> > PCs and process some results]. Could it use only one user CAL then?
> >
> > Bweh, I know, silly questions, but I'm lost in all these licensing
> options.
> >
> > Thanks!
> >
> > "Mike Epprecht (SQL MVP)" wrote:
> >
> > > Hi
> > >
> > > You needs CALS for all 3 users.
> > > DEP_1 is just a security user and does not count in for CALS.
> > >
> > > Regards
> > > Mike
> > >
> > > "Marek" wrote:
> > >
> > > > Hi,
> > > >
> > > > I have a question about SQL Server plus user CALs. What exactly is
> meant by
> > > > "user"? Is it a person that logs into my application or is it a user
> id
> > > > specified in connecion string?
> > > >
> > > > Can I have one user CAL for X people, that are accessing SQL server
> through
> > > > identical userid in connection string?
> > > >
> > > > for example:
> > > >
> > > > users: John [logged into MyApplication at PC1], Mark[logged into
> > > > MyApplication at PC2], Bob[logged into MyApplication at PC3]
> > > >
> > > > MyApplication is installed on everybody's PC (that is there are
three
> copies
> > > > of MyApplication (PC1 and PC2 and PC3)).
> > > >
> > > > Each installation of MyApplication is using this connection string
to
> access
> > > > SQL Server:
> > > >
> > > > ConnStr = "User ID=DEP_1;Password=abc;Persist Security
> Info=True;Connection
> > > > Timeout=15;Data Source=XXX;Initial Catalog=YYY"
> > > >
> > > > Can I have one user CAL for user DEP_1 or do I need three user CALs
> for all
> > > > three users?
> > > >
> > > > Thanks!
>
I have a question about SQL Server plus user CALs. What exactly is meant by
"user"? Is it a person that logs into my application or is it a user id
specified in connecion string?
Can I have one user CAL for X people, that are accessing SQL server through
identical userid in connection string?
for example:
users: John [logged into MyApplication at PC1], Mark[logged into
MyApplication at PC2], Bob[logged into MyApplication at PC3]
MyApplication is installed on everybody's PC (that is there are three copies
of MyApplication (PC1 and PC2 and PC3)).
Each installation of MyApplication is using this connection string to access
SQL Server:
ConnStr = "User ID=DEP_1;Password=abc;Persist Security Info=True;Connection
Timeout=15;Data Source=XXX;Initial Catalog=YYY"
Can I have one user CAL for user DEP_1 or do I need three user CALs for all
three users?
Thanks!Hi
You needs CALS for all 3 users.
DEP_1 is just a security user and does not count in for CALS.
Regards
Mike
"Marek" wrote:
> Hi,
> I have a question about SQL Server plus user CALs. What exactly is meant by
> "user"? Is it a person that logs into my application or is it a user id
> specified in connecion string?
> Can I have one user CAL for X people, that are accessing SQL server through
> identical userid in connection string?
> for example:
> users: John [logged into MyApplication at PC1], Mark[logged into
> MyApplication at PC2], Bob[logged into MyApplication at PC3]
> MyApplication is installed on everybody's PC (that is there are three copies
> of MyApplication (PC1 and PC2 and PC3)).
> Each installation of MyApplication is using this connection string to access
> SQL Server:
> ConnStr = "User ID=DEP_1;Password=abc;Persist Security Info=True;Connection
> Timeout=15;Data Source=XXX;Initial Catalog=YYY"
> Can I have one user CAL for user DEP_1 or do I need three user CALs for all
> three users?
> Thanks!|||Thanks Mike for quick answer!
1. Does this mean, that user CAL is nothing more than a paper?
2. Is user CAL somehow entered into SQL Server licensing properties? (I
found only licensing per-seat (device CAL) or per processor in my SQL Server
licensing setup)
3. How will Server know, if there are more users accessing server than are
defined in server licensing properties? (I will have only one CAL for DEP_1
and server will never know, who is currently logged into MyApplication)
4. Is user CAL always "mapped" (=issued) to real person?
5. What if MyApplication from previous post will be a windows service with
no UI interraction [no user logs into it. It will run on background on three
PCs and process some results]. Could it use only one user CAL then?
Bweh, I know, silly questions, but I'm lost in all these licensing options.
Thanks!
"Mike Epprecht (SQL MVP)" wrote:
> Hi
> You needs CALS for all 3 users.
> DEP_1 is just a security user and does not count in for CALS.
> Regards
> Mike
> "Marek" wrote:
> > Hi,
> >
> > I have a question about SQL Server plus user CALs. What exactly is meant by
> > "user"? Is it a person that logs into my application or is it a user id
> > specified in connecion string?
> >
> > Can I have one user CAL for X people, that are accessing SQL server through
> > identical userid in connection string?
> >
> > for example:
> >
> > users: John [logged into MyApplication at PC1], Mark[logged into
> > MyApplication at PC2], Bob[logged into MyApplication at PC3]
> >
> > MyApplication is installed on everybody's PC (that is there are three copies
> > of MyApplication (PC1 and PC2 and PC3)).
> >
> > Each installation of MyApplication is using this connection string to access
> > SQL Server:
> >
> > ConnStr = "User ID=DEP_1;Password=abc;Persist Security Info=True;Connection
> > Timeout=15;Data Source=XXX;Initial Catalog=YYY"
> >
> > Can I have one user CAL for user DEP_1 or do I need three user CALs for all
> > three users?
> >
> > Thanks!|||1. Yes, but if you don't follow the paper rules, you get very expensive
paperwork from Microsoft layers when they catch you.
2. On The server, go to Administrative Tools > Licensing
3. It does not know, but you are responsible. Point 2 can help you report on
it.
4. A CAL can be for a physical user or device and by the licensing terms, it
can only be transferred once to another user/device.
5. As long as the service does not get used by another program or service to
connect through it to the SQL Server (multiplexing)
http://www.microsoft.com/sql/howtobuy/default.asp
http://www.microsoft.com/sql/howtobuy/faq.asp
The CAL actually says a lot:
http://download.microsoft.com/download/5/E/7/5E7B79D4-90B8-4A3D-B964-8A72F49A21A9/caleula.pdf
Regards
--
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"Marek" <Marek@.discussions.microsoft.com> wrote in message
news:F588172A-B890-4D60-962B-8B211B7CD9C8@.microsoft.com...
> Thanks Mike for quick answer!
> 1. Does this mean, that user CAL is nothing more than a paper?
> 2. Is user CAL somehow entered into SQL Server licensing properties? (I
> found only licensing per-seat (device CAL) or per processor in my SQL
Server
> licensing setup)
> 3. How will Server know, if there are more users accessing server than are
> defined in server licensing properties? (I will have only one CAL for
DEP_1
> and server will never know, who is currently logged into MyApplication)
> 4. Is user CAL always "mapped" (=issued) to real person?
> 5. What if MyApplication from previous post will be a windows service with
> no UI interraction [no user logs into it. It will run on background on
three
> PCs and process some results]. Could it use only one user CAL then?
> Bweh, I know, silly questions, but I'm lost in all these licensing
options.
> Thanks!
> "Mike Epprecht (SQL MVP)" wrote:
> > Hi
> >
> > You needs CALS for all 3 users.
> > DEP_1 is just a security user and does not count in for CALS.
> >
> > Regards
> > Mike
> >
> > "Marek" wrote:
> >
> > > Hi,
> > >
> > > I have a question about SQL Server plus user CALs. What exactly is
meant by
> > > "user"? Is it a person that logs into my application or is it a user
id
> > > specified in connecion string?
> > >
> > > Can I have one user CAL for X people, that are accessing SQL server
through
> > > identical userid in connection string?
> > >
> > > for example:
> > >
> > > users: John [logged into MyApplication at PC1], Mark[logged into
> > > MyApplication at PC2], Bob[logged into MyApplication at PC3]
> > >
> > > MyApplication is installed on everybody's PC (that is there are three
copies
> > > of MyApplication (PC1 and PC2 and PC3)).
> > >
> > > Each installation of MyApplication is using this connection string to
access
> > > SQL Server:
> > >
> > > ConnStr = "User ID=DEP_1;Password=abc;Persist Security
Info=True;Connection
> > > Timeout=15;Data Source=XXX;Initial Catalog=YYY"
> > >
> > > Can I have one user CAL for user DEP_1 or do I need three user CALs
for all
> > > three users?
> > >
> > > Thanks!|||Prior to one of the service packs, not 3 or 3a, the number of CALs
restricted the number of concurrent user connections. You'd get errors
similar to those you see in MSDE when you exceed 8. Since the service pack,
however, the concurrent connections is limited only by a sp_configure
setting. However, there is nothing but paper that says you can't run
Developer Edition in production, but, then, that's why the paper was
written. The U.S. Constitution is nothing but paper, but if they catch you,
there's all sorts of pleasures waiting for you and your wallet.
Sincerely,
Anthony Thomas
"Mike Epprecht (SQL MVP)" <mike@.epprecht.net> wrote in message
news:uYtjOLCyEHA.3976@.TK2MSFTNGP09.phx.gbl...
> 1. Yes, but if you don't follow the paper rules, you get very expensive
> paperwork from Microsoft layers when they catch you.
> 2. On The server, go to Administrative Tools > Licensing
> 3. It does not know, but you are responsible. Point 2 can help you report
on
> it.
> 4. A CAL can be for a physical user or device and by the licensing terms,
it
> can only be transferred once to another user/device.
> 5. As long as the service does not get used by another program or service
to
> connect through it to the SQL Server (multiplexing)
> http://www.microsoft.com/sql/howtobuy/default.asp
> http://www.microsoft.com/sql/howtobuy/faq.asp
> The CAL actually says a lot:
>
http://download.microsoft.com/download/5/E/7/5E7B79D4-90B8-4A3D-B964-8A72F49A21A9/caleula.pdf
> Regards
> --
> Mike Epprecht, Microsoft SQL Server MVP
> Zurich, Switzerland
> IM: mike@.epprecht.net
> MVP Program: http://www.microsoft.com/mvp
> Blog: http://www.msmvps.com/epprecht/
> "Marek" <Marek@.discussions.microsoft.com> wrote in message
> news:F588172A-B890-4D60-962B-8B211B7CD9C8@.microsoft.com...
> > Thanks Mike for quick answer!
> >
> > 1. Does this mean, that user CAL is nothing more than a paper?
> >
> > 2. Is user CAL somehow entered into SQL Server licensing properties? (I
> > found only licensing per-seat (device CAL) or per processor in my SQL
> Server
> > licensing setup)
> >
> > 3. How will Server know, if there are more users accessing server than
are
> > defined in server licensing properties? (I will have only one CAL for
> DEP_1
> > and server will never know, who is currently logged into MyApplication)
> >
> > 4. Is user CAL always "mapped" (=issued) to real person?
> >
> > 5. What if MyApplication from previous post will be a windows service
with
> > no UI interraction [no user logs into it. It will run on background on
> three
> > PCs and process some results]. Could it use only one user CAL then?
> >
> > Bweh, I know, silly questions, but I'm lost in all these licensing
> options.
> >
> > Thanks!
> >
> > "Mike Epprecht (SQL MVP)" wrote:
> >
> > > Hi
> > >
> > > You needs CALS for all 3 users.
> > > DEP_1 is just a security user and does not count in for CALS.
> > >
> > > Regards
> > > Mike
> > >
> > > "Marek" wrote:
> > >
> > > > Hi,
> > > >
> > > > I have a question about SQL Server plus user CALs. What exactly is
> meant by
> > > > "user"? Is it a person that logs into my application or is it a user
> id
> > > > specified in connecion string?
> > > >
> > > > Can I have one user CAL for X people, that are accessing SQL server
> through
> > > > identical userid in connection string?
> > > >
> > > > for example:
> > > >
> > > > users: John [logged into MyApplication at PC1], Mark[logged into
> > > > MyApplication at PC2], Bob[logged into MyApplication at PC3]
> > > >
> > > > MyApplication is installed on everybody's PC (that is there are
three
> copies
> > > > of MyApplication (PC1 and PC2 and PC3)).
> > > >
> > > > Each installation of MyApplication is using this connection string
to
> access
> > > > SQL Server:
> > > >
> > > > ConnStr = "User ID=DEP_1;Password=abc;Persist Security
> Info=True;Connection
> > > > Timeout=15;Data Source=XXX;Initial Catalog=YYY"
> > > >
> > > > Can I have one user CAL for user DEP_1 or do I need three user CALs
> for all
> > > > three users?
> > > >
> > > > Thanks!
>
Subscribe to:
Posts (Atom)