Први и други у деловима ове серије говорило се о разликама између Орацле Датабасе и Мицрософт СКЛ Сервер у њиховој имплементацији трансакција, као и замкама претворбе као резултат, као и о неким често коришћеним елементима синтаксе.

Ова последња рата покриваће појам Орацле прочитајте доследност и како претворити архитектуру, засновану на овом појму, у Мицрософт СКЛ Сервер верзија. Такође ће се позабавити употребом синонима (и како их НЕ користити) и улогом процеса контроле промена у управљању вашим окружењем базе података.

Орацле консистентност читања и њен еквивалент у СКЛ серверу

Орацле константност читања је гаранција да сви подаци враћени једним СКЛ изразом потичу из исте појединачне тачке времена.

То значи да ако сте издали SELECT изјава у 12: 01: 02.345 и извршавала се 5 минута пре враћања скупа резултата, сви подаци (и само подаци) који су урезани у базу података од 12: 01: 02.345 ући ће у ваш скуп за повратак. Ваш скуп за враћање неће додати нове податке током тих 5 минута колико је било потребно бази података да обради вашу изјаву, нити било каква ажурирања и неће бити видљива брисања.

Орацле архитектура постиже доследност читања интерним временским обележавањем сваке промене података и стварањем скупа резултата из два извора: трајних датотека података и сегмента за опозив (или „сегмента враћања“) као што је било познато до верзије 10г ).

Да бисте је подржали, поништите информације треба сачувати . Ако се препише, резултира неславним ORA-01555: snapshot too old грешка.

Ако оставимо по страни управљање опозивом сегмента - и како се кретати кроз ORA-01555: snapshot too old грешка - погледајмо импликације конзистентности читања на било коју практичну примену у Орацле-у. Такође, како би се то требало пресликати у СКЛ Сервер, који - као што је случај са осталим имплементацијама РДБМС-а, уз могући и квалификовани изузетак ПостгреСКЛ-а, не подржава?

Кључ је у томе што Орацле чита и пише не блокирају једни друге. То такође значи да ваш дуготрајни скуп повратних упита можда нема најновије податке.

Неблокирање читања и писања предност је коју Орацле има и то утиче на опсег трансакција .

Али доследност читања такође значи да немате најновије стање података. Када је у неким сценаријима савршено добро (попут израде извештаја за одређено време), то може створити значајне проблеме у другима.

Непостојање најновијих - чак и „прљавих“ или необавезених података могло би бити критично: класични сценарио је систем резервације хотелске собе.

Размотрите следећи случај употребе: Имате два агента корисничке службе који истовремено прихватају налоге за резервацију соба. Како можете осигурати да собе не постану пребукиране?

У СКЛ серверу можете започети експлицитну трансакцију и SELECT запис са листе (која може бити табела или приказ) расположивих соба. Све док ову трансакцију не затвори (или COMMIT или ROLLBACK), нико не може добити исти запис собе који сте изабрали. Ово спречава двоструку резервацију, али такође чини да сви други агенти чекају једни на друге да узастопно испуњавају захтеве за резервацију.

У Орацле-у можете постићи исти резултат издавањем SELECT ... FOR UPDATE изјава против записа који одговарају вашим критеријумима претраге.

Напомена: Постоје боља решења, попут постављања привремене заставе која означава собу која се „разматра“ уместо слепог закључавања приступа. Али то су архитектонска решења, а не језичке опције.

Закључак : Конзистентност Орацле читања није „сва добра“ или „сва лоша“, већ важно својство платформе које треба добро разумети и пресудно је за миграцију кода са више платформи.

Јавни (и приватни) синоними у Орацле и Мицрософт СКЛ Сервер

„Јавни синоними су зли.“ Његово није баш моје лично откриће , али прихватио сам га као јеванђеље све док мој дан, недеља и година нису били спашени јавним синонимима.

учење кодирања у в

У многим окружењима база података - рекао бих у свим Орацле окружењима са којима сам имао прилику да радим, али ниједном које сам дизајнирао - користећи CREATE PUBLIC SYNONYM за сваки предмет је била рутина, јер „то смо увек радили“.

У овим окружењима јавни синоними имали су само једну функцију: да дозволе упућивање на објекат без навођења његовог власника. А ово је једно лоше смишљен разлог да чине јавне синониме.

