DOCSLIB.ORG

Playbook Migrate from Oracle to Amazon Aurora Postgresql

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Oracle Database 11g/12c To Amazon Aurora with PostgreSQL Compatibility (9.6.x) Migration Playbook Version: 1.1, January 2018 Written by: David Yahalom, Nimrod Keinan 1 © 2017, Amazon Web Services, Inc. or its affiliates. All rights reserved. Document written by David Yahalom and Nimrod Keinan. Notices This document is provided for informational purposes only. It represents AWS’s current product offerings and practices as of the date of issue of this document, which are subject to change without notice. Customers are responsible for making their own independent assessment of the information in this document and any use of AWS’s products or services, each of which is provided “as is” without warranty of any kind, whether express or implied. This document does not create any warranties, representations, contractual commitments, conditions or assurances from AWS, its affiliates, suppliers or licensors. The responsibilities and liabilities of AWS to its customers are controlled by AWS agreements, and this document is not part of, nor does it modify, any agreement between AWS and its customers. 2 Introduction To migrate an Oracle database to Amazon Aurora with PostgreSQL Compatibility, you usually need to perform both automated and manual tasks. The automated tasks involve data migration and schema conversion using the AWS Database Migration Service (AWS DMS) and AWS Schema Conversion Tool (AWS SCT). The manual tasks involve post-migration “touch-ups” for certain database objects that can’t be migrated automatically. This whitepaper primarily focuses on the manual aspects of database migration and includes step-by-step instructions that you can adapt for your own requirements. In this document, we focus on how to manually migrate specific Oracle database objects and features to Amazon Aurora with PostgreSQL Compatibility equivalents. We also include a brief overview that explains how to use the AWS Schema Conversion Tool (AWS SCT) for automatic migrations of schema objects. You can use this document as a supplementary guide for your database migrations – both as a guide to expand your PostgreSQL competency if you come from an Oracle database background and as a reference to help build Oracle-comparable functionality in Amazon Aurora with PostgreSQL compatibility This document does not yet cover all Oracle Database features and capabilities from a migration perspective. For the first release, we focus on some of the most important features and will continue to expand the Playbook document over time. Not all Oracle features have direct and fully compatible equivalents in PostgreSQL. In these cases, we present our recommendations for the best-possible equivalent features in Amazon Aurora with PostgreSQL compatibility. We also plan to expand this document in the future and add new chapters specifically dedicated to advanced topics such as Oracle security, High Availability and Disaster Recovery, Performance Tuning, and more. Disclaimer The various code snippets, commands, guides, best practices, and scripts included in this document should be used for reference only and are provided as-is without warranty. Please be sure to test all of the code, commands, best practices, and scripts outlined in this document in a non-production environment first. Amazon and its affiliates are not responsible for any direct or indirect damage that can occur from the information contained in this document. 3 Automatic Schema Migration Help Section Link Using the AWS Schema Conversion Tool for automatic schema conversion SQL & PL/SQL (Manual) Oracle Feature Aurora PostgreSQL Compatibility Feature Link Anonymous Block Do Yes Link Execute Immediate Execute & Prepare Yes Link DBMS_RANDOM random() Yes* Link DBMS_OUTPUT RAISE Yes Link Procedures & Functions Functions Yes* Link User Defined Functions Functions Yes* (UDFs) Link UTL_FILE N/A None Link JSON Document Support JSON Document Support Yes* Link OLAP Functions Window Functions Yes Link PL/SQL Cursors Cursors Yes Link Single Row & Aggregate Single Row & Aggregate Yes Functions Functions Link Merge SQL Merge Yes Link Create Table As Select (CTAS) Create Table As Select (CTAS) Yes Link Common Table Expression Common Table Expression Yes (CTE) (CTE) Link Insert From Select Insert From Select Yes Link Inline Views Inline Views Yes Link DB Hints Query Planning Yes* 4 Tables & Indexes (Manual) Oracle Feature Aurora PostgreSQL Compatibility Feature Link Index Organized Tables (IOTs) PostgreSQL “Cluster” Tables Yes* Link Common Data Types Common Data Types Yes Link Table Constraints Table Constraints Yes Link Table Partitioning including: Table Partitioning including: Yes* RANGE, LIST, HASH, RANGE, LIST COMPOSITE, Automatic LIST Link Exchange and Split Partitions N/A None Link Temporary Tables Temporary Tables Yes* Link Unused Columns ALTER TABLE DROP COLUMN Yes Link Virtual Columns Views and/or Function as a Yes* Column Link User Defined Types (UDTs) User Defined Types (UDTs) Yes Link Read Only Tables and Table Read Only Roles and/or Yes* Partitions Triggers Link Index Types Index Types Yes* Link B-Tree Indexes B-Tree Indexes Yes Link Composite Indexes Multi-Column Indexes Yes Link BITMAP Indexes BRIN Indexes Minimal Link Function-Based Indexes Expression Indexes Yes Link Local and Global Partitioned Partitioned Indexes Yes* Indexes Link Identity Columns Serial Data Type Yes* Link MVCC MVCC Yes* (Table and Row Locks) (Table and Row Locks) Link Character Sets Encoding Yes* Link Transaction Model Transactional Model Yes* Link LOBs and SecureFile LOBs LOBs Yes* Database Objects (Manual) Oracle Feature Aurora PostgreSQL Compatibility Feature Link Materialized Views Materialized Views Yes* Link Common Data Types Common Data Types Yes Link Oracle Triggers PostgreSQL Trigger Procedure Yes* Link Views Views Yes Link Sequences Sequences Yes 5 Link Database Links PostgreSQL DBLink and Yes* FDWrapper 6 Database Administration (Manual) Oracle Feature Aurora PostgreSQL Compatibility Feature Link Recovery Manager (RMAN) Amazon Aurora Snapshots Yes Link Flashback Database Amazon Aurora Snapshots Yes Link 12c Multi-Tenant Databases Yes* Architecture: PDBs and CDB Link Tablespaces and DataFiles Tablespaces Yes* Link Data Pump pg_dump and pg_restore Yes Link Resource Manager Separate Amazon Aurora Yes Clusters Link Database Users Database Roles Yes Link Database Roles Database Roles Yes Link SGA & PGA Memory Memory Buffers Yes Link V$ Views & the Data System Catalog Tables, Yes* Dictionary Statistics Collector, Amazon Aurora Performance Insights Link Log Miner Logging Options Yes Link Instance & Database Amazon Aurora Parameter Yes Parameters (SPFILE) Groups Link Session Parameters Session Parameters Yes Link Alert.log (error log) Error Log via AWS Yes Management Console Link Automatic and Manual Automatic and Manual Yes Statistics Collection Statistics Collection Link Viewing Execution Plans Viewing Execution Plans Yes 7 Automatic Migration of Oracle Schema Objects Using the AWS Schema Conversion Tool 8 Automatic Schema Migration [Back to TOC] This section provides a step-by-step process for using the AWS Schema Conversion Tool (AWS SCT) to migrate an Oracle database to an Aurora with PostgreSQL compatibility database cluster. Amazon SCT can automatically migrate most of the database objects. While this document primarily covers the best practices, feature-parity aspects of manual database migrations, and Oracle to Amazon Aurora with PostgreSQL compatibility migration best practices, we recommend using AWS SCT as the first step of the process. AWS SCT is a downloadable Java utility that runs locally on your computer. It connects to the source and target databases, scans the source database schema objects (tables, views, indexes, procedures, etc.), and converts them to the target database objects. For more information, see http://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/Welcome.html 9 Download AWS SCT and Install JDBC Drivers JDBC drivers are required for database connectivity to both the source and target databases. 1. Download SCT: http://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/CHAP_SchemaConversionTool.Installing.h tml 2. Download the Oracle JDBC Driver (ojdbc7.jar): http://www.oracle.com/technetwork/database/features/jdbc/jdbc-drivers-12c-download-1958347.html 3. Download the PostgreSQL JDBC Driver (postgresql-9.4-1204.jdbc42.jar): https://jdbc.postgresql.org/download.html Configure SCT for Database Migration 1. Launch SCT. 2. Choose the JAR files path under SCTs Global Settings 3. Click Global Settings > Drivers 4. Add the file path to the Oracle and the PostgreSQL JDBC drivers 5. Use the following filenames: Oracle JDBC JAR - ojdbc7.jar PostgreSQL JDBC JAR - postgresql-9.4-1204.jdbc42.jar 6. Click OK. 10 AWS SCT – Database Migration Project Configuration Create a new SCT project which will guide you, step-by-step, through the schema conversion process. 1. Click SCT > File > New Project Wizard 2. Select a source database for migration (the Oracle Database to migrate to Aurora with PostgreSQL Compatibility). 3. Enter a project name, specify the location of the SCT project files, choose the source database workload characteristics (OLTP or OLAP), and select the source database engine (Oracle). 11 4. Configure the source database connection properties: • Server hostname • Oracle Net Listener port number • Oracle Database SID • Privileged username and password. For example, the Oracle system user. 5. Click Next. 6. Select the source Oracle schema for migration. 12 7. SCT analyzes the source
Recommended publications
  • Different Kinds of Database Schema

    Different Kinds of Database Schema

    Different Kinds Of Database Schema Sarcophagous or conglutinant, Hasty never categorize any Banff! Plato usually parsing devotedly or opaque harum-scarum when agraphic Manish blemishes extortionately and steady. Healthiest Worthy usually spiral some animadversions or outdid universally. Once jen starts a value for a new functionality or more detailed documentation about database using it does it in terms of database Usually it does not different models of. Jen has values in your email lists the documentation explaining some other kinds of different database schema indicates the external schemas? Sometimes find there are assumed to ensure that whenever the foreign key is a product types of making other kinds of different entities. We do prefer releasing frequently as that keeps the updates small, we serve a multitude of customers with different use cases, users to infer state by replaying events. Agile processes approach where the different kinds of database schema changes to represent relationships together with? Primary keys What do you think will happen if two users with the same name are added to the Users table? Any topic page is different kinds of database schema and punctuation, such as frequent changes needs a blueprint for qa staff should be filled in. Before they appeared on the scene most of the thinking about software process was about understanding requirements early, database schemas not only include tables, carefully modified to violate Normalization rules to increase reporting speed. This separate working works with files, which DBMS is best? On Career Karma, above and beyond the basic syntactical constraints imposed by XML itself. Now with a lot of serious time and effort you could eventually get to some kind of structure for understanding the data.
  • Database Schema Migration Tools Open Source

    Database Schema Migration Tools Open Source

    Database Schema Migration Tools Open Source Validating Darian sometimes tranquillize his barony afterwards and cast so stubbornly! Vilhelm rocket his flirt bludge round-arm or best after Worthy smuts and formulise conspiratorially, quinoidal and declaratory. Implied Ernest rinsings: he built his Kathy lexically and amorally. Does this coupon code that is ideal state can replicate for speaking with their database tools and handled it ensures data, a granular control Review the tool for migrating to? If necessary continue browsing the site, will agree specify the rush of cookies on this website. Iteratively make both necessary changes to applications. 1 Database Version Control DBMS Tools. It moves to schema migration database tools source database migration is a few clicks configuration as well as someone to. GDPR: floating video: is from consent? Openmysql rootwelcometcp1270013306migrationtest if err nil fmt. Database health Suite itself and Schema Sync across. The Top 33 Database Migrations Open Source Projects. The community edition of PDI is useful enough they perform our mystery here. Migration Supports schema migration for MySQL SQLite and PostgreSQL Reverse Engineering For existing database structures we to reverse enginering. Most schema migration tools aim to minimize the footprint of schema changes on any existing data in tally database. Contains errors, warnings, and informational messages relating to migration operations. To schema and tools with a tool allows you take years of the tooling uses the type of. But migrating data services ownership, and integrity checks will be able to other objects to use open source tools now part of. Making database schema while capturing any databases, open source endpoint to migrate to get started with constraints between data sources in an altered outside the.
  • Oracle Berkeley DB Installation and Build Guide Release 18.1

    Oracle Berkeley DB Installation and Build Guide Release 18.1

    Oracle Berkeley DB Installation and Build Guide Release 18.1 Library Version 18.1.32 Legal Notice Copyright © 2002 - 2019 Oracle and/or its affiliates. All rights reserved. This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited. The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing. Berkeley DB, and Sleepycat are trademarks or registered trademarks of Oracle. All rights to these marks are reserved. No third- party use is permitted without the express prior written consent of Oracle. Other names may be trademarks of their respective owners. If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable: U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.
  • Unbound: a New Secure and High Performance Open Source DNS Server

    Unbound: a New Secure and High Performance Open Source DNS Server

    New Open Source DNS Server Released Today Unbound – A Secure, High-Performance Alternative to BIND – Makes its Debut within Open Source Community Amsterdam, The Netherlands and Mountain View, CA – May 20, 2008 – Unbound – a new open source alternative to the BIND domain name system (DNS) server– makes its worldwide debut today with the worldwide public release of Unbound 1.0 at http://unbound.net. Released to open source developers by NLnet Labs, VeriSign, Inc. (NASDAQ: VRSN), Nominet, and Kirei, Unbound is a validating, recursive, and caching DNS server designed as a high- performance alternative for BIND (Berkeley Internet Name Domain). Unbound will be supported by NLnet Labs. An essential component of the Internet, the DNS ties domain names (such as www.verisign.com) to the IP addresses and other information that Web browsers need to access and interact with specific sites. Though it is unknown to the vast majority of Web users, DNS is at the heart of a range of Internet-based services beyond Web browsing, including email, messaging and Voice Over Internet Protocol (VOIP) telecommunications. Although BIND has been the de facto choice for DNS servers since the 1980s, a desire to seek an alternative server that excels in security, performance and ease of use prompted an effort to develop an open source DNS implementation. Unbound is the result of that effort. Mostly deployed by ISPs and enterprise users, Unbound will also be available for embedding in customer devices, such as dedicated DNS appliances and ADSL modems. By making Unbound code available to open source developers, its originators hope to enable rapid development of features that have not traditionally been associated with DNS.
  • A Reverse Engineering Approach for Migrating Data-Intensive Web Sites to the Semantic Web

    A Reverse Engineering Approach for Migrating Data-Intensive Web Sites to the Semantic Web

    A reverse engineering approach for migrating data-intensive web sites to the Semantic Web Nenad Stojanovic, Ljiljana Stojanovic, Raphael Volz AIFB Institute, Univ. of Karlsruhe,Germany, {nst,lst,volz}@aifb.uni-karlsruhe.de The Semantic Web is intended to enable machine understandable web content and seems to be a solution for many drawbacks of the current Web. It is based on metadata that describe the formal semantics of Web contents. In this paper we present an integrated and semi-automatic approach for generating shared-understandable metadata of data- intensive Web applications. This approach is based on mapping the given relational schema into already existing ontology structure using a reverse engineering process. As a case study we present this style of a schema- and data-migration for our Institute web portal. The presented approach can be applied to a broad range of today's data-intensive Web sites. 1. INTRODUCTION The Semantic Web is one of today's hot keywords. It is about bringing ``[...] structure to the meaningful content of Web pages, creating an environment where software agents, roaming from page to page, can readily carry out sophisticated tasks for users.'' [17]. In order to enable this, web sites are enhanced with metadata that provide formal semantics for Web content. The key technology involved here are the ontologies. The ontologies provide consensual domain models, which are understandable to both human beings and machines as a shared conceptualisation of a specific domain that is given. Using ontologies, a content is made suitable for machine consumption, opposing to the content found on the web today, which is primarily intended for human consumption.
  • Stateless DNS

    Stateless DNS

    Technical Report KN{2014{DiSy{004 Distributed System Laboratory Stateless DNS Daniel Kaiser, Matthias Fratz, Marcel Waldvogel, Valentin Dietrich, Holger Strittmatter Distributed Systems Laboratory Department of Computer and Information Science University of Konstanz { Germany Konstanzer Online-Publikations-System (KOPS) URL: http://nbn-resolving.de/urn:nbn:de:bsz:352-0-267760 Abstract. Several network applications, like service discovery, file dis- covery in P2P networks, distributed hash tables, and distributed caches, use or would benefit from distributed key value stores. The Domain Name System (DNS) is a key value store which has a huge infrastructure and is accessible from almost everywhere. Nevertheless storing information in this database makes it necessary to be authoritative for a domain or to be \registered" with a domain, e.g. via DynDNS, to be allowed to store and update resource records using nsupdate . Applications like the ones listed above would greatly benefit from a configurationless approach, giving users a much more convenient experience. In this report we describe a technique we call Stateless DNS, which allows to store data in the cache of the local DNS server. It works without any infrastructure updates; it just needs our very simple, configurationless echo DNS server that can parse special queries containing information desired to be stored, process this information, and generate DNS answers in a way that the DNS cache that was asked the special query will store the desired information. Because all this happens in the authority zone of our echo DNS server, we do not cause cache poisoning. Our tests show that Stateless DNS works with a huge number of public DNS servers.
  • Automated Testing of Database Schema Migrations

    Automated Testing of Database Schema Migrations

    DEGREE PROJECT IN COMPUTER SCIENCE AND ENGINEERING, SECOND CYCLE, 30 CREDITS STOCKHOLM, SWEDEN 2019 Automated Testing of Database Schema Migrations PETER JONSSON KTH ROYAL INSTITUTE OF TECHNOLOGY SCHOOL OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCE Automated Testing of Database Schema Migrations PETER JONSSON Master in Computer Science Date: June 28, 2019 Supervisor: Johan Gustavsson Examiner: Elena Troubitsyna School of Electrical Engineering and Computer Science Host company: The Swedish Police Authority Swedish title: Automatiserad testning av databasschemaförändringar iii Abstract Modern applications use databases, and the majority of them are relational databases, which use schemas to impose data integrity constraints. As appli- cations change, so do their databases. Database schemas are changed using migrations. Certain conditions can result in migrations failing in production environments, leading to a broken database state and testing can be problem- atic without accessing production data which can be sensitive. Two migration validation methods were proposed and implemented to au- tomatically reject invalid migrations that are not compatible with the database state. The methods were based on, and compared to, a default method that used Liquibase to structure and perform migrations. The assertion method used knowledge of what a valid state would look like to generate pre-conditions from assertions to verify that the database’s state matched expectations and that the migrations were compatible with a database’s state prior to migra- tion. The schema method, used a copy of the production database’s schema to perform migrations on an empty database in order to test the compatibility of the old and new schemas. 108 test cases consisting of a migration and a database state were used to test all methods.
  • Internet Systems Consortium, Inc

    Internet Systems Consortium, Inc

    BIND 9 Administrator Reference Manual I S C Copyright c 2004, 2005, 2006, 2007, 2008, 2009, 2010 Internet Systems Consortium, Inc. (”ISC”) Copyright c 2000, 2001, 2002, 2003 Internet Software Consortium. Permission to use, copy, modify, and/or distribute this software for any purpose with or without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies. THE SOFTWARE IS PROVIDED ”AS IS” AND ISC DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. 2 Contents 1 Introduction 9 1.1 Scope of Document . 9 1.2 Organization of This Document . 9 1.3 Conventions Used in This Document . 9 1.4 The Domain Name System (DNS) . 10 1.4.1 DNS Fundamentals . 10 1.4.2 Domains and Domain Names . 10 1.4.3 Zones . 10 1.4.4 Authoritative Name Servers . 11 1.4.4.1 The Primary Master . 11 1.4.4.2 Slave Servers . 11 1.4.4.3 Stealth Servers . 11 1.4.5 Caching Name Servers . 12 1.4.5.1 Forwarding . 12 1.4.6 Name Servers in Multiple Roles . 12 2 BIND Resource Requirements 13 2.1 Hardware requirements . 13 2.2 CPU Requirements . 13 2.3 Memory Requirements .
  • Bind 9 Linux 3.19, Microsoft Windows Server 2008 Integration Guide: Bind 9

    Bind 9 Linux 3.19, Microsoft Windows Server 2008 Integration Guide: Bind 9

    Integration Guide Bind 9 Linux 3.19, Microsoft Windows Server 2008 Integration Guide: Bind 9 Imprint copyright 2016 Utimaco IS GmbH Germanusstrasse 4 D-52080 Aachen Germany phone +49 (0)241 / 1696-200 fax +49 (0)241 / 1696-199 web http://hsm.utimaco.com email [email protected] document version 1.2.1 date January 2016 author System Engineering HSM document no. SGCS_IG_BIND9 all rights reserved No part of this documentation may be reproduced in any form (printing, photocopy or according to any other process) without the written approval of Utimaco IS GmbH or be processed, reproduced or distributed using electronic systems. Utimaco IS GmbH reserves the right to modify or amend the documentation at any time without prior notice. Utimaco IS GmbH assumes no liability for typographical errors and damages incurred due to them. All trademarks and registered trademarks are the property of their respective owners. Contents 1 Introduction 4 1.1 Concepts ............................................. 4 2 Requirements 5 2.1 Supported Operating Systems ................................ 5 3 Installation 6 3.1 Install CryptoServer Hardware ................................. 6 3.2 Install CryptoServer Software ................................. 6 4 Procedures 7 4.1 Configure PKCS#11 Environment ............................... 7 4.1.1 Linux ........................................... 7 4.1.2 Microsoft Windows .................................. 7 4.1.3 Adjust Configuration File ............................... 7 4.2 Test PKCS#11 Environment .................................. 8 4.3 Patch and Build OpenSSL ................................... 9 4.3.1 Linux ........................................... 9 4.3.2 Microsoft Windows .................................. 10 4.4 Install BIND Domain Name Server .............................. 12 4.4.1 Linux ........................................... 12 4.4.2 Microsoft Windows .................................. 12 5 Generate Keys and Sign a Domain Zone 14 5.1 ReSigning Domain Zones ..................................
  • Getting Started with Berkeley DB Java Edition

    Getting Started with Berkeley DB Java Edition

    Oracle Berkeley DB, Java Edition Getting Started with Berkeley DB Java Edition 12c Release 2 Library Version 12.2.7.5 Legal Notice Copyright © 2002 - 2017 Oracle and/or its affiliates. All rights reserved. This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited. The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing. Berkeley DB, Berkeley DB Java Edition and Sleepycat are trademarks or registered trademarks of Oracle. All rights to these marks are reserved. No third-party use is permitted without the express prior written consent of Oracle. Other names may be trademarks of their respective owners. If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable: U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.
  • Analysis of DNS Resolver Performance Measurements Author

    Analysis of DNS Resolver Performance Measurements Author

    Master in System and Network Engineering Analysis of DNS Resolver Performance Measurements Supervisors: Author: Yuri Schaeffer Hamza Boulakhrif [email protected] [email protected] Willem Toorop [email protected] July 13, 2015 Abstract The Domain Name System (DNS) is an essential building block of the Internet. Applica- tions depend on it in order to operate properly. Therefore DNS resolvers are required to perform well, and do whatever they can to provide an answer to a query. In this paper a methodology is devised to measure the performance of the Unbound, BIND, and PowerDNS resolvers. Measurements of these resolvers is required to be objective and not biased. Analysis is conducted on these performance measurements, where the implementations are compared to each other. Corner cases have also been identified and analysed. Acknowledgement I would like to thank NLnet Labs for providing this interesting Research Project. Also the support they provided throughout this project is really appreciated. Especially Willem Toorop and Yuri Schaeffer who answered all of my questions and guided me through this project. Thanks go also to Wouter Wijngaards who answered my questions related to DNS resolvers. The performed measurements during this project were carried out from the SNE lab, at the University of Amsterdam. I would also like to thank Harm Dermois for providing his server in the lab to perform these measurements. Special thanks also go to the SNE staff for their support and guidance. This does not only concern this project but the entire study. Hamza Boulakhrif 1 Contents 1 Introduction 3 1.1 Related Work . .3 1.2 Research Questions .
  • Migrating to the Cloud: Oracle Client-Server Modernization

    Migrating to the Cloud: Oracle Client-Server Modernization

    Migrating to the Cloud > This page intentionally left blank Migrating to the Cloud Oracle Client/Server Modernization Tom Laszewski Prakash Nauduri Technical Editor Ward Spangenberg AMSTERDAM • BOSTON • HEIDELBERG • LONDON NEW YORK • OXFORD • PARIS • SAN DIEGO SAN FRANCISCO • SINGAPORE • SYDNEY • TOKYO Syngress is an imprint of Elsevier Acquiring Editor: Chris Katsaropoulos Development Editor: Matt Cater Project Manager: Jessica Vaughan Designer: Alisa Andreola Syngress is an imprint of Elsevier 225 Wyman Street, Waltham, MA 02451, USA Ó 2012 Elsevier Inc. All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or any information storage and retrieval system, without permission in writing from the publisher. Details on how to seek permission, further information about the Publisher’s permissions policies and our arrangements with organizations such as the Copyright Clearance Center and the Copyright Licensing Agency, can be found at our website: www.elsevier.com/permissions. This book and the individual contributions contained in it are protected under copyright by the Publisher (other than as may be noted herein). Notices Knowledge and best practice in this field are constantly changing. As new research and experience broaden our understanding, changes in research methods or professional practices may become necessary. Practitioners and researchers must always rely on their own experience and knowledge in evaluating and using any information or methods described herein. In using such information or methods they should be mindful of their own safety and the safety of others, including parties for whom they have a professional responsibility.