Jag ville höra om någon har något bra tips. När jag skall jobba i E M så tar den en enorm lång tid på sig, oavset vad jag skall göa. Nästan 1 min innan E M har laddats upp. Skall jag titta på mina databaser, så tar det nästan lika lång tid. Jag har instalerat servicepack 3.
Finns det några inställningar som gör att man kan ändra på detta?
Jag har en AMD 1600+ 512 mb RAM 150GB hd, så hårdvaran är det inte fel på.

E M?

Ligger servern på samma dator som EM (Enterprise Manager)?

Ja, allting körs lokalt. E M = Enterprise Manager
Det är just därför som jag tycker att det känns lustigt att det tar så lång tid.
Men med tanke på att det finns ganska så många inställningar, så tänkte jag att jag kanske hade missat någonting. Jag använder enbart SQL.servern för att köra VB-Apps lokalt.

Har samma likartade problem jag med (lite slöare dator bara, men symptomen är desamma), trodde jag var ensam om detta.

Vilken typ av anslutning har du till din server? Finns där många databaser på servern? Vilket service pack har du?

Som jag skrev innan så har jag servicepack 3
Databaserna är Master, MelodiStatestikSQL(min egen), model,msdb,Northwind,pubs,tempdb.
(vilka av dessa sista kan jag ta bort?)
Anslutning till servern?? Jag jobbar ju lokalt med den, och mitt problem är ju när jag skall in i E M, där är väll ingen anslutning som jag kan styra???

> Som jag skrev innan så har jag servicepack 3

Ah, visst ja. Förstår varför det diskuteras att ha ett separat fönster för att skriva inlägg i så att man kan se hela tråden i bakgrunden. :)

> Databaserna är Master, MelodiStatestikSQL(min egen), model, msdb, Northwind, pubs, tempdb. (vilka av dessa sista kan jag ta bort?)

Northwind och pubs, om du vill. Säkerhetsmässigt är det bra att göra och på en produktionsserver finns det ingen anledning att ha lvar dem, men i en testmaskin är det lika bra att brhålla dem för att testa i.

> Anslutning till servern?? Jag jobbar ju lokalt med den, och mitt problem är ju när jag skall in i E M, där är väll ingen anslutning som jag kan styra???

Jag menade hur servern är registrerad i Enterprise Manager. Vilket nätverksprotokoll kör du (kolla i Client Network Utility och även i Server Network Utility)? Kör du Windows Authentication eller SQL Server login? Har du haft problemet hela tiden (dvs innan du installerade t ex SP3) eller är det nytt?

Jag har tyvärr ingen aning om vad problemet beror på, men som du märker så fiskar jag efter ledtrådar. Därav att jag frågar efter connection och så.

Jo jag vet hur du jobbar Christoffer, och jag har full förtröstand för det, det brukar ju alltid ge resultat.
Jag fick en krach för två veckor sedan, innan des så var E M kanonsnabb.

Client Network protokoll
Aktiverade protokoll efter ordning

TCP/IP
Namngivna pipes

Server Network protokoll

Named pipes
TCP/IP

**********
Det är m a o inte i samma ordning, kan det ha någon betydelse?

Jag kör Windows Authentication, servern är registrerad som local
Jag har förkryssat Display SQL Server State in consol (tror inte det har någon betydelse).

Jag är inte så intreserad av att behöva ominstallera, SQL Servern i sig tar ju inte så lång tid att instalera men servicepacken. Det tog en hel evighet.
Vad tror du?

**************
i en loggbok så fann jag detta:
Failed to obtain TransactionDispenserInterface: Result Code = 0x8004d01b
Betyder det någonting?

> Det är m a o inte i samma ordning, kan det ha någon betydelse?

Nej, det är bara Client Network Utility som har någon ordning, servern lyssnar på alla protokoll i listan.

> Jag kör Windows Authentication, servern är registrerad som local

Har du någon domänserver som kan vara långsam på att autenticera dig? Iofs är ju en timme inte långsamt, det är isf något som är helt fullständigt fel, men det kanske är där felet ligger isf.