Међутим, Орацле јавни синоними могу бити изузетно корисни и пружити предности продуктивности тима које знатно надмашују све њихове недостатке ако се правилно примењују и управљају њима са разлогом. Да, рекао сам „продуктивност тима“. Али како? За ово морамо да разумемо како решавање имена функционише у Орацле-у.

Када Орацле парсер пронађе име (нерезервисану кључну реч), покушава да га упари са постојећим објектом базе података следећим редоследом:

Напомена: Подигнута грешка ће бити ORA-00942: table or view does not exist за ДМЛ изјаве или PLS-00201: identifier 'my_object' must be declared за ускладиштене процедуре или позиве функција.

У овом редоследу решавања имена лако је видети да када програмер ради у сопственој шеми, сваки локални објекат са истим именом као јавни синоним ће сакрити овај јавни синоним. (Напомена: Орацле 18ц је применио тип шеме „само за пријаву“ и ова дискусија се на њу не односи.)

Јавни синоними за скалирање тимова: Орацле Цханге Цонтрол

Погледајмо сада хипотетички тим од 100 програмера који раде на истој бази података (што је нешто што сам искусио). Даље, претпоставимо да сви раде локално на својим личним радним станицама и самостално раде верзије без базе података, све повезане са истим развојним окружењем базе података. Решавање спајања кода у коду који није из базе података (било да је то Ц #, Јава, Ц ++, Питхон или било шта друго) извршиће се у време пријаве за контролу промена и ступиће на снагу са следећом изградњом кода. Али табеле базе података, код и подаци морају се мењати напред и назад више пута током текућег развоја. Сваки програмер то ради независно и ступа на снагу одмах.

Због тога се сви објекти базе података креирају у заједничкој шеми апликације. Ово је тхе шема на коју се апликација позива. Сваки програмер:

• Повезује се са базом података помоћу њиховог личног корисничког налога / шеме
• Увек почиње са празном личном шемом
• Упућује на уобичајену шему само путем разрешавања имена на јавни синоним, као што је горе описано

Када програмер треба да направи било који промене у бази података - креирају или мењају табелу, мењају код процедуре или чак модификују скуп података како би подржале неки тестни сценарио - креирају копију објекта у својој личној шеми. То раде тако што добијају ДДЛ код користећи DESCRIBE команду и покретање локално.

Од овог тренутка, код овог програмера видеће локалну верзију објекта и податке, који неће бити видљиви (нити ће имати утицаја на) било кога другог. Након завршетка развоја, модификовани код базе података се проверава у контроли извора и решавају се сукоби. Затим се коначни код (и подаци, ако су потребни) имплементирају у заједничку шему.

После овога, цео развојни тим може поново видети исту базу података. Програмер који је управо доставио код испушта све објекте из своје личне шеме и спреман је за нови задатак.

Ова способност омогућавања независног паралелног рада за више програмера главна је предност јавних синонима - значај који је тешко пренаглашити. Међутим, у пракси и даље виђам тимове који стварају јавне синониме у Орацле имплементацијама „само зато што то увек радимо“. Супротно томе, у тимовима који користе СКЛ Сервер, стварање јавних синонима не видим као уобичајену праксу. Функционалност постоји, али се не користи често.

У СКЛ Серверу, тренутна подразумевана шема за корисника дефинисана је у корисничкој конфигурацији и може се променити било када ако имате привилегије „променити корисника“. Може се применити иста тачна методологија као што је горе описана за Орацле. Међутим, ако се овај метод не користи, јавни синоними се не смеју копирати.

Како Мицрософт СКЛ Сервер подразумевано не повезује нови кориснички налог са сопственом шемом (као што то чини Орацле), повезивање би требало да буде део ваше стандардне скрипте „креирај корисника“.

Испод је пример скрипте која креира наменске корисничке шеме и додељује их једном кориснику.

Прво створите шеме за нове кориснике које треба уградити у базу података која се зове DevelopmentDatabase (свака шема мора бити креирана у својој групи):

use DevelopmentDatabase; GO CREATE SCHEMA Dev1; GO CREATE SCHEMA Dev2; GO

Друго, креирајте првог корисника са додељеном подразумеваном шемом:

CREATE LOGIN DevLogin123 WITH PASSWORD = 'first_pass123'; CREATE USER Dev1 FOR LOGIN DevLogin123 WITH DEFAULT_SCHEMA = Dev1; GO

У овом тренутку, подразумевана шема за корисника Dev1 би било Dev1.

Даље, креирајте другог корисника без подразумеване шеме:

CREATE LOGIN DevLogin321 WITH PASSWORD = 'second_pass321'; CREATE USER Dev2 FOR LOGIN DevLogin321; GO

Подразумевана шема за корисника Dev2 је dbo.

Сада промените корисника Dev2 да промени своју подразумевану шему у Dev2:

ALTER USER Dev2 WITH DEFAULT_SCHEMA = Dev2; GO

Сада подразумевана шема за корисника Dev2 је Dev2.

Ова скрипта приказује два начина за додељивање и промену подразумеване шеме за корисника у базама података Мицрософт СКЛ Сервер. Како СКЛ Сервер подржава више метода аутентификације корисника (најчешћа је Виндовс аутентификација), а укрцавањем корисника могу управљати системски администратори, а не ДБА, ALTER USER метод додељивања / промене подразумеване шеме биће употребљивији.

Напомена: Направио сам име шеме исто као и име корисника. У СКЛ Серверу то не мора бити тако, али моја је преференција јер се (1) подудара са начином на који се то ради у Орацлеу и (2) поједностављује управљање корисницима (обраћајући се највећем приговору ДБА да то ради исправно на првом месту) - знате име корисника и аутоматски знате подразумевану шему корисника.

Закључак : Јавни синоними су важно средство за изградњу стабилног и добро заштићеног вишекорисничког развојног окружења. Нажалост, према мојим запажањима у индустрији, чешће се користи из погрешних разлога - остављајући тимове да трпе збрку и друге недостатке јавних синонима, а да не схватају њихове користи. Промена ове праксе ради добијања стварних користи од јавних синонима може донети стварне користи процесу рада тима.

Управљање приступом базама података и процеси управљања променама

Како смо управо разговарали о подршци паралелном развоју великих тимова, вреди се позабавити једном одвојеном и често погрешно схваћеном темом: процеси контроле промена.

Управљање променама често постаје облик бирокрације коју контролишу вође тимова и ДБА, а коју презиру побуњени програмери који желе да испоруче све ако не „јуче“, а затим „сада“.

Као ДБА, увек стављам заштитне препреке на пут у своју базу података. И за то имам врло добар разлог: База података је заједнички ресурс.

Твеет

У контексту контроле извора, управљање променама је опште прихваћено, јер омогућава тиму да се врати са новог, али неисправног кода на стари, али који ради. Али у контексту базе података, управљање променама може изгледати као скуп неразумних препрека и ограничења које постављају ДБА: Чисто лудило је оно што беспотребно успорава развој!

Оставимо похвале овог програмера по страни: ја сам ДБА и нећу бацити камење на себе! Као ДБА, увек стављам заштитне препреке на пут у „своју“ базу података. И за то имам врло добар разлог: База података је заједнички ресурс.

Сваки развојни тим - и сваки његов програмер - има врло специфично дефинисан циљ и врло специфичан резултат. Једини циљ који је свакодневно на радном столу ДБА је стабилност базе података као дељеног ресурса. ДБА има јединствену улогу у организацији да надгледа све развојне напоре свих тимова и да контролише базу података којој сви програмери приступају. ДБА је тај који осигурава да се сви пројекти и сви процеси изводе без међусобног ометања и да сваки има ресурсе потребне за функционисање.

Проблем је када и развојни и ДБА тим седе закључани у својим кулама од слоноваче.

Програмери не знају, немају приступ и чак их није брига шта се дешава са базом података све док им она функционира сасвим у реду. (То није њихов резултат, нити ће утицати на њихову процену учинка.)

ДБА тим држи базу података близу сандука, штитећи је од програмера који о њој „не знају ништа“, јер је циљ њиховог тима стабилност базе података. А најбољи начин да се осигура стабилност је спречавање деструктивних промена - што често резултира ставом да се база података штити од било каквих промена што је више могуће.

Ове сукобљени ставови према бази података може, као што сам видео, довести до непријатељства између развојних и ДБА тимова и довести до неизведивог окружења. Али ДБА и развојни тим морају заједно радити на постизању заједничког циља: пружити пословно решење, које их је пре свега и окупило.

Био сам на обе стране поделе програмера и ДБА, знам да је проблем лако решити када ДБА боље разумеју заједничке задатке и циљеве развојних тимова. Са њихове стране, програмери морају да виде базу података не као апстрактни концепт, већ као заједнички ресурс - и ту би ДБА требало да преузме улогу едукатора.

Најчешћа грешка коју ДБА-ови који нису програмери је ограничавање приступа програмера речнику података и алатима за оптимизацију кода. Приступ Орацле-у DBA_ прикази каталога, динамички V$ приказа и SYS Табеле се многим ДБА чине „привилегованим ДБА“, када су у ствари то критични развојни алати.

Исто важи и за СКЛ Сервер, са једном компликацијом: Приступ неким системским приказима не може се доделити директно, али то је само део SYSADMIN улога базе података, а ова улога се никада не сме доделити изван ДБА тима. Ово се може решити (и требало би да се реши у случају миграције пројекта са Орацле-а на СКЛ Сервер) стварањем погледа и ускладиштених процедура које се извршавају под SYSADMIN привилегије, али им могу приступити корисници који нису ДБА. Ово је развој ДБА-а посао који треба обавити како је конфигурисано ново развојно окружење за СКЛ Сервер.

Заштита података је једна од главних одговорности ДБА. Упркос томе, прилично је уобичајено да развојни тимови имају пуни приступ нефилтрираним производним подацима како би омогућили решавање проблема са подацима у вези са подацима. То су исти програмери који имају ограничен приступ структури података - структури коју су сами креирали или за њих уопште.

Поверпивот екцел 2013 туториал пдф

Када се успоставе правилни радни односи између развојних и ДБА тимова, стварање доброг процеса контроле промена постаје интуитивно. Специфичности и изазови управљања променама на страни базе података су истовремено ригидност и флуидност базе података - структура је крута, подаци су флуидни.

Често се дешава да је управљање променама на модификацији структуре - тј. На језику за дефинисање података или ДДЛ - добро успостављено, док промене података имају мало или нимало на путу управљања променама. Оправдање је једноставно - подаци се стално мењају.

Али ако ово боље погледамо, видећемо да у било ком систему сви подаци спадају у једну од две категорије: подаци о апликацијама и подаци о корисницима.

Информације о алпикацији је речник података који дефинише понашање апликације и критичан је за њене процесе као и било који код апликације. Промене ових података треба да буду под строгим процесом контроле промена, баш као и код било које друге промене апликације. Да би се створила транспарентност у процесу контроле промена за промене података апликације, подаци апликације и подаци корисника морају бити изричито одвојени.

У Орацле-у би то требало учинити стављањем апликација и корисничких података сваки у своју шему. У Мицрософт СКЛ Сервер-у то би требало учинити стављањем сваке у засебну шему или - много боље - у засебну базу података. Доношење ових избора требало би да буде део планирања миграције: Орацле има резолуцију имена на два нивоа (шема / власник - име објекта), док СКЛ Сервер има резолуцију имена на три нивоа (база података - шема / власник - име објекта).

Уобичајени извор забуне између света Орацле и СКЛ Сервер су - можда изненађујуће - појмови база података и сервер :

Појам СКЛ Сервер	Орацле Терм	Дефиниција
сервер	база података (користи се наизменично са сервер уобичајеним језиком, осим ако се посебно не односи на хардвер сервера, ОС или мрежне елементе; на физичком / виртуелном серверу може бити једна или више база података)	Покренута инстанца која може да „разговара“ са другим инстанцама путем мрежних портова
база података (део сервера, садржи више шема / власника)	шема / власник	Груписање на највишем нивоу

Ову комбинацију терминологије треба јасно разумети у пројектима миграције на више платформи, јер погрешно тумачење појма може резултирати нетачним одлукама о конфигурацији којима је тешко адресирати ретроактивно.

Исправно раздвајање апликација и корисничких података омогућава ДБА тиму да се позабави својом другом најважнијом бригом: безбедношћу корисничких података. Како се кориснички подаци налазе одвојено, биће врло једноставно применити а поступак ломљења стакла за приступ корисничким подацима по потреби.

Закључак : Процеси контроле промена су пресудни у било ком пројекту. У софтверском инжењерству, управљање променама на страни базе података често се занемарује, јер се сматра да су подаци „превише флуидни“. Али управо зато што су подаци истовремено „флуидни“ и „трајни“, добро осмишљен поступак контроле промена треба да буде камен темељац правилне архитектуре окружења базе података.

О употреби алата за миграцију кода

Стандардни први алати, Орацле Мигратион Воркбенцх и СКЛ Сервер помоћник за миграцију , може бити корисно при миграцији кода. Али оно о чему треба водити рачуна је правило 80/20 : Када се код 80% исправно мигрира, решавање преосталих 20% одузеће 80% вашег напора за миграцију.

Највећи ризик у коришћењу алата за миграцију је далеко перцепција „сребрног метка“. Неко може доћи у искушење да помисли: „То ће обавити посао, а ја ћу само морати мало да га очистим и поспремим.“ Приметио сам пројекат који је пропао због таквог става тима за конверзију и његовог техничког вођства.

С друге стране, требало ми је четири радна дана да извршим основну конверзију система средње величине Мицрософт СКЛ Сервер 2008 (око 200 објеката) користећи функцију за масовну замену Нотепад ++-а као главни алат за уређивање.

Алатке за миграцију не могу решити ниједан од критичних елемената миграције којима сам се до сада позабавио.

Свакако, користите алате за помоћ у миграцији, али имајте на уму да они пружају само помоћ у уређивању. Резултирајући излазни текст мора да има преглед, модификацију и - у неким случајевима - преписивање да би постао производ вредан кода.

Развој алата за вештачку интелигенцију могао би да реши недостатке алата за миграцију у будућности, али очекивао бих да ће се разлике између база података пре тога замаглити и да ће сваки сам процес миграције постати непотребан. Дакле, све док су потребне ове врсте пројеката, мораћемо то да радимо на стари начин, користећи старомодну људску интелигенцију.

Закључак : Коришћење алата за помоћ у миграцији је корисно, али то није „сребрни метак“, а било који пројекат конверзије и даље захтева детаљан преглед горе наведених тачака.

Миграције Орацле / СКЛ Сервер: Увек пажљивије погледајте

Орацле и Мицрософт СКЛ Сервер су две најраширеније РДБМС платформе у пословном окружењу. Оба имају основну усклађеност са АНСИ СКЛ стандардом, а мали сегменти кода се могу премештати са врло мало модификација или чак такви какви јесу.

Ова сличност ствара варљив утисак да је миграција између две платформе једноставан, непосредан задатак и да се иста апликација може лако усвојити из употребе једног РДБМС-а на други.

У пракси такве миграције платформе нису далеко од тривијалних и морају узети у обзир фине елементе унутрашњег рада сваке платформе и, пре свега, начин на који примењују подршку за најкритичнији елемент управљања подацима: трансакције.

Иако сам покривао две РДБМС платформе које су срж моје стручности, исто упозорење - „изгледа слично не значи да и подједнако функционише“ - требало би да се примени на премештање кода између било ког другог система за управљање базама података који је у складу са СКЛ-ом. И у свим случајевима, прва тачка пажње треба да буде на томе како се примена управљања трансакцијама разликује између изворне и циљне платформе.

Разумевање основа

Шта је доследност података у програму Орацле?

У Орацлеу се доследност података заснива на више верзија: Свака верзија података која се односи на једну временску тачку треба да буде у таквом стању да нема кршења активних ограничења базе података.

Шта је доследност читања у Орацле-у?

Конзистентност Орацле читања је гаранција на нивоу СКЛ изјаве да ће сви подаци бити враћени у доследном стању - као што је било у тренутку када је изјава предата на извршење. Да би то подржао, Орацле управља више верзија података које одговарају више временских тачака.

Шта је провера усклађености базе података?

Провера доследности базе података је поступак за потврду да је база података у доследном стању и да нема недостајућих или оштећених блокова података. Требало би га изводити на сигурносним копијама и на базама података чија се функционалност обнавља након квара хардвера.

Шта је доследност података у СКЛ-у?

У базама података компатибилним са СКЛ-ом, доследност података односи се на стање података где не крши ниједно активно ограничење базе података. Ово је основни захтев који мора бити задовољен на крају сваке трансакције.

Шта су приватни и јавни синоними у Орацлеу?

Орацле приватни синоними су створени у одређеној шеми и може им се приступити путем референци шеме на исти начин као и било који други објекат шеме. С друге стране, јавни синоними се креирају у групи ПУБЛИЦ и може им се приступити без икаквих референци на шему.

Како мењате синониме у Орацле-у?

У програму Орацле, да бисте променили на који се објект односи синоним, синоним треба испустити и поново створити.

Шта је Орацле инстанца?

Орацле инстанца је цела колекција позадинског процеса и додељене меморије која чини Орацле базу података као апликацију која складишти и манипулише подацима.