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.
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
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
> >
> >
>
32bit vs 64bit SQL 2005
Just curious if anyone has any numbers for this.
We have a customer that has their server running windows server 64bit.
But, SQL 2005 loaded on it is only 32bit. What would be the benefits
(speed mainly) of upgrading to 64bit SQL - in numbers - like a 25%
increase, or something like that. Or, is there some certain issue when
running the 32bit SQL on 64bit OS that I need to be aware of.
TIA
Darin
*** Sent via Developersdex http://www.codecomments.com ***
The immediate benefit would be an improvement in the accessibility of memory
past 2GB (you wouldn't need to have AWE enabled - and AWE has restrictions
and is slow to deal with compared to normal memory).
I personally wouldn't expect a massive performance difference between 32-bit
vs. 64-bit on a 64-bit box, although 25% might not be unrealistic (have seen
this kind of performance difference with 32-bit Integration Services running
on a 64-bit box).
"Darin" <darin_nospam@.nospamever> wrote in message
news:u0FNa53WIHA.484@.TK2MSFTNGP06.phx.gbl...
> Just curious if anyone has any numbers for this.
> We have a customer that has their server running windows server 64bit.
> But, SQL 2005 loaded on it is only 32bit. What would be the benefits
> (speed mainly) of upgrading to 64bit SQL - in numbers - like a 25%
> increase, or something like that. Or, is there some certain issue when
> running the 32bit SQL on 64bit OS that I need to be aware of.
> TIA
> Darin
> *** Sent via Developersdex http://www.codecomments.com ***
|||I don't know that there can be an explicit across the board answer for this
situation. It probably depends on the load on the server. The more heavily
loaded the server runs the better the 64bit sql server install should
perform.
Kevin G. Boles
Indicium Resources, Inc.
SQL Server MVP
kgboles a earthlink dt net
"Darin" <darin_nospam@.nospamever> wrote in message
news:u0FNa53WIHA.484@.TK2MSFTNGP06.phx.gbl...
> Just curious if anyone has any numbers for this.
> We have a customer that has their server running windows server 64bit.
> But, SQL 2005 loaded on it is only 32bit. What would be the benefits
> (speed mainly) of upgrading to 64bit SQL - in numbers - like a 25%
> increase, or something like that. Or, is there some certain issue when
> running the 32bit SQL on 64bit OS that I need to be aware of.
> TIA
> Darin
> *** Sent via Developersdex http://www.codecomments.com ***
|||I don't think you can really quantify the performance without actually
running tests in your environment. See
http://blogs.msdn.com/sqlprogrammability/default.aspx.
Hope this helps.
Dan Guzman
SQL Server MVP
"Darin" <darin_nospam@.nospamever> wrote in message
news:u0FNa53WIHA.484@.TK2MSFTNGP06.phx.gbl...
> Just curious if anyone has any numbers for this.
> We have a customer that has their server running windows server 64bit.
> But, SQL 2005 loaded on it is only 32bit. What would be the benefits
> (speed mainly) of upgrading to 64bit SQL - in numbers - like a 25%
> increase, or something like that. Or, is there some certain issue when
> running the 32bit SQL on 64bit OS that I need to be aware of.
> TIA
> Darin
> *** Sent via Developersdex http://www.codecomments.com ***
|||This server is the distributor for 2 replicated subscribers.
One question - does 32bit SQL 2005 ONLY use 2GB RAM? If so, that to me
is enough reason to upgrade.
All 3 servers have 64bit Windows but are only running 32bit SQL2005.
Also, the distributor has 3GB RAM, one subscriber has 4GB and the other
has 2.93GB RAM. I have told their IT person to put at least 4GB on the
distributor since that is in the main office w/ the most users, and is
handling the replication.
Darin
*** Sent via Developersdex http://www.codecomments.com ***
|||> One question - does 32bit SQL 2005 ONLY use 2GB RAM? If so, that to me
> is enough reason to upgrade.
Memory in Standard Edition (and above) is limited only by the OS. However,
in 32-bit versions, memory beyond 3GB can be used only for data buffer cache
and is addressable only via AWE. One the the reasons to migrate to 64-bit
is that memory beyond 3GB can be used for other memory needs, like procedure
cache.
Hope this helps.
Dan Guzman
SQL Server MVP
"Darin" <darin_nospam@.nospamever> wrote in message
news:eGsq6P4WIHA.5132@.TK2MSFTNGP02.phx.gbl...
> This server is the distributor for 2 replicated subscribers.
> One question - does 32bit SQL 2005 ONLY use 2GB RAM? If so, that to me
> is enough reason to upgrade.
> All 3 servers have 64bit Windows but are only running 32bit SQL2005.
> Also, the distributor has 3GB RAM, one subscriber has 4GB and the other
> has 2.93GB RAM. I have told their IT person to put at least 4GB on the
> distributor since that is in the main office w/ the most users, and is
> handling the replication.
> Darin
> *** Sent via Developersdex http://www.codecomments.com ***
We have a customer that has their server running windows server 64bit.
But, SQL 2005 loaded on it is only 32bit. What would be the benefits
(speed mainly) of upgrading to 64bit SQL - in numbers - like a 25%
increase, or something like that. Or, is there some certain issue when
running the 32bit SQL on 64bit OS that I need to be aware of.
TIA
Darin
*** Sent via Developersdex http://www.codecomments.com ***
The immediate benefit would be an improvement in the accessibility of memory
past 2GB (you wouldn't need to have AWE enabled - and AWE has restrictions
and is slow to deal with compared to normal memory).
I personally wouldn't expect a massive performance difference between 32-bit
vs. 64-bit on a 64-bit box, although 25% might not be unrealistic (have seen
this kind of performance difference with 32-bit Integration Services running
on a 64-bit box).
"Darin" <darin_nospam@.nospamever> wrote in message
news:u0FNa53WIHA.484@.TK2MSFTNGP06.phx.gbl...
> Just curious if anyone has any numbers for this.
> We have a customer that has their server running windows server 64bit.
> But, SQL 2005 loaded on it is only 32bit. What would be the benefits
> (speed mainly) of upgrading to 64bit SQL - in numbers - like a 25%
> increase, or something like that. Or, is there some certain issue when
> running the 32bit SQL on 64bit OS that I need to be aware of.
> TIA
> Darin
> *** Sent via Developersdex http://www.codecomments.com ***
|||I don't know that there can be an explicit across the board answer for this
situation. It probably depends on the load on the server. The more heavily
loaded the server runs the better the 64bit sql server install should
perform.
Kevin G. Boles
Indicium Resources, Inc.
SQL Server MVP
kgboles a earthlink dt net
"Darin" <darin_nospam@.nospamever> wrote in message
news:u0FNa53WIHA.484@.TK2MSFTNGP06.phx.gbl...
> Just curious if anyone has any numbers for this.
> We have a customer that has their server running windows server 64bit.
> But, SQL 2005 loaded on it is only 32bit. What would be the benefits
> (speed mainly) of upgrading to 64bit SQL - in numbers - like a 25%
> increase, or something like that. Or, is there some certain issue when
> running the 32bit SQL on 64bit OS that I need to be aware of.
> TIA
> Darin
> *** Sent via Developersdex http://www.codecomments.com ***
|||I don't think you can really quantify the performance without actually
running tests in your environment. See
http://blogs.msdn.com/sqlprogrammability/default.aspx.
Hope this helps.
Dan Guzman
SQL Server MVP
"Darin" <darin_nospam@.nospamever> wrote in message
news:u0FNa53WIHA.484@.TK2MSFTNGP06.phx.gbl...
> Just curious if anyone has any numbers for this.
> We have a customer that has their server running windows server 64bit.
> But, SQL 2005 loaded on it is only 32bit. What would be the benefits
> (speed mainly) of upgrading to 64bit SQL - in numbers - like a 25%
> increase, or something like that. Or, is there some certain issue when
> running the 32bit SQL on 64bit OS that I need to be aware of.
> TIA
> Darin
> *** Sent via Developersdex http://www.codecomments.com ***
|||This server is the distributor for 2 replicated subscribers.
One question - does 32bit SQL 2005 ONLY use 2GB RAM? If so, that to me
is enough reason to upgrade.
All 3 servers have 64bit Windows but are only running 32bit SQL2005.
Also, the distributor has 3GB RAM, one subscriber has 4GB and the other
has 2.93GB RAM. I have told their IT person to put at least 4GB on the
distributor since that is in the main office w/ the most users, and is
handling the replication.
Darin
*** Sent via Developersdex http://www.codecomments.com ***
|||> One question - does 32bit SQL 2005 ONLY use 2GB RAM? If so, that to me
> is enough reason to upgrade.
Memory in Standard Edition (and above) is limited only by the OS. However,
in 32-bit versions, memory beyond 3GB can be used only for data buffer cache
and is addressable only via AWE. One the the reasons to migrate to 64-bit
is that memory beyond 3GB can be used for other memory needs, like procedure
cache.
Hope this helps.
Dan Guzman
SQL Server MVP
"Darin" <darin_nospam@.nospamever> wrote in message
news:eGsq6P4WIHA.5132@.TK2MSFTNGP02.phx.gbl...
> This server is the distributor for 2 replicated subscribers.
> One question - does 32bit SQL 2005 ONLY use 2GB RAM? If so, that to me
> is enough reason to upgrade.
> All 3 servers have 64bit Windows but are only running 32bit SQL2005.
> Also, the distributor has 3GB RAM, one subscriber has 4GB and the other
> has 2.93GB RAM. I have told their IT person to put at least 4GB on the
> distributor since that is in the main office w/ the most users, and is
> handling the replication.
> Darin
> *** Sent via Developersdex http://www.codecomments.com ***
Subscribe to:
Posts (Atom)