I have a server with Windows server 2003 enterprise edition, 6gb ram.
(32bit)
I installed SQL 2000 with SP4 on it, i configured it to use only 5gb of
memory.
Do i have to enable AWE for this box or this is enough for optimal
performance ?
my server show in the boot.ini "/PAE"
Thanks,,,Hi
http://support.microsoft.com/kb/274750
Aslo , read about hotfix
http://support.microsoft.com/kb/899761
"Mahmoud Amin" <mm.amin@.gmail.com> wrote in message
news:eE0c1aZYIHA.1212@.TK2MSFTNGP05.phx.gbl...
>I have a server with Windows server 2003 enterprise edition, 6gb ram.
>(32bit)
> I installed SQL 2000 with SP4 on it, i configured it to use only 5gb of
> memory.
> Do i have to enable AWE for this box or this is enough for optimal
> performance ?
> my server show in the boot.ini "/PAE"
> Thanks,,,
>
Showing posts with label 5gb. Show all posts
Showing posts with label 5gb. Show all posts
Wednesday, March 7, 2012
Does anyone know the Maximum Size of GetRowSet?
Does anyone know the maximum size of sql server's GetRowSet command?
We are trying to a 5gb table using SqlServer2000's GetRowSet command, and
after it fails with a 'connection error', we have found a suspicious temp
file that is almost exactly 2gb in size in the os temp folder.
We have plenty of drive space, plenty of tempdb space, we have checked
everything we can think of, moved the data to the temp HD and still it
fails approx 40% into the load.
The file we are reading is a foxPro file and we are trying to Get the data
into Sql Server.
Anyone have any thoughts on this?
Thanks.
Charles..it is possible this was programmed with 32-bit convention,
in which 2 or 3GB will be the limit. If you have W2K AS,
try booting with the /3GB flag and see if the temp file
goes to exactly 3GB before bombing out
>--Original Message--
>Does anyone know the maximum size of sql server's
GetRowSet command?
>We are trying to a 5gb table using SqlServer2000's
GetRowSet command, and
>after it fails with a 'connection error', we have found a
suspicious temp
>file that is almost exactly 2gb in size in the os temp
folder.
>We have plenty of drive space, plenty of tempdb space, we
have checked
>everything we can think of, moved the data to the temp
HD and still it
>fails approx 40% into the load.
>The file we are reading is a foxPro file and we are
trying to Get the data
>into Sql Server.
>Anyone have any thoughts on this?
>Thanks.
> Charles..
>
>.
>
We are trying to a 5gb table using SqlServer2000's GetRowSet command, and
after it fails with a 'connection error', we have found a suspicious temp
file that is almost exactly 2gb in size in the os temp folder.
We have plenty of drive space, plenty of tempdb space, we have checked
everything we can think of, moved the data to the temp HD and still it
fails approx 40% into the load.
The file we are reading is a foxPro file and we are trying to Get the data
into Sql Server.
Anyone have any thoughts on this?
Thanks.
Charles..it is possible this was programmed with 32-bit convention,
in which 2 or 3GB will be the limit. If you have W2K AS,
try booting with the /3GB flag and see if the temp file
goes to exactly 3GB before bombing out
>--Original Message--
>Does anyone know the maximum size of sql server's
GetRowSet command?
>We are trying to a 5gb table using SqlServer2000's
GetRowSet command, and
>after it fails with a 'connection error', we have found a
suspicious temp
>file that is almost exactly 2gb in size in the os temp
folder.
>We have plenty of drive space, plenty of tempdb space, we
have checked
>everything we can think of, moved the data to the temp
HD and still it
>fails approx 40% into the load.
>The file we are reading is a foxPro file and we are
trying to Get the data
>into Sql Server.
>Anyone have any thoughts on this?
>Thanks.
> Charles..
>
>.
>
Friday, February 24, 2012
Does a database need contiguous space?
Hello,
We had a problem that we're trying to figure out. We have a database that's
about 3.5GB in size on a partition with about 10GB of free space. The
database appeared normal, however when the client tried to write data to it
we'd receive a write error message.
We recreated the database on a different partition with 40GB free and it
works fine now. However we're still trying to figure out why the original
database failed and there comes the question-does SQL need contiguous free
space to work? The drive may be fairly fragmented and while there is ~10GB
free there may not be much contiguous space.
Everything else with SQL appears normal.
Thanks!Although a DB doesn't "need" contiguous space, it generally performs better
if it does have it.
What specifically is the error you get? Does the SQL Server service account
have write permission on that partition?
--
Tom
----
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Toronto, ON Canada
.
"Mike Chiodo" <MikeChiodo@.discussions.microsoft.com> wrote in message
news:B860E70E-2CC7-4644-A624-C21EB0373BCF@.microsoft.com...
Hello,
We had a problem that we're trying to figure out. We have a database that's
about 3.5GB in size on a partition with about 10GB of free space. The
database appeared normal, however when the client tried to write data to it
we'd receive a write error message.
We recreated the database on a different partition with 40GB free and it
works fine now. However we're still trying to figure out why the original
database failed and there comes the question-does SQL need contiguous free
space to work? The drive may be fairly fragmented and while there is ~10GB
free there may not be much contiguous space.
Everything else with SQL appears normal.
Thanks!|||Yes, the SQL server account has permission to write to that partition. As
far as the error message-it was an error generated by the program not a SQL
error.
I suspect the database was simply corrupt but don't know for certain.
Thanks for your answer-it helped clear up a piece of the puzzle.
Mike
"Tom Moreau" wrote:
> Although a DB doesn't "need" contiguous space, it generally performs better
> if it does have it.
> What specifically is the error you get? Does the SQL Server service account
> have write permission on that partition?
> --
> Tom
> ----
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
> SQL Server MVP
> Toronto, ON Canada
> ..
> "Mike Chiodo" <MikeChiodo@.discussions.microsoft.com> wrote in message
> news:B860E70E-2CC7-4644-A624-C21EB0373BCF@.microsoft.com...
> Hello,
> We had a problem that we're trying to figure out. We have a database that's
> about 3.5GB in size on a partition with about 10GB of free space. The
> database appeared normal, however when the client tried to write data to it
> we'd receive a write error message.
> We recreated the database on a different partition with 40GB free and it
> works fine now. However we're still trying to figure out why the original
> database failed and there comes the question-does SQL need contiguous free
> space to work? The drive may be fairly fragmented and while there is ~10GB
> free there may not be much contiguous space.
> Everything else with SQL appears normal.
> Thanks!
>
We had a problem that we're trying to figure out. We have a database that's
about 3.5GB in size on a partition with about 10GB of free space. The
database appeared normal, however when the client tried to write data to it
we'd receive a write error message.
We recreated the database on a different partition with 40GB free and it
works fine now. However we're still trying to figure out why the original
database failed and there comes the question-does SQL need contiguous free
space to work? The drive may be fairly fragmented and while there is ~10GB
free there may not be much contiguous space.
Everything else with SQL appears normal.
Thanks!Although a DB doesn't "need" contiguous space, it generally performs better
if it does have it.
What specifically is the error you get? Does the SQL Server service account
have write permission on that partition?
--
Tom
----
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Toronto, ON Canada
.
"Mike Chiodo" <MikeChiodo@.discussions.microsoft.com> wrote in message
news:B860E70E-2CC7-4644-A624-C21EB0373BCF@.microsoft.com...
Hello,
We had a problem that we're trying to figure out. We have a database that's
about 3.5GB in size on a partition with about 10GB of free space. The
database appeared normal, however when the client tried to write data to it
we'd receive a write error message.
We recreated the database on a different partition with 40GB free and it
works fine now. However we're still trying to figure out why the original
database failed and there comes the question-does SQL need contiguous free
space to work? The drive may be fairly fragmented and while there is ~10GB
free there may not be much contiguous space.
Everything else with SQL appears normal.
Thanks!|||Yes, the SQL server account has permission to write to that partition. As
far as the error message-it was an error generated by the program not a SQL
error.
I suspect the database was simply corrupt but don't know for certain.
Thanks for your answer-it helped clear up a piece of the puzzle.
Mike
"Tom Moreau" wrote:
> Although a DB doesn't "need" contiguous space, it generally performs better
> if it does have it.
> What specifically is the error you get? Does the SQL Server service account
> have write permission on that partition?
> --
> Tom
> ----
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
> SQL Server MVP
> Toronto, ON Canada
> ..
> "Mike Chiodo" <MikeChiodo@.discussions.microsoft.com> wrote in message
> news:B860E70E-2CC7-4644-A624-C21EB0373BCF@.microsoft.com...
> Hello,
> We had a problem that we're trying to figure out. We have a database that's
> about 3.5GB in size on a partition with about 10GB of free space. The
> database appeared normal, however when the client tried to write data to it
> we'd receive a write error message.
> We recreated the database on a different partition with 40GB free and it
> works fine now. However we're still trying to figure out why the original
> database failed and there comes the question-does SQL need contiguous free
> space to work? The drive may be fairly fragmented and while there is ~10GB
> free there may not be much contiguous space.
> Everything else with SQL appears normal.
> Thanks!
>
Subscribe to:
Posts (Atom)