When we print invoices, we offer a 25% discount if they pay within 33 days from the date of invoice. Can anyone help with a formula that would show the date 33 days from printed invoice date? As always, thanks!See the help on the DateAdd function.|||Something like this should work. ( I took a guess at your field name )
{Orders.Invoice Date} + 33
Tuesday, March 27, 2012
32GB log file
Recently, I discovered the log file of testing database server which grow up
a lot. The log file is around 32GB.
any idea on shrink/ Purge the log file?
Thanks
Alan
Hi,
It seems you have set recovery model for this database to FULL. In this
recovery model all the activity inside the
database is logged. So you have schedule a transaction log backup to clear
of the trasnaction logs. THis backup can
be used when a recovery is needed. Since this database is a test environment
I recomment you to make the recovery model as SIMPLE.
Show to set to simple
ALTER database <dbname> set recovery SIMPLE
How to clear the existing logs and shrink the file:-
Since the file is really huge, I recomment you to set the database to single
user model befotre doing the below steps.
-- Setting database single user.
Alter database <dbname> set single_user with rollback immediate
-- Truncate the transaction log
BACKUP log <dbname> with truncate_only
-- Shrink the transacton log file
DBCC SHRINKFILE('logical_ldf_name',truncateonly)
After doing the above steps execute the below command to see the transaction
log size and usage.
DBCC SQLPERF(LOGSPACE)
-- Now set the database multi user
Alter database <dbname> set multi_user
Thanks
Hari
MCDBA
"izumi" <test@.test.com> wrote in message
news:#AzZUnZWEHA.2844@.TK2MSFTNGP11.phx.gbl...
> Recently, I discovered the log file of testing database server which grow
up
> a lot. The log file is around 32GB.
> any idea on shrink/ Purge the log file?
> Thanks
> Alan
>
|||see
http://www.nigelrivett.net/Transacti...leGrows_1.html
|||thanks all.
actually my company will backup the database 2 times a day...
But we dont shrink(Truncate) the log..so it grows up a lot...
do we have any problems after i delete the whole log?
"Nigel Rivett" <NigelRivett@.discussions.microsoft.com> wrote in message
news:4E79A30A-2807-4652-921A-7BCC48B6199E@.microsoft.com...
> see
> http://www.nigelrivett.net/Transacti...leGrows_1.html
>
|||no real Problems deleting the log except that you wont be able to recover
transactions potentially lost.
If you are not using the logs for your recovery model, I would just
recommend setting the database recovery model to "SIMPLE". This will turn
logging off then you wont have to worry about the files at all.
Greg Jackson
PDX, Oregon
|||Yes if we can restore mdf withour log
i think it is ok...
"Jaxon" <GregoryAJackson@.hotmail.com> wrote in message
news:%23kaIa5fWEHA.1048@.tk2msftngp13.phx.gbl...
> no real Problems deleting the log except that you wont be able to recover
> transactions potentially lost.
> If you are not using the logs for your recovery model, I would just
> recommend setting the database recovery model to "SIMPLE". This will turn
> logging off then you wont have to worry about the files at all.
>
> Greg Jackson
> PDX, Oregon
>
|||Just wanted to make a distinction between shrinking and truncating the file. Truncation is a TLog specific activity and it deletes old log records
in the file that are no longer necessary. This activity doesnot result in any reduciton in the physical size of the LDF file , and change in file size
is noticed at the file level. This is an internal operation and only makes room inside the file, for re-use.
On the otherhand, shrinking is a physical operation intended for reducing the size of the LDF file.
To address your problem, I would not recommend a flat deletion of the Tlog file. Rather, you should schedule a periodic BACKUP LOG
operation, which will ensure that the TLog is truncated. Then , on a as-needed-basis, you can perform a manual DBCC SHRINKFILE operation
to claim this unused (truncated) space from the ldf and release it back to the OS.
Thanks
Ananth Padmanabham
Microsoft SQL Server support
Please reply only to the newsgroup so that others can benefit. When posting, please state the version of SQL Server being used and the error
number/exact error message text received, if any.
This posting is provided "AS IS" with no warranties, and confers no rights.
a lot. The log file is around 32GB.
any idea on shrink/ Purge the log file?
Thanks
Alan
Hi,
It seems you have set recovery model for this database to FULL. In this
recovery model all the activity inside the
database is logged. So you have schedule a transaction log backup to clear
of the trasnaction logs. THis backup can
be used when a recovery is needed. Since this database is a test environment
I recomment you to make the recovery model as SIMPLE.
Show to set to simple
ALTER database <dbname> set recovery SIMPLE
How to clear the existing logs and shrink the file:-
Since the file is really huge, I recomment you to set the database to single
user model befotre doing the below steps.
-- Setting database single user.
Alter database <dbname> set single_user with rollback immediate
-- Truncate the transaction log
BACKUP log <dbname> with truncate_only
-- Shrink the transacton log file
DBCC SHRINKFILE('logical_ldf_name',truncateonly)
After doing the above steps execute the below command to see the transaction
log size and usage.
DBCC SQLPERF(LOGSPACE)
-- Now set the database multi user
Alter database <dbname> set multi_user
Thanks
Hari
MCDBA
"izumi" <test@.test.com> wrote in message
news:#AzZUnZWEHA.2844@.TK2MSFTNGP11.phx.gbl...
> Recently, I discovered the log file of testing database server which grow
up
> a lot. The log file is around 32GB.
> any idea on shrink/ Purge the log file?
> Thanks
> Alan
>
|||see
http://www.nigelrivett.net/Transacti...leGrows_1.html
|||thanks all.
actually my company will backup the database 2 times a day...
But we dont shrink(Truncate) the log..so it grows up a lot...
do we have any problems after i delete the whole log?
"Nigel Rivett" <NigelRivett@.discussions.microsoft.com> wrote in message
news:4E79A30A-2807-4652-921A-7BCC48B6199E@.microsoft.com...
> see
> http://www.nigelrivett.net/Transacti...leGrows_1.html
>
|||no real Problems deleting the log except that you wont be able to recover
transactions potentially lost.
If you are not using the logs for your recovery model, I would just
recommend setting the database recovery model to "SIMPLE". This will turn
logging off then you wont have to worry about the files at all.
Greg Jackson
PDX, Oregon
|||Yes if we can restore mdf withour log
i think it is ok...
"Jaxon" <GregoryAJackson@.hotmail.com> wrote in message
news:%23kaIa5fWEHA.1048@.tk2msftngp13.phx.gbl...
> no real Problems deleting the log except that you wont be able to recover
> transactions potentially lost.
> If you are not using the logs for your recovery model, I would just
> recommend setting the database recovery model to "SIMPLE". This will turn
> logging off then you wont have to worry about the files at all.
>
> Greg Jackson
> PDX, Oregon
>
|||Just wanted to make a distinction between shrinking and truncating the file. Truncation is a TLog specific activity and it deletes old log records
in the file that are no longer necessary. This activity doesnot result in any reduciton in the physical size of the LDF file , and change in file size
is noticed at the file level. This is an internal operation and only makes room inside the file, for re-use.
On the otherhand, shrinking is a physical operation intended for reducing the size of the LDF file.
To address your problem, I would not recommend a flat deletion of the Tlog file. Rather, you should schedule a periodic BACKUP LOG
operation, which will ensure that the TLog is truncated. Then , on a as-needed-basis, you can perform a manual DBCC SHRINKFILE operation
to claim this unused (truncated) space from the ldf and release it back to the OS.
Thanks
Ananth Padmanabham
Microsoft SQL Server support
Please reply only to the newsgroup so that others can benefit. When posting, please state the version of SQL Server being used and the error
number/exact error message text received, if any.
This posting is provided "AS IS" with no warranties, and confers no rights.
32GB log file
Recently, I discovered the log file of testing database server which grow up
a lot. The log file is around 32GB.
any idea on shrink/ Purge the log file?
Thanks
AlanHi,
It seems you have set recovery model for this database to FULL. In this
recovery model all the activity inside the
database is logged. So you have schedule a transaction log backup to clear
of the trasnaction logs. THis backup can
be used when a recovery is needed. Since this database is a test environment
I recomment you to make the recovery model as SIMPLE.
Show to set to simple
ALTER database <dbname> set recovery SIMPLE
How to clear the existing logs and shrink the file:-
Since the file is really huge, I recomment you to set the database to single
user model befotre doing the below steps.
-- Setting database single user.
Alter database <dbname> set single_user with rollback immediate
-- Truncate the transaction log
BACKUP log <dbname> with truncate_only
-- Shrink the transacton log file
DBCC SHRINKFILE('logical_ldf_name',truncateon
ly)
After doing the above steps execute the below command to see the transaction
log size and usage.
DBCC SQLPERF(LOGSPACE)
-- Now set the database multi user
Alter database <dbname> set multi_user
Thanks
Hari
MCDBA
"izumi" <test@.test.com> wrote in message
news:#AzZUnZWEHA.2844@.TK2MSFTNGP11.phx.gbl...
> Recently, I discovered the log file of testing database server which grow
up
> a lot. The log file is around 32GB.
> any idea on shrink/ Purge the log file?
> Thanks
> Alan
>|||see
http://www.nigelrivett.net/Transact...ileGrows_1.html|||thanks all.
actually my company will backup the database 2 times a day...
But we dont shrink(Truncate) the log..so it grows up a lot...
do we have any problems after i delete the whole log?
"Nigel Rivett" <NigelRivett@.discussions.microsoft.com> wrote in message
news:4E79A30A-2807-4652-921A-7BCC48B6199E@.microsoft.com...
> see
> http://www.nigelrivett.net/Transact...ileGrows_1.html
>|||no real Problems deleting the log except that you wont be able to recover
transactions potentially lost.
If you are not using the logs for your recovery model, I would just
recommend setting the database recovery model to "SIMPLE". This will turn
logging off then you wont have to worry about the files at all.
Greg Jackson
PDX, Oregon|||Yes if we can restore mdf withour log
i think it is ok...
"Jaxon" <GregoryAJackson@.hotmail.com> wrote in message
news:%23kaIa5fWEHA.1048@.tk2msftngp13.phx.gbl...
> no real Problems deleting the log except that you wont be able to recover
> transactions potentially lost.
> If you are not using the logs for your recovery model, I would just
> recommend setting the database recovery model to "SIMPLE". This will turn
> logging off then you wont have to worry about the files at all.
>
> Greg Jackson
> PDX, Oregon
>|||Just wanted to make a distinction between shrinking and truncating the file.
Truncation is a TLog specific activity and it deletes old log records
in the file that are no longer necessary. This activity doesnot result in an
y reduciton in the physical size of the LDF file , and change in file size
is noticed at the file level. This is an internal operation and only makes r
oom inside the file, for re-use.
On the otherhand, shrinking is a physical operation intended for reducing th
e size of the LDF file.
To address your problem, I would not recommend a flat deletion of the Tlog f
ile. Rather, you should schedule a periodic BACKUP LOG
operation, which will ensure that the TLog is truncated. Then , on a as-need
ed-basis, you can perform a manual DBCC SHRINKFILE operation
to claim this unused (truncated) space from the ldf and release it back to t
he OS.
Thanks
Ananth Padmanabham
Microsoft SQL Server support
Please reply only to the newsgroup so that others can benefit. When posting,
please state the version of SQL Server being used and the error
number/exact error message text received, if any.
This posting is provided "AS IS" with no warranties, and confers no rights.
a lot. The log file is around 32GB.
any idea on shrink/ Purge the log file?
Thanks
AlanHi,
It seems you have set recovery model for this database to FULL. In this
recovery model all the activity inside the
database is logged. So you have schedule a transaction log backup to clear
of the trasnaction logs. THis backup can
be used when a recovery is needed. Since this database is a test environment
I recomment you to make the recovery model as SIMPLE.
Show to set to simple
ALTER database <dbname> set recovery SIMPLE
How to clear the existing logs and shrink the file:-
Since the file is really huge, I recomment you to set the database to single
user model befotre doing the below steps.
-- Setting database single user.
Alter database <dbname> set single_user with rollback immediate
-- Truncate the transaction log
BACKUP log <dbname> with truncate_only
-- Shrink the transacton log file
DBCC SHRINKFILE('logical_ldf_name',truncateon
ly)
After doing the above steps execute the below command to see the transaction
log size and usage.
DBCC SQLPERF(LOGSPACE)
-- Now set the database multi user
Alter database <dbname> set multi_user
Thanks
Hari
MCDBA
"izumi" <test@.test.com> wrote in message
news:#AzZUnZWEHA.2844@.TK2MSFTNGP11.phx.gbl...
> Recently, I discovered the log file of testing database server which grow
up
> a lot. The log file is around 32GB.
> any idea on shrink/ Purge the log file?
> Thanks
> Alan
>|||see
http://www.nigelrivett.net/Transact...ileGrows_1.html|||thanks all.
actually my company will backup the database 2 times a day...
But we dont shrink(Truncate) the log..so it grows up a lot...
do we have any problems after i delete the whole log?
"Nigel Rivett" <NigelRivett@.discussions.microsoft.com> wrote in message
news:4E79A30A-2807-4652-921A-7BCC48B6199E@.microsoft.com...
> see
> http://www.nigelrivett.net/Transact...ileGrows_1.html
>|||no real Problems deleting the log except that you wont be able to recover
transactions potentially lost.
If you are not using the logs for your recovery model, I would just
recommend setting the database recovery model to "SIMPLE". This will turn
logging off then you wont have to worry about the files at all.
Greg Jackson
PDX, Oregon|||Yes if we can restore mdf withour log
i think it is ok...
"Jaxon" <GregoryAJackson@.hotmail.com> wrote in message
news:%23kaIa5fWEHA.1048@.tk2msftngp13.phx.gbl...
> no real Problems deleting the log except that you wont be able to recover
> transactions potentially lost.
> If you are not using the logs for your recovery model, I would just
> recommend setting the database recovery model to "SIMPLE". This will turn
> logging off then you wont have to worry about the files at all.
>
> Greg Jackson
> PDX, Oregon
>|||Just wanted to make a distinction between shrinking and truncating the file.
Truncation is a TLog specific activity and it deletes old log records
in the file that are no longer necessary. This activity doesnot result in an
y reduciton in the physical size of the LDF file , and change in file size
is noticed at the file level. This is an internal operation and only makes r
oom inside the file, for re-use.
On the otherhand, shrinking is a physical operation intended for reducing th
e size of the LDF file.
To address your problem, I would not recommend a flat deletion of the Tlog f
ile. Rather, you should schedule a periodic BACKUP LOG
operation, which will ensure that the TLog is truncated. Then , on a as-need
ed-basis, you can perform a manual DBCC SHRINKFILE operation
to claim this unused (truncated) space from the ldf and release it back to t
he OS.
Thanks
Ananth Padmanabham
Microsoft SQL Server support
Please reply only to the newsgroup so that others can benefit. When posting,
please state the version of SQL Server being used and the error
number/exact error message text received, if any.
This posting is provided "AS IS" with no warranties, and confers no rights.
32GB log file
Recently, I discovered the log file of testing database server which grow up
a lot. The log file is around 32GB.
any idea on shrink/ Purge the log file?
Thanks
AlanHi,
It seems you have set recovery model for this database to FULL. In this
recovery model all the activity inside the
database is logged. So you have schedule a transaction log backup to clear
of the trasnaction logs. THis backup can
be used when a recovery is needed. Since this database is a test environment
I recomment you to make the recovery model as SIMPLE.
Show to set to simple
ALTER database <dbname> set recovery SIMPLE
How to clear the existing logs and shrink the file:-
Since the file is really huge, I recomment you to set the database to single
user model befotre doing the below steps.
-- Setting database single user.
Alter database <dbname> set single_user with rollback immediate
-- Truncate the transaction log
BACKUP log <dbname> with truncate_only
-- Shrink the transacton log file
DBCC SHRINKFILE('logical_ldf_name',truncateonly)
After doing the above steps execute the below command to see the transaction
log size and usage.
DBCC SQLPERF(LOGSPACE)
-- Now set the database multi user
Alter database <dbname> set multi_user
Thanks
Hari
MCDBA
"izumi" <test@.test.com> wrote in message
news:#AzZUnZWEHA.2844@.TK2MSFTNGP11.phx.gbl...
> Recently, I discovered the log file of testing database server which grow
up
> a lot. The log file is around 32GB.
> any idea on shrink/ Purge the log file?
> Thanks
> Alan
>|||see
http://www.nigelrivett.net/TransactionLogFileGrows_1.html|||thanks all.
actually my company will backup the database 2 times a day...
But we dont shrink(Truncate) the log..so it grows up a lot...
do we have any problems after i delete the whole log?
"Nigel Rivett" <NigelRivett@.discussions.microsoft.com> wrote in message
news:4E79A30A-2807-4652-921A-7BCC48B6199E@.microsoft.com...
> see
> http://www.nigelrivett.net/TransactionLogFileGrows_1.html
>|||no real Problems deleting the log except that you wont be able to recover
transactions potentially lost.
If you are not using the logs for your recovery model, I would just
recommend setting the database recovery model to "SIMPLE". This will turn
logging off then you wont have to worry about the files at all.
Greg Jackson
PDX, Oregon|||Yes if we can restore mdf withour log
i think it is ok...
"Jaxon" <GregoryAJackson@.hotmail.com> wrote in message
news:%23kaIa5fWEHA.1048@.tk2msftngp13.phx.gbl...
> no real Problems deleting the log except that you wont be able to recover
> transactions potentially lost.
> If you are not using the logs for your recovery model, I would just
> recommend setting the database recovery model to "SIMPLE". This will turn
> logging off then you wont have to worry about the files at all.
>
> Greg Jackson
> PDX, Oregon
>|||Just wanted to make a distinction between shrinking and truncating the file. Truncation is a TLog specific activity and it deletes old log records
in the file that are no longer necessary. This activity doesnot result in any reduciton in the physical size of the LDF file , and change in file size
is noticed at the file level. This is an internal operation and only makes room inside the file, for re-use.
On the otherhand, shrinking is a physical operation intended for reducing the size of the LDF file.
To address your problem, I would not recommend a flat deletion of the Tlog file. Rather, you should schedule a periodic BACKUP LOG
operation, which will ensure that the TLog is truncated. Then , on a as-needed-basis, you can perform a manual DBCC SHRINKFILE operation
to claim this unused (truncated) space from the ldf and release it back to the OS.
Thanks
Ananth Padmanabham
Microsoft SQL Server support
Please reply only to the newsgroup so that others can benefit. When posting, please state the version of SQL Server being used and the error
number/exact error message text received, if any.
This posting is provided "AS IS" with no warranties, and confers no rights.sql
a lot. The log file is around 32GB.
any idea on shrink/ Purge the log file?
Thanks
AlanHi,
It seems you have set recovery model for this database to FULL. In this
recovery model all the activity inside the
database is logged. So you have schedule a transaction log backup to clear
of the trasnaction logs. THis backup can
be used when a recovery is needed. Since this database is a test environment
I recomment you to make the recovery model as SIMPLE.
Show to set to simple
ALTER database <dbname> set recovery SIMPLE
How to clear the existing logs and shrink the file:-
Since the file is really huge, I recomment you to set the database to single
user model befotre doing the below steps.
-- Setting database single user.
Alter database <dbname> set single_user with rollback immediate
-- Truncate the transaction log
BACKUP log <dbname> with truncate_only
-- Shrink the transacton log file
DBCC SHRINKFILE('logical_ldf_name',truncateonly)
After doing the above steps execute the below command to see the transaction
log size and usage.
DBCC SQLPERF(LOGSPACE)
-- Now set the database multi user
Alter database <dbname> set multi_user
Thanks
Hari
MCDBA
"izumi" <test@.test.com> wrote in message
news:#AzZUnZWEHA.2844@.TK2MSFTNGP11.phx.gbl...
> Recently, I discovered the log file of testing database server which grow
up
> a lot. The log file is around 32GB.
> any idea on shrink/ Purge the log file?
> Thanks
> Alan
>|||see
http://www.nigelrivett.net/TransactionLogFileGrows_1.html|||thanks all.
actually my company will backup the database 2 times a day...
But we dont shrink(Truncate) the log..so it grows up a lot...
do we have any problems after i delete the whole log?
"Nigel Rivett" <NigelRivett@.discussions.microsoft.com> wrote in message
news:4E79A30A-2807-4652-921A-7BCC48B6199E@.microsoft.com...
> see
> http://www.nigelrivett.net/TransactionLogFileGrows_1.html
>|||no real Problems deleting the log except that you wont be able to recover
transactions potentially lost.
If you are not using the logs for your recovery model, I would just
recommend setting the database recovery model to "SIMPLE". This will turn
logging off then you wont have to worry about the files at all.
Greg Jackson
PDX, Oregon|||Yes if we can restore mdf withour log
i think it is ok...
"Jaxon" <GregoryAJackson@.hotmail.com> wrote in message
news:%23kaIa5fWEHA.1048@.tk2msftngp13.phx.gbl...
> no real Problems deleting the log except that you wont be able to recover
> transactions potentially lost.
> If you are not using the logs for your recovery model, I would just
> recommend setting the database recovery model to "SIMPLE". This will turn
> logging off then you wont have to worry about the files at all.
>
> Greg Jackson
> PDX, Oregon
>|||Just wanted to make a distinction between shrinking and truncating the file. Truncation is a TLog specific activity and it deletes old log records
in the file that are no longer necessary. This activity doesnot result in any reduciton in the physical size of the LDF file , and change in file size
is noticed at the file level. This is an internal operation and only makes room inside the file, for re-use.
On the otherhand, shrinking is a physical operation intended for reducing the size of the LDF file.
To address your problem, I would not recommend a flat deletion of the Tlog file. Rather, you should schedule a periodic BACKUP LOG
operation, which will ensure that the TLog is truncated. Then , on a as-needed-basis, you can perform a manual DBCC SHRINKFILE operation
to claim this unused (truncated) space from the ldf and release it back to the OS.
Thanks
Ananth Padmanabham
Microsoft SQL Server support
Please reply only to the newsgroup so that others can benefit. When posting, please state the version of SQL Server being used and the error
number/exact error message text received, if any.
This posting is provided "AS IS" with no warranties, and confers no rights.sql
32-bit with 64-bit memory extensions.
Can anyone from Microsoft tell us if Yukon will support the x86-64
architecture that is available in the Opteron chip and soon to be available
in the Xeon chip set? the reason for this is we use Microsoft Analytical
Services and SQL Server quite extensively here and the 2.7 GB memory
limitation in MSAS is killing us on cube builds.
Andrew C. Madsen
Information Architect
Harley-Davidson Motor Company
I don't know the answer on the Yukon question, but thought if versions are
right, this article my be of assistance to you.
http://www.sql-server-performance.com/awe_memory.asp
Good Luck
"Andrew Madsen" <andrew.madsen@.harley-davidson.com> wrote in message
news:u6MJPl6UEHA.3656@.TK2MSFTNGP11.phx.gbl...
> Can anyone from Microsoft tell us if Yukon will support the x86-64
> architecture that is available in the Opteron chip and soon to be
available
> in the Xeon chip set? the reason for this is we use Microsoft Analytical
> Services and SQL Server quite extensively here and the 2.7 GB memory
> limitation in MSAS is killing us on cube builds.
> --
> Andrew C. Madsen
> Information Architect
> Harley-Davidson Motor Company
>
|||Everything I've heard says yes, they will support it, but I haven't seen
anything official. Also, the TechEd 2004 presentation PowerPoint slides are
available online and one of them says it will, slide 4:
http://download.microsoft.com/downlo...6ae/dat306.ppt
-John Oakes
"Andrew Madsen" <andrew.madsen@.harley-davidson.com> wrote in message
news:u6MJPl6UEHA.3656@.TK2MSFTNGP11.phx.gbl...
> Can anyone from Microsoft tell us if Yukon will support the x86-64
> architecture that is available in the Opteron chip and soon to be
available
> in the Xeon chip set? the reason for this is we use Microsoft Analytical
> Services and SQL Server quite extensively here and the 2.7 GB memory
> limitation in MSAS is killing us on cube builds.
> --
> Andrew C. Madsen
> Information Architect
> Harley-Davidson Motor Company
>
|||This applies to SQL Server and not the MSAS component. That component is
written to handle only 2.7 GB of memory in the 32 bit world. It is unlimited
in a 64-bit world.
Andrew C. Madsen
Information Architect
Harley-Davidson Motor Company
"Rich" <deleted99@.msn.com> wrote in message
news:gvYzc.54894$TR1.25097@.nwrddc01.gnilink.net...
> I don't know the answer on the Yukon question, but thought if versions are
> right, this article my be of assistance to you.
> http://www.sql-server-performance.com/awe_memory.asp
> Good Luck
>
> "Andrew Madsen" <andrew.madsen@.harley-davidson.com> wrote in message
> news:u6MJPl6UEHA.3656@.TK2MSFTNGP11.phx.gbl...
> available
>
architecture that is available in the Opteron chip and soon to be available
in the Xeon chip set? the reason for this is we use Microsoft Analytical
Services and SQL Server quite extensively here and the 2.7 GB memory
limitation in MSAS is killing us on cube builds.
Andrew C. Madsen
Information Architect
Harley-Davidson Motor Company
I don't know the answer on the Yukon question, but thought if versions are
right, this article my be of assistance to you.
http://www.sql-server-performance.com/awe_memory.asp
Good Luck
"Andrew Madsen" <andrew.madsen@.harley-davidson.com> wrote in message
news:u6MJPl6UEHA.3656@.TK2MSFTNGP11.phx.gbl...
> Can anyone from Microsoft tell us if Yukon will support the x86-64
> architecture that is available in the Opteron chip and soon to be
available
> in the Xeon chip set? the reason for this is we use Microsoft Analytical
> Services and SQL Server quite extensively here and the 2.7 GB memory
> limitation in MSAS is killing us on cube builds.
> --
> Andrew C. Madsen
> Information Architect
> Harley-Davidson Motor Company
>
|||Everything I've heard says yes, they will support it, but I haven't seen
anything official. Also, the TechEd 2004 presentation PowerPoint slides are
available online and one of them says it will, slide 4:
http://download.microsoft.com/downlo...6ae/dat306.ppt
-John Oakes
"Andrew Madsen" <andrew.madsen@.harley-davidson.com> wrote in message
news:u6MJPl6UEHA.3656@.TK2MSFTNGP11.phx.gbl...
> Can anyone from Microsoft tell us if Yukon will support the x86-64
> architecture that is available in the Opteron chip and soon to be
available
> in the Xeon chip set? the reason for this is we use Microsoft Analytical
> Services and SQL Server quite extensively here and the 2.7 GB memory
> limitation in MSAS is killing us on cube builds.
> --
> Andrew C. Madsen
> Information Architect
> Harley-Davidson Motor Company
>
|||This applies to SQL Server and not the MSAS component. That component is
written to handle only 2.7 GB of memory in the 32 bit world. It is unlimited
in a 64-bit world.
Andrew C. Madsen
Information Architect
Harley-Davidson Motor Company
"Rich" <deleted99@.msn.com> wrote in message
news:gvYzc.54894$TR1.25097@.nwrddc01.gnilink.net...
> I don't know the answer on the Yukon question, but thought if versions are
> right, this article my be of assistance to you.
> http://www.sql-server-performance.com/awe_memory.asp
> Good Luck
>
> "Andrew Madsen" <andrew.madsen@.harley-davidson.com> wrote in message
> news:u6MJPl6UEHA.3656@.TK2MSFTNGP11.phx.gbl...
> available
>
32-bit with 64-bit memory extensions.
Can anyone from Microsoft tell us if Yukon will support the x86-64
architecture that is available in the Opteron chip and soon to be available
in the Xeon chip set? the reason for this is we use Microsoft Analytical
Services and SQL Server quite extensively here and the 2.7 GB memory
limitation in MSAS is killing us on cube builds.
Andrew C. Madsen
Information Architect
Harley-Davidson Motor CompanyI don't know the answer on the Yukon question, but thought if versions are
right, this article my be of assistance to you.
http://www.sql-server-performance.com/awe_memory.asp
Good Luck
"Andrew Madsen" <andrew.madsen@.harley-davidson.com> wrote in message
news:u6MJPl6UEHA.3656@.TK2MSFTNGP11.phx.gbl...
> Can anyone from Microsoft tell us if Yukon will support the x86-64
> architecture that is available in the Opteron chip and soon to be
available
> in the Xeon chip set? the reason for this is we use Microsoft Analytical
> Services and SQL Server quite extensively here and the 2.7 GB memory
> limitation in MSAS is killing us on cube builds.
> --
> Andrew C. Madsen
> Information Architect
> Harley-Davidson Motor Company
>|||Everything I've heard says yes, they will support it, but I haven't seen
anything official. Also, the TechEd 2004 presentation PowerPoint slides are
available online and one of them says it will, slide 4:
dat306.ppt" target="_blank">http://download.microsoft.com/downl... />
dat306.ppt
-John Oakes
"Andrew Madsen" <andrew.madsen@.harley-davidson.com> wrote in message
news:u6MJPl6UEHA.3656@.TK2MSFTNGP11.phx.gbl...
> Can anyone from Microsoft tell us if Yukon will support the x86-64
> architecture that is available in the Opteron chip and soon to be
available
> in the Xeon chip set? the reason for this is we use Microsoft Analytical
> Services and SQL Server quite extensively here and the 2.7 GB memory
> limitation in MSAS is killing us on cube builds.
> --
> Andrew C. Madsen
> Information Architect
> Harley-Davidson Motor Company
>|||This applies to SQL Server and not the MSAS component. That component is
written to handle only 2.7 GB of memory in the 32 bit world. It is unlimited
in a 64-bit world.
Andrew C. Madsen
Information Architect
Harley-Davidson Motor Company
"Rich" <deleted99@.msn.com> wrote in message
news:gvYzc.54894$TR1.25097@.nwrddc01.gnilink.net...
> I don't know the answer on the Yukon question, but thought if versions are
> right, this article my be of assistance to you.
> http://www.sql-server-performance.com/awe_memory.asp
> Good Luck
>
> "Andrew Madsen" <andrew.madsen@.harley-davidson.com> wrote in message
> news:u6MJPl6UEHA.3656@.TK2MSFTNGP11.phx.gbl...
> available
>
architecture that is available in the Opteron chip and soon to be available
in the Xeon chip set? the reason for this is we use Microsoft Analytical
Services and SQL Server quite extensively here and the 2.7 GB memory
limitation in MSAS is killing us on cube builds.
Andrew C. Madsen
Information Architect
Harley-Davidson Motor CompanyI don't know the answer on the Yukon question, but thought if versions are
right, this article my be of assistance to you.
http://www.sql-server-performance.com/awe_memory.asp
Good Luck
"Andrew Madsen" <andrew.madsen@.harley-davidson.com> wrote in message
news:u6MJPl6UEHA.3656@.TK2MSFTNGP11.phx.gbl...
> Can anyone from Microsoft tell us if Yukon will support the x86-64
> architecture that is available in the Opteron chip and soon to be
available
> in the Xeon chip set? the reason for this is we use Microsoft Analytical
> Services and SQL Server quite extensively here and the 2.7 GB memory
> limitation in MSAS is killing us on cube builds.
> --
> Andrew C. Madsen
> Information Architect
> Harley-Davidson Motor Company
>|||Everything I've heard says yes, they will support it, but I haven't seen
anything official. Also, the TechEd 2004 presentation PowerPoint slides are
available online and one of them says it will, slide 4:
dat306.ppt" target="_blank">http://download.microsoft.com/downl... />
dat306.ppt
-John Oakes
"Andrew Madsen" <andrew.madsen@.harley-davidson.com> wrote in message
news:u6MJPl6UEHA.3656@.TK2MSFTNGP11.phx.gbl...
> Can anyone from Microsoft tell us if Yukon will support the x86-64
> architecture that is available in the Opteron chip and soon to be
available
> in the Xeon chip set? the reason for this is we use Microsoft Analytical
> Services and SQL Server quite extensively here and the 2.7 GB memory
> limitation in MSAS is killing us on cube builds.
> --
> Andrew C. Madsen
> Information Architect
> Harley-Davidson Motor Company
>|||This applies to SQL Server and not the MSAS component. That component is
written to handle only 2.7 GB of memory in the 32 bit world. It is unlimited
in a 64-bit world.
Andrew C. Madsen
Information Architect
Harley-Davidson Motor Company
"Rich" <deleted99@.msn.com> wrote in message
news:gvYzc.54894$TR1.25097@.nwrddc01.gnilink.net...
> I don't know the answer on the Yukon question, but thought if versions are
> right, this article my be of assistance to you.
> http://www.sql-server-performance.com/awe_memory.asp
> Good Luck
>
> "Andrew Madsen" <andrew.madsen@.harley-davidson.com> wrote in message
> news:u6MJPl6UEHA.3656@.TK2MSFTNGP11.phx.gbl...
> available
>
32-bit with 64-bit memory extensions.
Can anyone from Microsoft tell us if Yukon will support the x86-64
architecture that is available in the Opteron chip and soon to be available
in the Xeon chip set? the reason for this is we use Microsoft Analytical
Services and SQL Server quite extensively here and the 2.7 GB memory
limitation in MSAS is killing us on cube builds.
--
Andrew C. Madsen
Information Architect
Harley-Davidson Motor CompanyI don't know the answer on the Yukon question, but thought if versions are
right, this article my be of assistance to you.
http://www.sql-server-performance.com/awe_memory.asp
Good Luck
"Andrew Madsen" <andrew.madsen@.harley-davidson.com> wrote in message
news:u6MJPl6UEHA.3656@.TK2MSFTNGP11.phx.gbl...
> Can anyone from Microsoft tell us if Yukon will support the x86-64
> architecture that is available in the Opteron chip and soon to be
available
> in the Xeon chip set? the reason for this is we use Microsoft Analytical
> Services and SQL Server quite extensively here and the 2.7 GB memory
> limitation in MSAS is killing us on cube builds.
> --
> Andrew C. Madsen
> Information Architect
> Harley-Davidson Motor Company
>|||Everything I've heard says yes, they will support it, but I haven't seen
anything official. Also, the TechEd 2004 presentation PowerPoint slides are
available online and one of them says it will, slide 4:
http://download.microsoft.com/download/b/8/a/b8ad50e0-4bbc-4809-a0fe-0edee65716ae/dat306.ppt
-John Oakes
"Andrew Madsen" <andrew.madsen@.harley-davidson.com> wrote in message
news:u6MJPl6UEHA.3656@.TK2MSFTNGP11.phx.gbl...
> Can anyone from Microsoft tell us if Yukon will support the x86-64
> architecture that is available in the Opteron chip and soon to be
available
> in the Xeon chip set? the reason for this is we use Microsoft Analytical
> Services and SQL Server quite extensively here and the 2.7 GB memory
> limitation in MSAS is killing us on cube builds.
> --
> Andrew C. Madsen
> Information Architect
> Harley-Davidson Motor Company
>|||This applies to SQL Server and not the MSAS component. That component is
written to handle only 2.7 GB of memory in the 32 bit world. It is unlimited
in a 64-bit world.
--
Andrew C. Madsen
Information Architect
Harley-Davidson Motor Company
"Rich" <deleted99@.msn.com> wrote in message
news:gvYzc.54894$TR1.25097@.nwrddc01.gnilink.net...
> I don't know the answer on the Yukon question, but thought if versions are
> right, this article my be of assistance to you.
> http://www.sql-server-performance.com/awe_memory.asp
> Good Luck
>
> "Andrew Madsen" <andrew.madsen@.harley-davidson.com> wrote in message
> news:u6MJPl6UEHA.3656@.TK2MSFTNGP11.phx.gbl...
> > Can anyone from Microsoft tell us if Yukon will support the x86-64
> > architecture that is available in the Opteron chip and soon to be
> available
> > in the Xeon chip set? the reason for this is we use Microsoft Analytical
> > Services and SQL Server quite extensively here and the 2.7 GB memory
> > limitation in MSAS is killing us on cube builds.
> >
> > --
> > Andrew C. Madsen
> > Information Architect
> > Harley-Davidson Motor Company
> >
> >
>
architecture that is available in the Opteron chip and soon to be available
in the Xeon chip set? the reason for this is we use Microsoft Analytical
Services and SQL Server quite extensively here and the 2.7 GB memory
limitation in MSAS is killing us on cube builds.
--
Andrew C. Madsen
Information Architect
Harley-Davidson Motor CompanyI don't know the answer on the Yukon question, but thought if versions are
right, this article my be of assistance to you.
http://www.sql-server-performance.com/awe_memory.asp
Good Luck
"Andrew Madsen" <andrew.madsen@.harley-davidson.com> wrote in message
news:u6MJPl6UEHA.3656@.TK2MSFTNGP11.phx.gbl...
> Can anyone from Microsoft tell us if Yukon will support the x86-64
> architecture that is available in the Opteron chip and soon to be
available
> in the Xeon chip set? the reason for this is we use Microsoft Analytical
> Services and SQL Server quite extensively here and the 2.7 GB memory
> limitation in MSAS is killing us on cube builds.
> --
> Andrew C. Madsen
> Information Architect
> Harley-Davidson Motor Company
>|||Everything I've heard says yes, they will support it, but I haven't seen
anything official. Also, the TechEd 2004 presentation PowerPoint slides are
available online and one of them says it will, slide 4:
http://download.microsoft.com/download/b/8/a/b8ad50e0-4bbc-4809-a0fe-0edee65716ae/dat306.ppt
-John Oakes
"Andrew Madsen" <andrew.madsen@.harley-davidson.com> wrote in message
news:u6MJPl6UEHA.3656@.TK2MSFTNGP11.phx.gbl...
> Can anyone from Microsoft tell us if Yukon will support the x86-64
> architecture that is available in the Opteron chip and soon to be
available
> in the Xeon chip set? the reason for this is we use Microsoft Analytical
> Services and SQL Server quite extensively here and the 2.7 GB memory
> limitation in MSAS is killing us on cube builds.
> --
> Andrew C. Madsen
> Information Architect
> Harley-Davidson Motor Company
>|||This applies to SQL Server and not the MSAS component. That component is
written to handle only 2.7 GB of memory in the 32 bit world. It is unlimited
in a 64-bit world.
--
Andrew C. Madsen
Information Architect
Harley-Davidson Motor Company
"Rich" <deleted99@.msn.com> wrote in message
news:gvYzc.54894$TR1.25097@.nwrddc01.gnilink.net...
> I don't know the answer on the Yukon question, but thought if versions are
> right, this article my be of assistance to you.
> http://www.sql-server-performance.com/awe_memory.asp
> Good Luck
>
> "Andrew Madsen" <andrew.madsen@.harley-davidson.com> wrote in message
> news:u6MJPl6UEHA.3656@.TK2MSFTNGP11.phx.gbl...
> > Can anyone from Microsoft tell us if Yukon will support the x86-64
> > architecture that is available in the Opteron chip and soon to be
> available
> > in the Xeon chip set? the reason for this is we use Microsoft Analytical
> > Services and SQL Server quite extensively here and the 2.7 GB memory
> > limitation in MSAS is killing us on cube builds.
> >
> > --
> > Andrew C. Madsen
> > Information Architect
> > Harley-Davidson Motor Company
> >
> >
>
Subscribe to:
Posts (Atom)