> Jag har förkryssat Display SQL Server State in consol (tror inte det har någon betydelse).

Nej det ska absolut inte göra något.

> Jag är inte så intreserad av att behöva ominstallera, SQL Servern i sig tar ju inte så lång tid att instalera men servicepacken. Det tog en hel evighet.

Det är ju bara SP3 du måste installera eftersom det är kumulativt. Du kan ju prova att först bara installera klientverktygen på någon annan maskin och se om det går lika långsamt där. Hur är det egentligen med andra verktyg, ex. Query Analyzer? Om det går bra med Query Analyzer, och går bra med EM från nån annan maskin så skulle jag kunna tänka mig att det är något problem med SQL-DMO, men jag tror tyvärr inte du kan installera om bara det eller ens bara klientverktygen. Iofs kan du kanske installera om enbart klientverktygen, men då måste du nog lägga på SP3 igen för deras skull.

> i en loggbok så fann jag detta:
Failed to obtain TransactionDispenserInterface: Result Code = 0x8004d01b
Betyder det någonting?

Nja, det borde väl inte ha något med detta att göra (om det inte dyker upp varje gång du försöker starta EM), det verkar ha med MSDTC (Distributed Transaction Coordinator) att göra, kanske även något i samband med klustring (kollade inte upp det så ordentligt). Men det är ju förstås kanske inte något man ska bortse från helt och hållet, loggningar bör man väl alltid följa upp och se vad de beror på.

<Har du någon domänserver som kan vara långsam på att autenticera dig? Iofs är ju <en timme inte långsamt, det är isf något som är helt fullständigt fel, men det <kanske är där felet ligger isf.
Nix jag kör ju forfarande lokalt.
Även Query Analyzer tar tid, inte riktigt som E M men ändå.
Ingenting annat är långsamt här.

Det är ju lite plågsammt med så här trög E M, trots allt så behöver jag relativt offta komma in hit. Håller b la på med en kurs om SQL och där är en hel del uppgifter i E M så jag hade hoppats att kunna "trimma" upp den.

Tja, då föreslår jag nog en ominstallation, tyvärr är det kanske inte vad du hoppats på men det känns som det enklaste och bästa sättet att försöka lösa det här.

Nu har jag gjort slitgörat.
Avinstalerat, omstart, gick in i regedit och manuellt(!) tog bort ev nycklar som var kvar.
Körde regedit, norton utititis(windoktor) körd installationen igen, uppgraderade med sp2 och sp3.
Jg kan för mitt liv inte tänka någonting annat som man kan göra.

RESULTAT.
Ingen som helst förändring, lika dj-a slö i E M fortfarande.

Någonting måste väll ändå gå att göra??

Jag kan ha hittat ett fel. Jo jag har suttit uppe halva natten, sökt på nätet och upptäckt att jag är långt ifrån ensam om problemet.

När jag kör profiler så upptäckte jag att vissa saker tog väldigt lång tid att genoföra, så jag körde igång prestanda. Det visar sig där, att så fort som jag skall göra någonting, så går genomsnittslängd på disk kö upp i topp.
Det är tydligen där problemet ligger. Frågan, hur löser jag det?

Låter som att din disk inte mår så bra, har du kört lite bra diskverktyg mot den? Typ checkdisk, defragmentering etc. Iom att du hade en krasch innan problemen uppstod så kanske det är disken som gått riktigt sönder. Hur blir det om du kör från någon annan maskin?

Jag kör diskverktygen minst en ggr per vecka, (norton) aldrig några problem.
Disken är ny, min krack berode på att jag gav mig f-n på att jag skulle ha Creativs drvirutiner till mitt Live-kort, och då gick det som det gick.

Denna gången struntade jag i det, och inga problem.
När jag sökte på nätet så upptäckte jag en sak.
En man säger att connections (service managerr) visar fyra olika iconer.
1 vid full connections grön botten med vit triangel.
2 enkel connections vit botten med grön triangel.
3 pause
4 stopp.

Om jag skall gå på detta så har jag 2:an. Jag vet inte hur jag skall få 1:an.
Kan detta vara någonting?

