kazarma Ierakstīts Maijs 24, 2017 Share Ierakstīts Maijs 24, 2017 Sveiki, vajag kādu specu, kurš var šo darbiņu paveikt. Tā kā nav īsti mans lauciņš es nonācu līdz: 1) Sagatavoju Scriptu kollonām, lai izmainītu kolāciju. 2) Sagatavoju Scriptu kollonām, lai piefiksētu indexus un Foreign key. 3) Sagatavoju Scriptu Kollonām, lai nomestu indexus un Foreign key. Izpilde bija 1->2->3->1(outputu ievadu) un te sākās problēmas. Tāpēc vēlos noalgot specu, kurš šo darbiņu varētu paveikt, jo esmu aizgājis tālu aiz savas kompetences robežām. Datubāze ir maza 200 tabulas, kopējais izmērs ~31MB. Link to comment Share on other sites More sharing options...
Ronalds Maijs 24, 2017 Share Maijs 24, 2017 Ar šo skriptu nesanāk nomainīt? https://stackoverflow.com/questions/18122773/change-collations-of-all-columns-of-all-tables-in-sql-server Link to comment Share on other sites More sharing options...
kazarma Maijs 24, 2017 Author Share Maijs 24, 2017 Tas strādātu, ja nebūtu indexu un FK constreintu. "Columns has to be index and constraint free for this to work." Pašam ir īsāks skripts, kas šo pašu paveic. Problēma ir ar indexiem un FK Constreitiem. Link to comment Share on other sites More sharing options...
Ronalds Maijs 24, 2017 Share Maijs 24, 2017 Nu tad - nodumpo sql bāzes struktūru iekš sql skripta. nodumpo datus iekš insert skripta. Ar search/replace izmaini Collation. Uz jaunas bāzes palaid abus skriptus. Link to comment Share on other sites More sharing options...
kazarma Maijs 24, 2017 Author Share Maijs 24, 2017 Nu tad šitas nav mysql, kur to var bez problēmām izdarīt. Tas MS sql, kur viss notiek caur d. Link to comment Share on other sites More sharing options...
Ronalds Maijs 24, 2017 Share Maijs 24, 2017 Arī MS SQL var nodumpot bāzi uz insert skriptu! Piekrītu ka iekš mysql būtu vienkāršāk, bet arī iekš mssql tas ir izdarāms! Tik vienīgi problēma ar FK.... insert skripts var datus nepareizā secībā likt iekš tabulām. Te vajadzētu sākumā tabulas sataisīt, tad datus iekšā, tad FK. Link to comment Share on other sites More sharing options...
kazarma Maijs 24, 2017 Author Share Maijs 24, 2017 Jā un neko tur nevar exportēt kamēr ir FK salikti un izmantoti indexi. Darbs ir skaidrs, kas jādara kopumā, bet meklēju kādu, kurš to reāli izdarīs. 1) Izveidojam sarakstu ar indexiem un FK. 2) Izveidojam sarakstu ar collonām, kurās mēs mainīsim Collation. 3) Metalm nost Indexus un FK. 4) Izmantojam otrajā solī sagatavotos vaicājumus, lai visām kollonām pamainītu Collation. 5) Atjaunojam indexus un FK. Pats zinu, kas jādara, tik MSSQL met ārā nesaprotamas kļūdas un man pietiek rediģēt A4 lapas garus scriptus, lai tas viss strādātu nav mans lauciņš. Tāpēc meklēju specu, kurš to var izdarīt / iespējams jau darījis un ir gatavi scripti šādai operācijai. Link to comment Share on other sites More sharing options...
Mezavecis Maijs 24, 2017 Share Maijs 24, 2017 1 stundu atpakaļ, kazarma teica: Jā un neko tur nevar exportēt kamēr ir FK salikti un izmantoti indexi. Par šo derētu sīkāka info. P.S. Savulaik biju MSSQL specs, bet sen neesmu neko darījis, tāpēc šādam pasākumam neparakstītos. Link to comment Share on other sites More sharing options...
kazarma Maijs 25, 2017 Author Share Maijs 25, 2017 Bump. Link to comment Share on other sites More sharing options...
Ronalds Maijs 25, 2017 Share Maijs 25, 2017 pirms 20 stundām , Mezavecis teica: Par šo derētu sīkāka info. Var eksportēt, tomēr management studio eksports taisa insert skriptu neņemot vērā FK un tabulu saites! Var sanākt tā, ka piemēram rēķinu tabula tiek importēta pirms klientu tabulas. FK vērtību nav un viss imports nobrūk protams ka! Tāpēc vajag atjaunot bāzi bez FK, salikt iekšā vērtības un tad atjaunot FK. Link to comment Share on other sites More sharing options...
Mezavecis Maijs 26, 2017 Share Maijs 26, 2017 Te ātra risinājuma nebūs. Atceros, ka kaut kas līdzīgs bija nepieciešams taisīt DB, kur vajadzēja apgreidoties. Vienkārši uzrakstīju C# kodu, kas jaunā datu bāzē veidoja koriģētu struktūru un migrēja esošos datus. Jāšanās ar SQL procedūrām ir pārāk darbietilpīgs process un pie liela tabulu skaita daudz kas var noiet greizi. It sevišķi, ja parādās kādi līki ieraksti. Link to comment Share on other sites More sharing options...
rubb Maijs 26, 2017 Share Maijs 26, 2017 1 stundu atpakaļ, Mezavecis teica: Jāšanās ar SQL procedūrām ir pārāk darbietilpīgs process un pie liela tabulu skaita daudz kas var noiet greizi. It sevišķi, ja parādās kādi līki ieraksti. Ja kas arī servera puses procedūras ir pilnvērtīgas programmēšanas valodas, tai skaitā ar kārtīgu kļūdu un tranzakciju apstrādi - būtiskā škirba, tās strādā pašā MSSQL, attiecīgi pie lieliem apjomiem tām ir lieeeeli plusi. Šis gan nav šis gadījumus, runāju par gadījumiem, gur DB ir gigabaitos. Lielākā MSSQL DB ar kuru esmu strādājis ir ~60GB. Jebkurā gadījumā, attiecīgais risinājums jātaisa valodā, kuru māki. Es taisītu servera pusē... par laimi man nekad tāda ķēpīga situācija nav bijusi Link to comment Share on other sites More sharing options...
Mezavecis Maijs 26, 2017 Share Maijs 26, 2017 @rubb Esi kādu T-SQL procedūru uzrakstījis? Esmu daudz to darījis un tieši datu migrēšana nav tas labākais veids, ja jāiet ciklā cauri n-tajām tabulām. Turklāt pieļaujot kļūdas var iegūt skriptu, kas izpildīsies bezgalīgi un optimizācija aizņems vēl 3x ilgāk laika, lai nav jāgaida nedēļu izpildei. Ja DB optimizēta, tad nav lielas starpības vai 10 vai 100 GB. Tēmas autors neko pats netaisīs, ja vien netiks ieteikts tūlis ar next next finish. Link to comment Share on other sites More sharing options...
rubb Maijs 26, 2017 Share Maijs 26, 2017 @Mezavecis pat nevari iedomājies, cik daudz, pie tam procedūras kurās ir megabaiti koda(esmu tās gan modificējis, gan veidojis). Tāpat esmu tās "tulkojis" uz Oracle. Tāpat gan uz MSSQL, gan uz Oracle tās ir tikušas treisotas, optimizētas un darīts viss tas pats, ko dara ne servera puses procēs, tas ir parastajās programmēšanas valodās. Neredzu nekādu problēmu lai servera pusei būtu mīnusi salīdzinot ar parastajām programmēšanas valodas. Ja nu vienīgi trūkst zināšanas par servera puses izstrādēm Ja kas, ir liela starpība vai DB ir 10 vai 100GB. Vari optimizēt kā gribi, bet lielāka DB *vienmēr* būs lēnāka. Jo vairākas reizes tā ir lielāka, jo lēnāka un tā paša dzelža. Labi, offtops, lai nu paliek. Link to comment Share on other sites More sharing options...
Ronalds Maijs 26, 2017 Share Maijs 26, 2017 @kazarma, nu ja neviens cits nepiesakās es varētu jaunnedēļ paskatīties. Bet nu pa lēto nebūs.... Un tā takš produkcijas bāze, kas nozīme ka darboties varēs vai nu pa brīvdienām vai pa naktīm? Link to comment Share on other sites More sharing options...
Mezavecis Maijs 26, 2017 Share Maijs 26, 2017 @rubb Izskaidro minēto jēdzienu "servera puse". Es tikai gribu pārliecināt tēmas autora, ka šāda speca ar šādām prasībām nav un nebūs. Katras DB migrācija ir individuāla. 2017.05.24. , 15:52, kazarma teica: ir gatavi scripti šādai operācijai. Link to comment Share on other sites More sharing options...
rubb Maijs 26, 2017 Share Maijs 26, 2017 Pirms 2 minūtēm , ronalds_ teica: Un tā takš produkcijas bāze Traks, šitādu lietu prod db? Es taisītu tikai uz atsevišķas testa DB, paceltu to pie sevis. Kad attiecīgais rīks būs gatavs, tad uz prod... un arī pirms tam aukstā kopija, lai ja nu kas, nav pī... Pirms 1 minūtes , Mezavecis teica: @rubb Izskaidro minēto jēdzienu "servera puse". Priekš manis tas ir MSSQL T-SQL un Oracle PL-SQL... Link to comment Share on other sites More sharing options...
Ronalds Maijs 26, 2017 Share Maijs 26, 2017 Pirms 1 minūtes , rubb teica: Traks, šitādu lietu prod db? Es taisītu tikai uz atsevišķas testa DB, paceltu to pie sevis. Kad attiecīgais rīks būs gatavs, tad uz prod... un arī pirms tam aukstā kopija, lai ja nu kas, nav pī... Bet protams! Kā gan savādāk??? Sākumā bāzes kopija ar ko spēlēties, izstrādāt skriptu, kopēšanas stratēģiju. Un tikai tad kad viss sanāk testa vidē var ķerties pie produkcijas, sākumā uztaisot rezerves kopiju! Link to comment Share on other sites More sharing options...
rubb Maijs 26, 2017 Share Maijs 26, 2017 Nu lūk... cerams, ka attiecīgais izstrādes pasūtītājs arī sapratīs, ka tas nav triviāli, ir jāveic daudzi soļi un attiecīgi arī maksās... Link to comment Share on other sites More sharing options...
Ronalds Maijs 26, 2017 Share Maijs 26, 2017 Bet nu - te jautājums par kādu softu iet runa... Ja source ir pieejama, moš vieglāk ir sql pieprasījumus izmainīt uz SELECT * FROM T1 ORDER BY C1 COLLATE Latin1_General_bin - norādīt kārtošanas secību tieši selektos. Meklējam order by un pieliekam klāt COLLATE. Man nez kāpēc domāt, ka tā būs vienkāršāk, kaut vai tāpēc ka var darīt darba dienā un bez dīkstāvēm! Link to comment Share on other sites More sharing options...
rubb Maijs 26, 2017 Share Maijs 26, 2017 @ronalds_ man ir stipras aizdomas, ka ja progzis, kurš datus raksta iekšā, nebūs Unicode, tad varētu nojukt kārtošanas, iespējams arī datu saglabāšana... labāk vienu reizi savest kārtībā... Link to comment Share on other sites More sharing options...
Ronalds Maijs 26, 2017 Share Maijs 26, 2017 Pri čom te unicode? Mēs runājam par secību, kādā SQL serveris kārtos datus, ne par to kā klients viņus atainos! Link to comment Share on other sites More sharing options...
rubb Maijs 26, 2017 Share Maijs 26, 2017 @ronalds_ tici man, arī dēļ kārtošanas kārtības ir gadījies, ka sastopu gļukus dēļ kā, ka datus nevar ielikt... labāk saved kārtībā to DB, lai pēc tam nav no nikna biedra pukstēšana, par slikti izdarītu darbu... Vismas es visu darītu līdz galam, nevis meklētu īsos workaroundus... Galu galā... ja DB maza - eksportē uz Excel, tad importē un miers... MSSQL Imports/Excel strādā ĻOTI labi... Link to comment Share on other sites More sharing options...
camel Maijs 26, 2017 Share Maijs 26, 2017 Tak te jau ir atrasts skripts kas izmaina collation, atliek pirms tam nomest index un fk un pēc tam atjaunot, gūglē priekš tā arī var atrast skriptus. Link to comment Share on other sites More sharing options...
Ronalds Maijs 26, 2017 Share Maijs 26, 2017 Jā, var! Tikai tā vai tā, tas nav triviāli! 1 Link to comment Share on other sites More sharing options...
kazarma Maijs 28, 2017 Author Share Maijs 28, 2017 (labots) Sveiki, paldies visiem. Tomēr nācās pašam ar šo tikt galā, jo nebija daudz darīt gribētāju un tiešām rezultāts nav triviāls. Kopā ir 8 dažādi scripti vidēji 1/2 A4 lapa, tai skaitā 2x procedūras, kas šo lietu, šai konkrētai DB izdara. Šodien testa vidē itkā viss izdevās, redzēs pirmdien, kad mēģinās šo visu pārnest uz produkciju. Starp citu MSSQL ir vēl viena laba fīča, tavai testa videi ir ieteicams (var teikt, ka ir jābūt) tādā pašā MS SQL server versijā kā produkcijā. Lai gan MS sola, ka jaunajiem serveriem ir backward compatibility, iekšējās procedūras, kā tiek uzglabātas struktūras un procesi atšķiras. Sākumā visu izveidoju jaunajā 2016 versijā, sapratu, ka nedarbojas, jo original DB ir uz 2008 R2 bāzes. Tad nācās testa vidi pārtaisīt uz 2008 R2 un veiksmīgi viss aizgāja. Kā tas tika realizēts: 1) Taisam triviālu skriptu, kas ignorē FK pārbaudi. 2) Taisam skriptu, kas atrod visas kollonas un sagatavo alter scriptu Objektiem / Esošajām procedūrām, Pašai DB, Tabulām, un visbeidzot Kollonām. 3) Sagatavojam procedūras, kas nometīs FK un tos atjaunos. 4) Taisam skriptu, kas atrod visus FK un izveido "Create" insertu visiem FK, kā arī uztaisa "Drop" FK komandu. 5) Taisam skriptu, kas atrod visus Indexus izveido "Create" insertu visiem Indexiem, kā arī uztaisa "Drop" Index komandu. 6) Scripts, kas salīdzina before / after FK, Indexus, Collation, tabulu izmērus. Palaižam: DB Backupu. Sagatavošanās: 1.Atslēdzam FK pārbaudi->3->4.Create->5.Create->4.Drop->5.Drop->6.Reference Izmaiņas: 4.Drop.Outputs->5.Drop.Outputs->2->4.Create.Outputs->5.Create.Outputs->1.Ieslēdzam FK pārbaudi. Testējam: 6.After Change->Skatamies vai softs vēl darbojās. Vārdu sakot nenovēlu nevienam šādu jāšanos, jo katrai DB būs individuāls piegājiens un jo lielāka DB, jo lielāki niķi. 5/26/2017 , 15:01, rubb teica: _ tici man, arī dēļ kārtošanas kārtības ir gadījies, ka sastopu gļukus dēļ kā, ka datus nevar ielikt... labāk saved kārtībā to DB, lai pēc tam nav no nikna biedra pukstēšana, par slikti izdarītu darbu... Vismas es visu darītu līdz galam, nevis meklētu īsos workaroundus... Galu galā... ja DB maza - eksportē uz Excel, tad importē un miers... MSSQL Imports/Excel strādā ĻOTI labi... Tā var, ja tev nav Procedūru/FK/Indexu. Un pat tad, tev katrai tabulai būs jānorāda, kādā veidā datus tu vēlies pānest a)full table copy b) Append utt. Kā arī Kollonas nezinu kāpēc šādā variantā mainīja datu tipu, tāpēc arī pārstāju iedziļināties šajā variantā. @ronalds_ Cik interesanti Tu vēlētos saņemt par šādu darbu? K. Labots Maijs 28, 2017 - kazarma 1 Link to comment Share on other sites More sharing options...
Ronalds Maijs 28, 2017 Share Maijs 28, 2017 Nu man prieks ka izdevās! Pirms 14 minūtēm , kazarma teica: ir ieteicams (var teikt, ka ir jābūt) tādā pašā MS SQL server versijā kā produkcijā. Bet protams! Kas gan par to šaubītos! Katrai versijai ir savas nianses un testa videi jābūt 100% tādai pašai kā produkcijas ja vēl vairāk čakara negribam! Link to comment Share on other sites More sharing options...
kazarma Maijs 28, 2017 Author Share Maijs 28, 2017 Pirms 2 minūtēm , ronalds_ teica: Nu man prieks ka izdevās! Bet protams! Kas gan par to šaubītos! Katrai versijai ir savas nianses un testa videi jābūt 100% tādai pašai kā produkcijas ja vēl vairāk čakara negribam! Es vēl ticu MS dokumentācijām un līdz šim nebija problēmu. Šis ir vairāk tāds "spec" gadījums, kur tev jāmaina viss datubāzē, kas noteikti nav "ikdienas" darbs un par to liecina maza / gandrīz neeksistējos info netā. Link to comment Share on other sites More sharing options...
Ronalds Maijs 28, 2017 Share Maijs 28, 2017 Pirms 17 minūtēm , kazarma teica: Šodien testa vidē itkā viss izdevās, redzēs pirmdien, kad mēģinās šo visu pārnest uz produkciju. Tas ir kā? Tu uz "dzīvas" bāzes šos skriptus taisies laist.... ???? Es gan tā nekad nedarītu! Pirms 1 minūtes , kazarma teica: Es vēl ticu MS dokumentācijām Es arī ticu, bet bet kā likums savietojamība ir uz standarta fīčām. Link to comment Share on other sites More sharing options...
kazarma Maijs 28, 2017 Author Share Maijs 28, 2017 (labots) Vai ir starpība? Ja DB neviens neizmanto un ir 2x backups nakts un esošais, kas ir 100% vienāds?. Var jau ķēpāties ar DB pārnešanu turpu šurpu, bet ņemot vērā, ka viss maiņas process ilgst 5 min. domāju ātrāk ir palaist uz dzīvās un viss, ja kas ir backups. Kā arī neredzu nekādus riskus. Labots Maijs 28, 2017 - kazarma Link to comment Share on other sites More sharing options...
Ronalds Maijs 28, 2017 Share Maijs 28, 2017 Just now, kazarma teica: Ja DB neviens neizmanto Nu ja neviens neizmanto, tad skaidrs ka var! Pārvedam datu bāzi single user modē, palaižam skriptus, pārbaudām ka viss ok, pārvedam atpakaļ multi user modē. Izskatījās ka mēģināsi laist skriptus uz DB, kas tiek lietota! Link to comment Share on other sites More sharing options...
kazarma Maijs 28, 2017 Author Share Maijs 28, 2017 (labots) Skaidrs, nav mans pirmais barbequ IT, lai tādus punktus vispār pieminētu, man šķiet tie ir pašsaprotami. Single / Multi user arī nelieku, jo ir serviss, pie kura useri slēdzas un parasti šis serviss pēc šādas operācijas ir jāpārstartē tā pat, tāpēc vienkārši nostepēju servisu Lai nu kā, paldies par mēģinājumiem palīdzēt. Labots Maijs 28, 2017 - kazarma Link to comment Share on other sites More sharing options...
Ronalds Maijs 28, 2017 Share Maijs 28, 2017 Pirms 4 minūtēm , kazarma teica: nav mans pirmais barbequ IT, lai tādus punktus vispār pieminētu, man šķiet tie ir pašsaprotami. Nē nu visādi brīnumi ir sastapti! Ja vari 100% garantēt, ka pie tās bāzes neviens izmaiņu laikā neslēgsies klāt, tad protams ka var uz single user modi neslēgties. Vienkārši single user mode garantē ka neviens cits nepieslēgsies. Pirms 4 minūtēm , kazarma teica: Lai nu kā, paldies par mēģinājumiem palīdzēt. Ņem par labu! Link to comment Share on other sites More sharing options...
Mezavecis Maijs 28, 2017 Share Maijs 28, 2017 pirms 5 stundām , kazarma teica: Sagatavojam procedūras, kas nometīs FK un tos atjaunos. Uz testa bāzes obligāti pārbaudi produktivitāti, jo viena kļūda nozīmēs to, ka būs mega bremze, inserti nogāzīsies utml. Link to comment Share on other sites More sharing options...
kazarma Maijs 29, 2017 Author Share Maijs 29, 2017 Update: visas izmaiņas veiktas produkcijas DB un patreiz sistēma darbojas nevainojami. K. Link to comment Share on other sites More sharing options...
Recommended Posts
Izveido kontu, vai pieraksties esošajā, lai komentētu
Jums ir jābūt šī foruma biedram, lai varētu komentēt tēmas
Izveidot jaunu kontu
Piereģistrējies un izveido jaunu kontu, tas būs viegli!
Reģistrēt jaunu kontuPierakstīties
Jums jau ir konts? Pierakstieties tajā šeit!
Pierakstīties tagad!