HI all,
I have a pentium 4 3.GIG dual processor 1GIG ram server, that has Exchange
5.5 and MSDE 2000. Are their any bad side effects to this setup. That is,
speed issues, load etc. Will the current setup support this.
Thanks
Robert
hi Robert,
Robert Bravery wrote:
> HI all,
> I have a pentium 4 3.GIG dual processor 1GIG ram server, that has
> Exchange
> 5.5 and MSDE 2000. Are their any bad side effects to this setup. That
> is, speed issues, load etc. Will the current setup support this.
usually Exchange is not a good companion for SQL Server... it is supported,
but if you can afford separated boxes.... :D
Andrea Montanari (Microsoft MVP - SQL Server)
http://www.asql.biz/DbaMgr.shtmhttp://italy.mvps.org
DbaMgr2k ver 0.15.0 - DbaMgr ver 0.60.0
(my vb6+sql-dmo little try to provide MS MSDE 1.0 and MSDE 2000 a visual
interface)
-- remove DMO to reply
|||HI Andrea,
THanks for the info. I'm trying to isolate some networking problems. Re- my
repvious post concerning MSDE, which you answered. What I am trying to
figure out is that if MSDE is on the same box as Exchange, would I
experience offline and connections dropping from client pc's. The server in
question is a pIV3.0gig, 1gig RAM, raid5, 180gig free HD
THanks
Robert
"Andrea Montanari" <andrea.sqlDMO@.virgilio.it> wrote in message
news:3sbpu5Fn2vgmU1@.individual.net...
> hi Robert,
> Robert Bravery wrote:
> usually Exchange is not a good companion for SQL Server... it is
supported,
> but if you can afford separated boxes.... :D
> --
> Andrea Montanari (Microsoft MVP - SQL Server)
> http://www.asql.biz/DbaMgr.shtmhttp://italy.mvps.org
> DbaMgr2k ver 0.15.0 - DbaMgr ver 0.60.0
> (my vb6+sql-dmo little try to provide MS MSDE 1.0 and MSDE 2000 a visual
> interface)
> -- remove DMO to reply
>
Showing posts with label gig. Show all posts
Showing posts with label gig. Show all posts
Friday, March 30, 2012
MSDE and clustered indexes.
We have this weird problem with our customers using MSDE. They keep running
up against the 2 gig size limit and their database stops functioning because
it can't allocate any more space. But if you examine the database, 75% of
the allocated space is unused. It can't be recovered by shrinking the
database. The only way we can reduce the database size is to copy all the
data into a temporary database, delete it from the original and then
re-insert in the original. Yesterday we did this and a customer's database
was reduced to 528 MB from 1.913 GB. We run a weely job that shrinks and
re-indexes everything but it doesn't have any effect on this problem. I
suspect that it has something to do with the fact that there are no
clustered indexes on any of the table so the re-index job is not doing
anything. But maybe my understanding of this is inaccurate. Is this problem
because of the lack of clustered indexes?If there are no clustered indexes, the table is essentially a "heap". Data
will be appended at the end. If the application delete large amounts of dat
a
and re-inserts it, the most likely be large gaps in the middle.
Objects such as triggers can cause "delete/insert" pairs instead of
"in-place" updates, fill-factor can be a potential cause, etc. Clustered
indexes may not help if the natural key is ever-increasing, since holes will
still exist after large deletes. Non-clustered indexes may help
space-reclamation.
Find out what type of activity is occuring and take appropriate action.
"Bob Castleman" wrote:
> We have this weird problem with our customers using MSDE. They keep runnin
g
> up against the 2 gig size limit and their database stops functioning becau
se
> it can't allocate any more space. But if you examine the database, 75% of
> the allocated space is unused. It can't be recovered by shrinking the
> database. The only way we can reduce the database size is to copy all the
> data into a temporary database, delete it from the original and then
> re-insert in the original. Yesterday we did this and a customer's database
> was reduced to 528 MB from 1.913 GB. We run a weely job that shrinks and
> re-indexes everything but it doesn't have any effect on this problem. I
> suspect that it has something to do with the fact that there are no
> clustered indexes on any of the table so the re-index job is not doing
> anything. But maybe my understanding of this is inaccurate. Is this proble
m
> because of the lack of clustered indexes?
>
>|||Any new devolepments with this issue, where the clustered indexes an issue o
r not? Anyone had a case like this?
Thanks.
up against the 2 gig size limit and their database stops functioning because
it can't allocate any more space. But if you examine the database, 75% of
the allocated space is unused. It can't be recovered by shrinking the
database. The only way we can reduce the database size is to copy all the
data into a temporary database, delete it from the original and then
re-insert in the original. Yesterday we did this and a customer's database
was reduced to 528 MB from 1.913 GB. We run a weely job that shrinks and
re-indexes everything but it doesn't have any effect on this problem. I
suspect that it has something to do with the fact that there are no
clustered indexes on any of the table so the re-index job is not doing
anything. But maybe my understanding of this is inaccurate. Is this problem
because of the lack of clustered indexes?If there are no clustered indexes, the table is essentially a "heap". Data
will be appended at the end. If the application delete large amounts of dat
a
and re-inserts it, the most likely be large gaps in the middle.
Objects such as triggers can cause "delete/insert" pairs instead of
"in-place" updates, fill-factor can be a potential cause, etc. Clustered
indexes may not help if the natural key is ever-increasing, since holes will
still exist after large deletes. Non-clustered indexes may help
space-reclamation.
Find out what type of activity is occuring and take appropriate action.
"Bob Castleman" wrote:
> We have this weird problem with our customers using MSDE. They keep runnin
g
> up against the 2 gig size limit and their database stops functioning becau
se
> it can't allocate any more space. But if you examine the database, 75% of
> the allocated space is unused. It can't be recovered by shrinking the
> database. The only way we can reduce the database size is to copy all the
> data into a temporary database, delete it from the original and then
> re-insert in the original. Yesterday we did this and a customer's database
> was reduced to 528 MB from 1.913 GB. We run a weely job that shrinks and
> re-indexes everything but it doesn't have any effect on this problem. I
> suspect that it has something to do with the fact that there are no
> clustered indexes on any of the table so the re-index job is not doing
> anything. But maybe my understanding of this is inaccurate. Is this proble
m
> because of the lack of clustered indexes?
>
>|||Any new devolepments with this issue, where the clustered indexes an issue o
r not? Anyone had a case like this?
Thanks.
Friday, March 9, 2012
MSDE
I looking for some guidance here. I have database which has exceeded the 2 gig limit. I deleted some old tables in an attempt to acquire some space. This worked out. However when I look at the size of my *.mdf it still appears in excess of the 2 gigs . I know this isn't true since I deleted 500 megs of stuff. How do i reclaim the space (get the file size to report correctly) or do I need to even worry about it.
Andy
AndyYou might try first backing up the database and then running the "Shrink" command. In Enterprise Manager Select the database, right click and select "Shrink..." from the list of commands. If you don't have Enterprise Manager you can try this command through osql or equivalent.
|||Thanks for your reply and help. I was just about to attempt it when I realized from reading another article on the subject than MSDE dynamically recalculates and adjusts files and indices. Turns out all I had to do was be patient and it took care of itself. This apparently is different functionality from the full blown version of SQL2000. Anyhow, thanks
DBCC SHRINKDATABASE ([YourDatabaseName], 0)
Andy
Subscribe to:
Posts (Atom)