Vad menar du med full och enkel connections? Ta gärna med en referens till där du hittade det. Service Managern kan vad jag vet inte visa en vit triangel på grön bakgrund, däremot visar EM en sådan när man är connectad till en server. Grön triangel på vit bakgrund betyder där att servern är igång men man är ej connectad.

Har du möjlighet att testa EM från någon annan dator? Jag är intresserad av att se om det är verktyget EM på din dator som är långsamt, eller om det är SQL Server i sig (som EM ansluter till).

Den beskrivningen om full eller enkel hittade jag på någon sida, verkar som jag inte finner den igen.
Nej jag har bara en maskin.
Nu har jag avinstallerat och ominstallerat två ggr idag, jag tänkte ge mig f-n på att klara det, men ...........

Du skall ha jättetack för att du lyssnar på mig.

PS
Jag har forfarande detta felet i loggboken, och jag kan ändå inte utesluta att det kanske kan vara någonting.

SuperSocket info: (SpnRegister) : Error 1355.

Mer information finns i Hjälp- och supportcenter på sidan http://go.microsoft.com/fwlink/events.asp.

Vad tror du?
DS

Det är inget att bry sig om, det 'felet' är egentligen bara en varning att SQL Server inte kan registrera sig i en Active Directory-domän.

http://support.microsoft.com/?kbid=303411

Hej! Jag jobbar en hel del med SQL server och är också nyfiken på orsaken till dina problem. Om jag förstod dig rätt så är det ALLT i EM som tar tid, inte bara uppkopplingen. Om du t.ex. lägger till IDENTITY på en kolumn i en tabell via EM så sker en hel del och du kan få det scriptet som körs lagrat till fil. Om du sedan tar bort IDENTITY igen och testar att köra scriptet från QA, är det någon märkbar skillnad då? Orsaken till min fråga är att jag vill försöka isolera problemet till databasen eller EM.
/Martin Höglund

Hej Martin.
Jag är jättetacksam för att du försöker hjälpa mig.
Först.
Att bara klicka på genvägen för att öppna EM ta mellan en och två minuter. I EM så vad jag än skall göra, så tar det mellan 30 sec upp till en minut.
i en dubblettabel så la jag till INDENTITY(vill int jobba mot viktig data än).
För att få det där scriptet, så fick jag grunna ordentligt, men jag antar att jag skulle in i Generate SQL.Script och fick fram följande script.
<code>
if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[t_SongTitlarOLD]') and OBJECTPROPERTY(id, N'IsUserTable') = 1)
drop table [dbo].[t_SongTitlarOLD]
GO

