SqlServer Express i RESTORE

[ Astek @ 07.04.2007. 20:24 ] @

Evo još malo da gnjavim...

1. Iz koda pozivam SP kojom se kreira backup baze podataka....
otprilike ovako
ALTER PROCEDURE [dbo].[SP_CREATE_BACKUP]
@PATH nvarchar(255),
@DBNAME nvarchar(255),
@LOGNAME nvarchar(255)
AS
BACKUP DATABASE @DBNAME TO DISK= @LOGNAME

kreira *.bak fajl i to radi Ok.

2. E sada hoću da obnovim te podatke..
bitan deo koda je otprilike ovako

..............................................................................

Dim conn As New SqlClient.SqlConnection
Try
conn.ConnectionString = oOpcije.Connection_String_Master ' probao sam konekciju i na moju bazu i na master bazu ali ne ide
conn.Open()
Dim sqlCommand As New SqlClient.SqlCommand
sqlCommand.CommandText = "RESTORE DATABASE MOJA_BAZA FROM DISK='" & sBackupPath & "'"
sqlCommand.CommandType = CommandType.Text
sqlCommand.Connection = conn
sqlCommand.ExecuteNonQuery()
sqlCommand.Dispose()
sqlCommand = Nothing

Catch e As Exception
Dim sMSG1 = "Greška u frmRestore.Oporavi: "
Dim oFrmMsg1 As New frmMsg(sMSG1 & e.Message, 1)
WriteError(sMSG1 & e.Message)
oFrmMsg1.Dispose()
oFrmMsg1 = Nothing
Finally
conn.Close()
conn = Nothing
End Try
...........................................................................................

I javlja grešku (u prilogu je)

Primetio sam sledeće:

1. Ako funkciju za oporavak pozovem kao prvi poziv bazi podataka radi OK.
2. Ako , recimo, najpre se obratim bazi da izvršim npr proveru prava prijavljenog korisnika, onda ne radi.
Koliko mi se čini sve konekcije prema bazi zatvaram.

Zna li neko gde je problem? Da li ovo uopšte može da se reši na ovaj način?
Hvala svima unapred.

[ mmix @ 09.04.2007. 12:55 ] @

Ti jesi zatvorio konekciju ali ona nije "fizicki" zatvorena, ostala je u connection pool-u. Iskotristi ovaj metod da zatvoris sve konekcije iz pool-a pre nego otvoris svoju za restore:
http://msdn2.microsoft.com/en-...t.sqlconnection.clearpool.aspx

[ Astek @ 09.04.2007. 18:36 ] @

Najpre hvala .

Ovako sam uradio...

1. Svako gašenje konekcije sam sproveo otprilike ovako..

conn.Close
conn=nothing
sqlClient.SqlConnection.ClearPool(conn)

2. Neposredno pre poziva master baze da bi izvrsio restore ubacio sam
SqlClient.CqlConnection.ClearAllPools()
pa tek onda otvorio konekciju prema master bazi
ali ponovo isti problem iz priloga? Da nije neophodno u ConnectionString uključiti parametre poput:Pooling=true itd..?

[ mmix @ 09.04.2007. 19:18 ] @

Umlati ti komarca pneumatskim cekicem

sqlClient.SqlConnection.ClearPool(conn) je vise nego dovoljan i to samo jedanput, pre nego sto otvoris svoju konekciju koja radi restore. To sto ti radis zapravo ponistava celu svrhu connection pool-a posto nikad ne dozvoljavas da se konekcija uopste tamo zadrzi.

Vrlo je moguce da ti drzis jednu konekciju otvorenu negde sa strane (Query analyzer ili sam VS.NET) koja te blokira. Da bi to otkrio, stavi breakpoint na ClearPool(), otvori sa strane Query Analyzer i konektuj se na server, na master bazu, izvrsi ClearPool() i potom u QA izvrsi sledecu "skriptu"

Code:

select s2.name, s1.status, s1.hostname, s1.program_name, s1.loginame from sysprocesses s1
inner join sysdatabases s2 on s1.dbid = s2.dbid
order by s2.name

i vidi koliko konekcija imas na tvoju bazu i koji programi/useri ih drze. U ove dve tabele imas jos korisnih informacija, ubaci * u select ako hoces da vidis sve.

[ bunker @ 09.04.2007. 21:59 ] @

Pooling=true je default. Ako u conn stringu postavis Pooling=false, dobicces sta si trazio.
Pozdrav.

[ Astek @ 10.04.2007. 08:11 ] @

Izgleda da je predhodno moje objašnjenje bilo konfuzno. Mislio sam u stvari ovo..

Citat:

Astek: Najpre hvala .
1. Svako gašenje konekcije sam sproveo otprilike ovako..

conn.Close
conn=nothing
sqlClient.SqlConnection.ClearPool(conn)

Ovo je deo metode neke klase koju pozivam više puta pre nego što probam Restore. Ovaj deo koda je potpuno nezavistan od sledećeg koji koristim pre nego što pokušam da u nekoj funkciji izvršim Restore

2. Neposredno pre poziva master baze da bi izvrsio restore ubacio sam
SqlClient.CqlConnection.ClearAllPools()
pa tek onda otvorio konekciju prema master bazi i pokušao da uradim restore..

Pokušaću danas da uhvatim šta mi napada bazu pa ću da javim.

[ bunker @ 10.04.2007. 10:15 ] @

