Първият и секундата части от тази поредица обсъдиха разликите между Oracle Database и Microsoft SQL Server в тяхното изпълнение на транзакции и произтичащите от това клопки за преобразуване, както и някои често използвани елементи на синтаксиса.

Тази последна вноска ще обхване понятието Oracle чете последователност и как да конвертирате архитектурата, базирана на това понятие, в Microsoft SQL Server версия. Той също така ще разгледа използването на синоними (и как да НЕ ги използва) и ролята на процеса на контрол на промените при управлението на вашата среда на база данни.

в какво са написани операционните системи

Последователност на четене на Oracle и нейният еквивалент в SQL Server

Oracle чете последователност е гаранция, че всички данни, върнати от един SQL оператор, идват от един и същ момент във времето.

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

Архитектурата на Oracle постига съгласуваност при четене чрез вътрешно поставяне на щампи във всяка промяна в данните и изграждане на набор от резултати от два източника: постоянни файлове с данни и отменен сегмент (или „сегмент за връщане назад“) както беше известно до версия 10g ).

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

Оставяйки настрана отмяната на управлението на сегменти - и как да навигирате в ORA-01555: snapshot too old грешка - нека разгледаме последиците от последователността на четенето върху всяко практическо изпълнение в Oracle. Също така, как трябва да се отразява в SQL Server, който - какъвто е случаят с други внедрения на RDBMS, с възможното и квалифицирано изключение на PostgreSQL - не го поддържа?

Ключът е, че Oracle чете и пише, не се блокират взаимно. Това също означава, че вашият дългосрочен набор за връщане на заявка може да няма най-новите данни.

Неблокирането на четене и запис е предимство, което Oracle има и то засяга обхвата на транзакциите .

Но последователността на четене също означава, че нямате последното състояние на данните. Когато в някои сценарии това е напълно добро (като изготвяне на отчет за определено време), това може да създаде значителни проблеми в други.

Липсата на най-новите - дори „мръсни“ или необвързани данни може да бъде критична: Класическият сценарий е система за резервация в хотелска стая.

Помислете за следния случай на използване: Имате двама агенти за обслужване на клиенти, които едновременно приемат поръчки за резервация на стая. Как можете да гарантирате, че стаите няма да бъдат прекалено резервирани?

В SQL Server можете да стартирате явна транзакция и SELECT запис от списъка (който може да бъде маса или изглед) на наличните стаи. Докато тази транзакция не е затворена (или от COMMIT или ROLLBACK), никой не може да получи същия запис на стая, който сте избрали. Това предотвратява двойното резервиране, но също така кара всеки друг агент да чака взаимно, за да изпълнява последователно заявките за резервация.

В Oracle можете да постигнете същия резултат, като издавате SELECT ... FOR UPDATE изявление срещу записи, отговарящи на критериите ви за търсене.

Забележка: Съществуват по-добри решения, като например поставяне на временен флаг, маркиращ стая, която се разглежда, вместо сляпо заключване на достъпа до нея. Но това са архитектурни решения, а не езикови възможности.

Заключение : Съвместимостта на Oracle за четене не е „всички добри“ или „всички лоши“, а важно свойство на платформата, което трябва да се разбере добре и е критично важно за миграцията на кодове между платформи.

Публични (и частни) синоними в Oracle и Microsoft SQL Server

„Публичните синоними са зло.“ Това е не точно моето лично откритие , но го бях приел като евангелие, докато денят, седмицата и годината ми бяха спасени от публични синоними.

В много среди на бази данни - бих казал, че всички среди на Oracle, с които съм имал възможност да работя, но нито една, която съм проектирал - използвайки CREATE PUBLIC SYNONYM за всеки обект беше рутина, защото „винаги сме го правили по този начин.“

В тези среди публичните синоними имаха само една функция: да позволяват препратка към обект, без да се посочва собственика му. И това е едно зле обмислена причина да правят публични синоними.

Публичните синоними на Oracle обаче могат да бъдат изключително полезни и да осигурят ползи за производителността на екипа, които значително надвишават всичките им недостатъци, ако се прилагат и управляват правилно и с основание. Да, казах „производителност на екипа“. Но как? За това трябва да разберем как работи разделителната способност на имената в Oracle.

