Showing posts with label everyonei. Show all posts
Showing posts with label everyonei. Show all posts

Monday, March 12, 2012

Maximum number of rows?

Hello Everyone:
I have been told by our DBA that SQL Server 2000 has problems
with tables that contain more than 13 million reocords, in particular
with indexes. He was not more specific(!).
Our group is in the process of developing an application and a couple
of the tables we will be using will contain up to 50 million records.
My worry here, is that if what our DBA said is correct that we need to
take this into account early in the DB design phase because any
structural changes to the DB have impact on the procedures, functions,
etc as well as the application.
I had not heard any such statement previously made and in fact my experience
has been quite positive with larger tables (over 20 million).
Nevertheless I am still somewhat concerned at the prospect of finding
out he was correct "after the fact", so to speak, and thus causing considera
ble
effort going into a work around after we are in production.
If anyone has heard or knows of anything of the sort I would be very thankfu
l
for your advice or to hear your experiences, especially under what
circumstances if any does SQL Server have problems.
Regards,
MarioN of rows is limited only with storage capacity (check
http://msdn.microsoft.com/library/d...br />
8dbn.asp).
Personally, I worked with a table with 3.5 billions rows without a
problem...
Dejan Sarka, SQL Server MVP
Associate Mentor
Solid Quality Learning
More than just Training
www.SolidQualityLearning.com
"Mario" <anonymous@.discussions.microsoft.com> wrote in message
news:94D5DF8D-D5BE-4563-A4A3-E29485D36E09@.microsoft.com...
> Hello Everyone:
> I have been told by our DBA that SQL Server 2000 has problems
> with tables that contain more than 13 million reocords, in particular
> with indexes. He was not more specific(!).
> Our group is in the process of developing an application and a couple
> of the tables we will be using will contain up to 50 million records.
> My worry here, is that if what our DBA said is correct that we need to
> take this into account early in the DB design phase because any
> structural changes to the DB have impact on the procedures, functions,
> etc as well as the application.
> I had not heard any such statement previously made and in fact my
experience
> has been quite positive with larger tables (over 20 million).
> Nevertheless I am still somewhat concerned at the prospect of finding
> out he was correct "after the fact", so to speak, and thus causing
considerable
> effort going into a work around after we are in production.
> If anyone has heard or knows of anything of the sort I would be very
thankful
> for your advice or to hear your experiences, especially under what
> circumstances if any does SQL Server have problems.
> Regards,
> Mario
>|||I am not aware of any problems at all. 13 million rows is quite a small
number as far as SQL Server is concerned. I have no ideas where the "DBA"
plucked this figure from - I would be interested to hear where. Even if you
use bigint as the PK for a table you could have 9,223,372,036,854,775,807
rows (I can't say that number, so have to write it down as digits). :-)
Mark Allison
SQL Server MVP
http://www.allisonmitchell.com
"Mario" <anonymous@.discussions.microsoft.com> wrote in message
news:94D5DF8D-D5BE-4563-A4A3-E29485D36E09@.microsoft.com...
> Hello Everyone:
> I have been told by our DBA that SQL Server 2000 has problems
> with tables that contain more than 13 million reocords, in particular
> with indexes. He was not more specific(!).
> Our group is in the process of developing an application and a couple
> of the tables we will be using will contain up to 50 million records.
> My worry here, is that if what our DBA said is correct that we need to
> take this into account early in the DB design phase because any
> structural changes to the DB have impact on the procedures, functions,
> etc as well as the application.
> I had not heard any such statement previously made and in fact my
experience
> has been quite positive with larger tables (over 20 million).
> Nevertheless I am still somewhat concerned at the prospect of finding
> out he was correct "after the fact", so to speak, and thus causing
considerable
> effort going into a work around after we are in production.
> If anyone has heard or knows of anything of the sort I would be very
thankful
> for your advice or to hear your experiences, especially under what
> circumstances if any does SQL Server have problems.
> Regards,
> Mario
>|||You'll run against the storage capacity limits of SQL Server long before you
reach that number. The maximum size for a database is 1,048,516 Tera Bytes,
and you're talking about approximately 9,000,000 Tera rows.
"DBA" indeed. Mario, both Mark and me are on the market at the moment ;-)
Jacco Schalkwijk
SQL Server MVP
"Mark Allison" <mark@.allisonmitchellyourpants.c0m> wrote in message
news:uieUWhW8DHA.2524@.TK2MSFTNGP11.phx.gbl...
> I am not aware of any problems at all. 13 million rows is quite a small
> number as far as SQL Server is concerned. I have no ideas where the "DBA"
> plucked this figure from - I would be interested to hear where. Even if
you
> use bigint as the PK for a table you could have 9,223,372,036,854,775,807
> rows (I can't say that number, so have to write it down as digits). :-)
> --
> Mark Allison
> SQL Server MVP
> http://www.allisonmitchell.com
> "Mario" <anonymous@.discussions.microsoft.com> wrote in message
> news:94D5DF8D-D5BE-4563-A4A3-E29485D36E09@.microsoft.com...
> experience
> considerable
> thankful
>|||Jacco,
my feelings exactly.
Earlier today I asked him to provide a source for his statement should anyth
ing turn up I'll post back here.
Thanks again!
Mario

Friday, March 9, 2012

Maximum memory problem

Hello, everyone:

I have SQL Server 2000 Standard Edition running on Windows 2000 Server. There are always memory full alter. I am going to configure that.

I hope a clearation about a concept. In my enviroment, does SQL Server take maximum memroy upto 2GB, no matter if QWE is enabled?

BOL said AWE is available only in the SQL Server 2000 Enterprise and Developer editions. Does it mean AWE cannot be configured on SQL Server 2000 Standard Edition?

Thanks

ZYTIt's suppose to do that

What? You have other things running on the box?|||Hi, Brett:

No other application is running, only sql server. The physical memory is 4GB. There are alerts. The team in considering to add memory. But it is worried new memory is useless because sql server standard version only take 2GB.

It's suppose to do that

What? You have other things running on the box?|||Yes, AWE cannot be used with SQL Server 2000 Standard Edition. It's limited to 2GB of memory.|||Yes, AWE cannot be used with SQL Server 2000 Standard Edition. It's limited to 2GB of memory.

Not only that, but he's running Windows 2000 Standard. OS Limit is 4GB. No benefit to running AWE on that platform.

AWE is used once you get above 4GB RAM. To get >4 GB RAM, you will need:

Windows 2000 Advanced Server (up to 8 GB RAM)
Windows 2000 Datacenter (Can't remember the limit)
Windows 2003 Enterprise (up to 32 GB RAM)
Windows 2003 Datacenter (up to 64 GB RAM)

Or you could go with Windows 2003 x64 and basically ignore your RAM limits.:shocked:

Regards,

hmscott

Monday, February 20, 2012

MAX(DATE) - help

Hello everyone:

i am trying to compare a MAX(DATE) from one table that would be greater
than a date in another.

first_table

compname MYDATE

abc comp 2006-09-26 09:19:43.250
123inc 2006-10-20 01:3:00.250

SELECT MAX(MYDATE) FROM first_table

log_table

logdate

2006-01-15 05:12:41.250

I would like to get the MAX(MYDATE) which is greater than the logdate.

thx

f.Freddie ,
If I understand correctly ,

What you want all the dates in log_table having date less than
max(date) in first table

SELECT * FROM log_table WHERE log_date < (SELECT MAX(DATE) FROM
first_table)

M A Srinivas
Freddie wrote:

Quote:

Originally Posted by

Hello everyone:
>
i am trying to compare a MAX(DATE) from one table that would be greater
than a date in another.
>
first_table
>
compname MYDATE
>
abc comp 2006-09-26 09:19:43.250
123inc 2006-10-20 01:3:00.250
>
SELECT MAX(MYDATE) FROM first_table
>
log_table
>
logdate
>
2006-01-15 05:12:41.250
>
I would like to get the MAX(MYDATE) which is greater than the logdate.
>
>
thx
>
f.