CREATE TABLE [dbo].[t_SongTitlarOLD] (
[ArrNo] [nvarchar] (3) COLLATE Finnish_Swedish_CI_AS NOT NULL ,
[songtitel] [nvarchar] (50) COLLATE Finnish_Swedish_CI_AS NULL ,
[Album] [int] NULL ,
[Kategori] [int] NULL ,
[Hide] [bit] NOT NULL ,
[kolla] [int] IDENTITY (1, 1) NOT NULL
) ON [PRIMARY]
GO
</code>
Jag startade därefter upp QA(även den tar sin tid, men inte så lång tid som EM)
Att sedan klicka i listboxen för att byta databas(jag vet jag kan skriva detta i skiptet men... det tar ialla fal en god stund).
När jag sedan kör scriptet(med bortagen IDENTITY, så tycker jag mig se att det tar lite kortare tid.
JAg tänkte också på en annan sak, på Microsoft sida så såg jag ett script som skulle compacta och reparera databas, är det någonting att försöka med???

Här har jag lagt in loggen för idag, säger det er någonting?(ursäkta att den är lite stor)
<code>
2003-02-08 10:44:30.79 server Microsoft SQL Server 2000 - 8.00.760 (Intel X86)
Dec 17 2002 14:22:05
Copyright (c) 1988-2003 Microsoft Corporation
Developer Edition on Windows NT 5.1 (Build 2600: )

2003-02-08 10:44:30.79 server Copyright (C) 1988-2002 Microsoft Corporation.
2003-02-08 10:44:30.79 server All rights reserved.
2003-02-08 10:44:30.79 server Server Process ID is 1500.
2003-02-08 10:44:30.79 server Logging SQL Server messages in file 'C:\Program\Microsoft SQL Server\MSSQL\log\ERRORLOG'.
2003-02-08 10:44:30.85 server SQL Server is starting at priority class 'normal'(1 CPU detected).
2003-02-08 10:44:31.21 server SQL Server configured for thread mode processing.
2003-02-08 10:44:31.22 server Using dynamic lock allocation. [2500] Lock Blocks, [5000] Lock Owner Blocks.
2003-02-08 10:44:31.36 server Attempting to initialize Distributed Transaction Coordinator.
'VAD BETYDER DETTA???
2003-02-08 10:44:31.97 server Failed to obtain TransactionDispenserInterface: Result Code = 0x8004d01b
2003-02-08 10:44:32.11 spid3 Starting up database 'master'.
2003-02-08 10:44:33.56 spid3 Server name is 'SAWDATA'.
2003-02-08 10:44:33.57 server Using 'SSNETLIB.DLL' version '8.0.760'.
2003-02-08 10:44:33.57 spid5 Starting up database 'model'.
2003-02-08 10:44:33.57 spid8 Starting up database 'msdb'.
2003-02-08 10:44:33.62 spid9 Starting up database 'pubs'.
2003-02-08 10:44:33.97 server SQL server listening on 213.114.35.154: 1433.
2003-02-08 10:44:33.97 server SQL server listening on 127.0.0.1: 1433.
2003-02-08 10:44:33.99 spid10 Starting up database 'Northwind'.
2003-02-08 10:44:33.99 spid11 Starting up database 'MelodiStatestikSQL'.
2003-02-08 10:44:35.90 spid5 Clearing tempdb database.
2003-02-08 10:44:36.24 server SQL server listening on TCP, Shared Memory, Named Pipes, Rpc.
2003-02-08 10:44:36.24 server SQL Server is ready for client connections
2003-02-08 10:44:38.27 spid5 Starting up database 'tempdb'.
2003-02-08 10:44:38.44 spid3 Recovery complete.
2003-02-08 10:44:38.44 spid3 SQL global counter collection task is created.
2003-02-08 11:02:18.96 spid51 Using 'xpstar.dll' version '2000.80.760' to execute extended stored procedure 'sp_MSgetversion'.
</code>

Kan detta hjälpa tro?
Vad som är av intresse är, när jag tar kontakt me servern via min VB-app så går det oehört fort, men så fort som jag försöker att göra någonting administativt(EM QA) då tar det jättelång tid.
En vanlig selectsats(select * from t_Album) innehåller fyra fält och generera fem poster tar över tre minuter.
Då förstår du kanske min förfrågan bättre.

Jag ser inga problem i loggen, förutom naturligtvis att DTCn strular. Om du inte behöver den så ta bort så att den inte autostartar (antingen i Services i Administrative Tools, eller i SQL Service Managern i taskbaren, byta till DTC där och kryssa bort autostart).

Som jag sa en gång tidigare så börjar jag undra om inte problemet ligger i SQL-DMO. Det som är konstigt är ju att du installerat om, men eftersom din VB-app fungerar bra så lutar det ändå ditåt. Har du testat köra med osql eller isql och sett om det går fort där?

Nja, jag får upp "not assossiated with a trusted SQL-Server"
Konstigt, för jag har lösenord både på sa och mig själv.
Apropå SQL-DMO går det att lösa den biten, konfigurera,reparera eller?

Kör följande och testa:

osql -Usa -Plösenord -Sservernamn -ddatabasnamn

Om du vill köra med Windows User login (den inloggade användaren alltså, förmodligen du):

osql -E -Sservernamn -ddatabasnamn

Ang. SQL-DMO så verkar det skumt, med tanke på att du har installerat om och då borde rimligen även de filerna uppdaterats.

Nja, det går inte snabbt, utan det tar sin tid. Över 30 sec för att ta fram 30 poster ur en enkel SQL-sats med 8 fält.
("select * from t_songtitlar")
Så någonting är det.

Tja, jag måste säga att jag höll helt med Christoffer - fram till ditt sista svar. Såvitt jag vet använder osql inte SQL-DMO så det borde gått fortare där. Jag har inga fler idéer f.n, tyvärr.

Jag är väldigt tacksam att ni har försökt att hjälpa mig. Tyvärr har det inte resulterat i någon ändring. Om ut ifall ni får någon bra ide, så är jag tacksam för info.

Har någonting blivit bättre sedan ominstallation? Går det t ex snabbare att logga in eller något? Tar det lika lång tid för en liknande enkel SELECT i någon annan databas (t ex pubs)?

Har du flera diskar? Kan du testa att lägga alla data (och loggar etc) på någon annan disk isf? Har du testat att köra DBCC CHECKDB på databasen? Kanske inte så kul om databasen är så långsam, men det kanske kan visa något problem.

Hej Christoffer.
Nej ingenting är annulunda efter ominstallationen.
Själva inloggningen t ex i QA ta i o f ca 10 sec. I em så innan jag kan göra någonting upp imot en minut, ibland mera.
Vilken databas jag än använder har ingen som helst betydelse.
Jag har flera diskar. Databasen MelodistatestikSQL ligger(med loggar) på f:
Jag körde just DBCC CHECKDB , tog ca: 10 - 12 sec på min databas (och även master).
Detta uppfatar jag som kanske inte så längsamt.
Jag har min installation annars på c:, jag funderade ett slag på att flytta installationen, men är osäker på att det hjälper mig.

Hej Christoffer.
Nej ingenting är annulunda efter ominstallationen.
Själva inloggningen t ex i QA ta i o f ca 10 sec. I em så innan jag kan göra någonting upp imot en minut, ibland mera.
Vilken databas jag än använder har ingen som helst betydelse.
Jag har flera diskar. Databasen MelodistatestikSQL ligger(med loggar) på f:
Jag körde just DBCC CHECKDB , tog ca: 10 - 12 sec på min databas (och även master).
Detta uppfatar jag som kanske inte så längsamt.
Jag har min installation annars på c:, jag funderade ett slag på att flytta installationen, men är osäker på att det hjälper mig.

Nej det är absolut inte lång tid för CHECKDB nej. Jag vet inte vad man ska säga, har tyvärr ingen riktigt bra idé om vad det kan bero på nu. En fullständig ominstallation av maskinen kanske kan hjälpa, men det är ju inte speciellt kul. Annars är det väl bara att öppna ett support case hos MS, kanske de kan hjälpa.

Har du frågat efter hjälp på fler platser? Newsgrupperna brukar vara bra, där finns flera superexperter som kanske har sett det här tidigare.

NU är allt klart.
Efter massor med letande, och många dagar(veckor) så har jag hittat problemet.

1. ODBS spårningen var på. DVS i administration/Datakälla/ODBC/spårning, så var denna på, därav den långa accesstiden.
Nu när jag jag har stängt av den, så öppnar jag EM på 2 sec, tabellerna under 1 sec.

2. Autoclose ej checkad
3. Autochrink ej checkad

Det var nog allt, men det gör underverk.

Tack för att ni har försökt att hjälpa mig och inte givit upp.
Jag hoppas också att dessa uppgifter kan hjälpa någon som har samma problem som jag har haft.

Härligt!
Intressant att det var det som var problemet, men jag förstår inte riktigt varför ODBC påverkar det. Jag testade lite, och om man t ex tar bort den System DSN som heter LocalServer och som skapas automatiskt när man installerar SQL Server så kan man ha tracing på utan problem. Men Enterprise Manager ska vad jag vet inte använda ODBC på något sätt för att connecta, den jobbar ju med SQL-DMO och som sagt, man kan ta bort LocalServer-dsn utan att det blir några problem i EM. Mycket skumt, jag ska testa lite mer senare...