I posle ovoga ako pogledas broj konekcija prema bazi, dobicces najmanje dve. Ovo je stvar pooling-a. Imao sam probleme jednom prilikom sa restorovanjem baze iz aplikacije i mogu ti recci da sam ga resio na onaj nacin kao sto sam ti opisao. Iako sam konekciju drzao u singleton-u ipak su se pojavljivale dve. Da, radilo se o desktop aplikaciji, pa nisam imao potrebe za pooling-om.
Ako ti je problem da iskljucis pool na nivou aplikacije, ti napravi novi connection string gde cces da postavis pooling=false. Neccu da budem napadan, ali ja sam tako resio problem.
Bez obzira sto si rekao ClearAllPools, kad otvoris konekciju, poll cce se opet aktivirati.

conn.ConnectionString = "integrated security=SSPI;SERVER=YOUR_SERVER;DATABASE=YOUR_DB_NAME;Pooling=false;Connect Timeout=45;";

[ Astek @ 10.04.2007. 17:30 ] @

Citat:

bunker: I posle ovoga ako pogledas broj konekcija prema bazi, dobicces najmanje dve. Ovo je stvar pooling-a. Imao sam probleme jednom prilikom sa restorovanjem baze iz aplikacije i mogu ti recci da sam ga resio na onaj nacin kao sto sam ti opisao. Iako sam konekciju drzao u singleton-u ipak su se pojavljivale dve. Da, radilo se o desktop aplikaciji, pa nisam imao potrebe za pooling-om.
Ako ti je problem da iskljucis pool na nivou aplikacije, ti napravi novi connection string gde cces da postavis pooling=false. Neccu da budem napadan, ali ja sam tako resio problem.
Bez obzira sto si rekao ClearAllPools, kad otvoris konekciju, poll cce se opet aktivirati.

conn.ConnectionString = "integrated security=SSPI;SERVER=YOUR_SERVER;DATABASE=YOUR_DB_NAME;Pooling=false;Connect Timeout=45;";

Nisam napadan, hvala ti mnogo na sugestijama. Samo nisam stigao da ti odgovorim. Tek sada sam seo za racunar , pa cu da probam. Inace tacno je da uvek imam dve konekcije prema bazi.

[ mmix @ 10.04.2007. 18:25 ] @

Aman, ljudi, ne secite ruku da biste lecili ogrebotinu. Najlakse resenje nije uvek i najbolje, umesto sto iskljucujete pooling, bolje dijagnostikujte odakle vam uospte dve konekcije. Otvaranje konekcije je najskuplji proces u radu sa bazom kako po klijenta tako i po server i ne treba iskljucivati pooling bez potrebe.
Pool nikad ne raste sam, prva konekcija otvara pool sa samo jednom konekcijom (osim ako connection string ne sadrzi "Min Pool Size" parametar, koji je po default-u 0). Ako je ta konekcija 'alocirana' (postoji ziv ADO.NET connection objekat nad njom) kreiranje novog sqlConnection objekta sa istim connection stringom dodaje novu konekciju u pool i tako pool raste. Ako pool nije prazan posle ClearPool() to znaci da ima sqlConnection objekata koji nisu zatvoreni.

Citat:

Dok god postoje zivi sqlConnection objekti ClearPool nece izbaciti te konekcije iz pool-a. Singleton pattern je u ovom slucaju krivac za to posto drzi zivu instancu connection objekta tokom celog zivota procesa. Da bi se konekcija vratila u pool, Close ili Dispose mora biti pozvan. Moze isto lako da se desi da je negde kreiran sqlConnection objekat i onda nije eksplicitno zatvoren i otisao je off-scope, konekcija nece biti zatvorane dok god GC ne resi da unisti objekat i do tada konekcija ne odlazi nazad u pool. Da to dijagnostikujes, uradi GC.Collect(0) pre Clear Pool(), ako se problem resi onda imas taj bug negde u aplikaciji (good luck u trazenju).

Druga stvar, connection pool se kreira na nivou procesa po osnovu connection stringa, ne baze. Moguce je imati dva i vise poolova nad istom bazom u okviru istog procesa ili vise poolova u razlicitim procesima nad istim connection stringom, pa moze da se desi da restore pukne ioako je pool prazan zato sto neko drugi druzi otvorenu konekciju u drugom poolu/procesu nad istom bazom. Ovo je izrazito vazno za desktop aplikacije gde dva i vise korisnika rade paralelno.

U principu koriscenje singletona za cuvanje zivog connection objekta je losa praksa. Thread safety ode kroz prozor. Bolje drzati connection string u signletonu i metod koji kreira konekcije na zahtev. Tako imas centralizovanu kontrolu nad konekcijama i centralizaovanu kofiguraciju a zadrzavas slobodu.

[ Astek @ 10.04.2007. 20:44 ] @

evo ovako..

1. Krivac što Restore ne radi kako treba sam ja: nisam eksplicitno sa close zatvorio bar jednu konekciju .
2. Napravio sam mali projekat gde sam eksperimentisao sa oba rešenja. U pravu ste obojica: i jedno i drugo rešenje funkcionišu korektno. Meni iz tehničkih razloga više odgovara SqlClient.SqlConnection.ClearPool(conn).
Nisam imao dosad prilike da se susretnem sa ovakvim problemom.

Spasili ste me velike bede...

Pozdrav i zahvaljujem još jednom.