Когато анализаторът на Oracle намира име (нерезервирана ключова дума), той се опитва да го съпостави със съществуващ обект на база данни в следния ред:

Забележка: Повишената грешка ще бъде ORA-00942: table or view does not exist за DML изрази или PLS-00201: identifier 'my_object' must be declared за съхранени процедури или извиквания на функции.

В този ред за разрешаване на имена е лесно да се види, че когато разработчик работи в собствена схема, всеки локален обект със същото име като публичен синоним ще Крия този публичен синоним. (Забележка: Oracle 18c е внедрил типа на схемата „само за вход“ и тази дискусия не се отнася за нея.)

Публични синоними на Scaling Teams: Oracle Control Control

Нека сега разгледаме хипотетичен екип от 100 разработчици, работещи върху една и съща база данни (което е нещо, което съм изпитвал). Освен това, нека приемем, че всички те работят локално на личните си работни станции и правят незавършени компилации на бази данни, всички свързани с една и съща среда за разработка на база данни. Разрешаването на сливането на код в код извън база данни (било то C #, Java, C ++, Python или каквото и да е друго) ще бъде направено по време на регистрация за контрол на промените и ще влезе в сила със следващото изграждане на код. Но таблиците на базата данни, кодът и данните трябва да се променят многократно напред и назад по време на текущото развитие. Всеки разработчик прави това независимо и то влиза в сила незабавно.

За това всички обекти на база данни се създават в обща схема на приложение. Това е на схема, която приложението препраща. Всеки разработчик:

• Свързва се с базата данни с техния личен потребителски акаунт / схема
• Винаги започва с празна лична схема
• Препраща към общата схема само чрез разрешаване на имена към публичен синоним, както е описано по-горе

Когато разработчикът трябва да направи всякакви промени в базата данни - създават или променят таблица, променят кода на процедурата или дори модифицират набор от данни, за да поддържат някакъв тестов сценарий - те създават копие на обекта в личната си схема. Те правят това, като получават DDL код с помощта на DESCRIBE командване и стартиране локално.

От този момент този код на разработчика ще вижда локалната версия на обекта и данните, които няма да бъдат видими (нито да имат влияние върху) никой друг. След като разработката завърши, модифицираният код на базата данни се проверява в контрола на източника и конфликтите се разрешават. След това окончателният код (и данните, ако е необходимо) е внедрен в общата схема.

След това целият екип за разработка може отново да види същата база данни. Разработчикът, който току-що е доставил кода, изпуска всички обекти от личната си схема и е готов за ново задание.

Тази способност за улесняване на независима паралелна работа за множество разработчици е основната полза от публичните синоними - значение, което е трудно да се надцени. На практика обаче продължавам да виждам екипи, които създават публични синоними в реализациите на Oracle, „само защото винаги го правим“. За разлика от това, в екипи, използващи SQL Server, не виждам създаването на публични синоними, установени като обичайна практика. Функционалността съществува, но не се използва често.

В SQL Server текущата схема по подразбиране за потребител е дефинирана в потребителската конфигурация и може да бъде променена по всяко време, ако имате привилегии за „промяна на потребителя“. Може да се приложи същата точна методология, описана по-горе за Oracle. Ако обаче този метод не се използва, публичните синоними не трябва да се копират.

Тъй като Microsoft SQL Server не асоциира нов потребителски акаунт със собствена схема по подразбиране (както прави Oracle), асоциирането трябва да е част от стандартния ви скрипт „създаване на потребител“.

По-долу е даден пример за скрипт, който създава специални потребителски схеми и ги присвоява на потребител.

Първо, създайте схеми за нови потребители, които трябва да бъдат включени в базата данни с име 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.

Този скрипт демонстрира два начина за присвояване и промяна на схема по подразбиране за потребител в бази данни на Microsoft SQL Server. Тъй като SQL Server поддържа множество методи за удостоверяване на потребителя (най-често срещаният е удостоверяването на Windows) и включването на потребителите може да се обработва от системни администратори, а не от DBA, ALTER USER методът за присвояване / промяна на схемата по подразбиране ще бъде по-използваем.

Забележка: Направих името на схемата същото като името на потребител. Не е задължително да е по този начин в SQL Server, но това е моето предпочитание, защото (1) съвпада с начина, по който се прави в Oracle и (2) опростява управлението на потребителите (адресирайки най-голямото възражение от страна на DBA да го прави правилно на първо място) - знаете името на потребител и автоматично знаете схемата по подразбиране на потребителя.

Заключение : Публичните синоними са важен инструмент за изграждане на стабилна и добре защитена среда за разработка на много потребители. За съжаление, по мое наблюдение в бранша, той по-често се използва по грешни причини - оставяйки екипите да страдат от объркването и други недостатъци на публичните синоними, без да осъзнават ползите от тях. Промяната на тази практика, за да се получат реални ползи от публичните синоними, може да донесе реални ползи за работния процес на екипа.

Управление на достъпа до база данни и процеси за управление на промените

Тъй като току-що говорихме за подкрепа за паралелно развитие от големи екипи, струва си да се обърнем към една отделна и често неразбрана тема: процеси за контрол на промените.

Управлението на промените често се превръща в форма на бюрокрация, контролирана от ръководителите на екипи и администраторите на базите данни, презирани от бунтовни разработчици, които искат да предоставят всичко, ако не „вчера“, то „сега“.

Като DBA винаги поставям защитни бариери по пътя към „моята“ база данни. И имам много добра причина за това: Базата данни е споделен ресурс.

Tweet

В контекста на контрола на източника управлението на промените е общоприето, тъй като позволява на екипа да се върне от нов, но неработещ код към стар, но работещ код. Но в контекста на базата данни управлението на промените може да изглежда като набор от неразумни бариери и ограничения, поставени от DBA: Това е чисто безумие, което ненужно забавя развитието!

Нека оставим настрана изказването на този разработчик: Аз съм специалист по базова информация и няма да си хвърлям камъни! Като DBA винаги поставям защитни бариери по пътя към „моята“ база данни. И имам много добра причина за това: Базата данни е споделен ресурс.

Всеки екип за разработка - и всеки от техните разработчици - има много конкретно определена цел и много специфичен резултат. Единствената цел, която всеки ден е на бюрото на DBA, е стабилността на базата данни като споделен ресурс. DBA има уникалната роля в организацията да наблюдава всички усилия за развитие във всички екипи и да контролира база данни, до която всички разработчици имат достъп. DBA е тази, която гарантира, че всички проекти и всички процеси се изпълняват, без да си пречат един на друг и че всеки има необходимите ресурси, за да функционира.

Проблемът е, когато екипите за разработка и DBA седят заключени в съответните си кули от слонова кост.

Разработчиците не знаят, нямат достъп и дори не се интересуват какво се случва в базата данни, стига да работи добре за тях. (Това не е резултат, нито ще повлияе на оценката на тяхното представяне.)

Екипът на DBA държи базата данни близо до сандъка, като я предпазва от разработчици, които „не знаят нищо“ за нея, тъй като целта на екипа им е стабилността на базата данни. И най-добрият начин да се осигури стабилност е да се предотвратят деструктивни промени - често водещи до нагласа за защита на базата данни от всякакви промени, доколкото е възможно.

Тези противоречиво отношение към базата данни както видях, може да доведе до враждебност между екипите за разработка и DBA и да доведе до неработеща среда. Но администраторите на базите данни и екипът за разработка трябва да работят заедно, за да постигнат обща цел: да предоставят бизнес решение, което първо ги е събрало.

След като бях от двете страни на разделението между разработчици и DBA, знам, че проблемът е лесен за решаване, когато DBA разбират по-добре общите задачи и цели на екипите за разработка. От тяхна страна разработчиците трябва да възприемат базата данни не като абстрактна концепция, а като споделен ресурс - и там DBA трябва да поеме ролята на преподавател.

Най-честата грешка, която DBA на разработчиците правят, е ограничаването на достъпа на разработчика до речника на данните и до инструментите за оптимизация на кода. Достъп до Oracle DBA_ изгледи на каталога, динамични V$ изгледи и SYS таблици изглежда на много DBA като „привилегировани на DBA“, когато всъщност това са критични инструменти за разработка.

Същото важи и за SQL Server, с едно усложнение: Достъпът до някои системни изгледи не може да бъде предоставен директно, но това е само част от SYSADMIN роля на база данни и тази роля никога не трябва да се предоставя извън екипа на DBA. Това може да бъде решено (и трябва да бъде решено в случай на миграция на проект от Oracle към SQL Server) чрез създаване на изгледи и съхранени процедури, които се изпълняват под SYSADMIN привилегии, но са достъпни за потребители извън DBA. Това е DBA за разработка работа, която трябва да направите, тъй като е конфигурирана нова среда за разработка на SQL Server.

Защитата на данните е една от основните отговорности на DBA. Въпреки това е доста често екипите за разработчици да имат пълен достъп до нефилтрирани производствени данни, за да позволят отстраняване на неизправности, свързани с данните. Това са същите разработчици, които имат ограничен достъп до структурата на данните - структурата, която е създадена от тях или на първо място за тях.

какво означава cms в уеб дизайна

Когато се установят правилни работни взаимоотношения между екипите за разработка и DBA, създаването на добър процес за контрол на промените става интуитивно. Спецификите и предизвикателствата на управлението на промените от страна на базата данни са твърдостта и плавността на базата данни едновременно - структурата е твърда, данните са плавни.

Често се случва управлението на промените при модифициране на структурата - т.е. на езика за дефиниране на данни или DDL - да е добре установено, докато промените в данните нямат почти нищо по отношение на управлението на промените. Обосновката е проста - данните се променят непрекъснато.

Но ако разгледаме това по-отблизо, ще видим, че във всяка система всички данни попадат в една от двете категории: данни за приложения и потребителски данни.

Данни за приложението е речник на данни, който определя поведението на дадено приложение и е толкова важен за неговите процеси, колкото всеки код на приложението. Промените в тези данни трябва да бъдат под строги процеси за контрол на промените, точно както при всяка друга промяна на приложението. За да се създаде прозрачност в процеса на контрол на промените за промени в данните на приложението, данните на приложението и потребителските данни трябва да бъдат изрично разделени.

В Oracle това трябва да се направи чрез поставяне на данни за приложения и потребители в собствена схема. В Microsoft SQL Server това трябва да стане чрез поставяне на всяка в отделна схема или - много по-добре - в отделна база данни. Правенето на тези избори трябва да бъде част от планирането на миграцията: Oracle има резолюция на име на две нива (схема / собственик - име на обект), докато SQL Server има резолюция на име на три нива (база данни - схема / собственик - име на обект).

Често срещан източник на объркване между световете на Oracle и SQL Server са - може би изненадващо - термините база данни и сървър :

Термин на SQL Server	Oracle Term	Определение
сървър	база данни (използва се взаимозаменяемо с сървър на общ език, освен ако не се отнася конкретно до сървърния хардуер, операционната система или мрежовите елементи; може да има една или повече бази данни на физически / виртуален сървър)	Работещ екземпляр, който може да 'говори' с други екземпляри чрез мрежови портове
база данни (част от сървър, съдържа множество схеми / собственици)	схема / собственик	Групирането на най-високо ниво

Това смесване на терминологията трябва да бъде ясно разбрано в проектите за миграция на различни платформи, тъй като погрешното тълкуване на термина може да доведе до неправилни решения за конфигуриране, които трудно могат да бъдат решени със задна дата.

Правилното разделяне на приложението и потребителските данни позволява на екипа на DBA да се справи с втората си по важност грижа: сигурността на потребителските данни. Тъй като потребителските данни се намират отделно, ще бъде много лесно да се внедри a процедура счупено стъкло за достъп до потребителски данни при необходимост.

Заключение : Процесите за контрол на промените са критични за всеки проект. В софтуерното инженерство управлението на промените от страна на базата данни често се пренебрегва, тъй като се счита, че данните са „твърде течни“. Но точно защото данните са „течни“ и „постоянни“ едновременно, добре проектираният процес за контрол на промените трябва да бъде крайъгълният камък на правилната архитектура на средата на базата данни.

Относно използването на инструменти за мигриране на кодове

Стандартните първоначални инструменти, Oracle Migration Workbench и Асистент за миграция на SQL Server , може да бъде полезно при миграция на код. Но това, което трябва да се вземе предвид, е правилото 80/20 : Когато кодът ще бъде мигриран 80% правилно, разрешаването на останалите 20% ще отнеме 80% от усилията ви за миграция.

Най-големият риск при използването на инструменти за миграция е далеч възприятието за „сребърна кула“. Човек може да се изкуши да си помисли: „Ще свърши работа и аз просто ще трябва да направя малко почистване и подреждане.“ Наблюдавах проект, който се провали поради такова отношение на екипа за преобразуване и неговото техническо ръководство.

От друга страна, отне ми четири работни дни, за да извърша основното преобразуване на средна система на Microsoft SQL Server 2008 (около 200 обекта), използвайки функцията за групово заместване на Notepad ++ като основен инструмент за редактиране.

Нито един от критичните елементи за миграция, които съм разглеждал досега, не може да бъде разрешен с инструменти за миграция.

Разбира се, използвайте инструменти за помощ при миграция, но не забравяйте, че те предоставят само помощ за редактиране. Полученият изходен текст трябва да има преглед, модификация и - в някои случаи - пренаписване, за да се превърне в достоен за производство код.

Разработването на инструменти за изкуствен интелект може да отстрани тези недостатъци на инструментите за миграция в бъдеще, но очаквам, че разликите между базите данни ще се размият преди това и всеки процес на миграция ще стане ненужен. Така че, докато са необходими такива видове проекти, ще трябва да го правим по стария начин, като използваме старомоден човешки интелект.

Заключение : Използването на инструменти за подпомагане на миграцията е полезно, но не е „сребърен куршум“ и всеки проект за преобразуване все още изисква подробен преглед на горните точки.

Миграции на Oracle / SQL Server: Винаги поглеждайте по-внимателно

Oracle и Microsoft SQL Server са двете най-разпространени RDBMS платформи в корпоративната среда. И двете имат основно съответствие със стандарта ANSI SQL и малки сегменти код могат да бъдат премествани с много малко модификации или дори такива, каквито са.

Това сходство създава измамно впечатление, че миграцията между двете платформи е проста, ясна задача и че едно и също приложение може лесно да бъде прието от използването на един RDBMS back end към друг.

На практика такива миграции на платформи далеч не са тривиални и трябва да вземат предвид фините елементи на вътрешната работа на всяка платформа и най-вече начина, по който те изпълняват подкрепа за най-важния елемент от управлението на данни: транзакциите.

Докато обхващах две RDBMS платформи, които са в основата на моя опит, едно и също предупреждение - „изглежда еднакво не означава, че работи еднакво“ - трябва да се приложи към преместване на код между други системи за управление на бази данни, съвместими с SQL. И във всички случаи, първата точка на внимание трябва да бъде върху това как изпълнението на управлението на транзакции се различава между източника и целевите платформи.

Разбиране на основите

Какво представлява последователността на данните в Oracle?

В Oracle съгласуваността на данните се основава на многоверсионност: Всяка версия на данните, която се отнася до един момент във времето, трябва да бъде в такова състояние, че да няма нарушения на активните ограничения на базата данни.

Какво е последователност на четенето в Oracle?

Съвместимостта на Oracle за четене е гаранция на ниво израз на SQL, че всички данни ще бъдат върнати в последователно състояние - както беше в момента, когато изявлението беше изпратено за изпълнение. За да подкрепи това, Oracle управлява множество версии на данни, съответстващи на множество точки във времето.

Какво е проверка на последователността на базата данни?

Проверката за съгласуваност на базата данни е процес за потвърждаване, че базата данни е в постоянно състояние и няма липсващи или повредени блокове данни. Тя трябва да се извършва на архиви и на бази данни, чиято функционалност се възстановява след хардуерен отказ.

Какво представлява последователността на данните в SQL?

В бази данни, съвместими с SQL, последователността на данните се отнася до състояние на данните, при което няма нарушение на активни ограничения на базата данни. Това е основното изискване, което трябва да бъде изпълнено в края на всяка транзакция.

Какво представляват частните синоними и публичните синоними в Oracle?

Частните синоними на Oracle са създадени в определена схема и могат да бъдат достъпни чрез препратки към схеми по същия начин, както всеки друг обект на схема. От друга страна, публичните синоними се създават в групата PUBLIC и могат да бъдат достъпни без препратка към схема.

Как променяте синонимите в Oracle?

В Oracle, за да промените към кой обект се отнася синоним, синонимът трябва да бъде изпуснат и пресъздаден.

Какво е екземпляр на Oracle?

Екземпляр на Oracle е цялата колекция от фонов процес и разпределена памет, която представлява базата данни на Oracle като приложение, което съхранява и манипулира данни.