 |
Oficinas en México |
|
|||||||||
   |
||||||||
Oracle DBA ServicesIT Consulting Services• Oracle Real Application Clusters (RAC)• Oracle Data Guard • Database design to you corporation needs • Software installation and Database creation • Oracle Migrations • Data Modeling • Oracle Recovery Manager (RMAN) • Oracle Training onsite or offsite • Oracle database upgrade services- including Oracle 9i, 10g, 11g and 12c • Oracle database tuning • Oracle Security Patches Updates • Oracle Critical Patches Upgrade • Oracle migration services • Oracle Security • Oracle Staffing onsite or offsite, full-time or part-time including evenings, weekends and holidays Oracle Real Application Clusters (RAC) Oracle Real Application Clusters (RAC), introduced with Oracle9i in 2001, supersedes the Oracle Parallel Server (OPS) database option. Whereas Oracle9i required an external clusterware for most of the Unix flavors (except for Linux and Windows where Oracle provided free clusterware called Cluster Ready Services or CRS), as of Oracle 10g, Oracle's clusterware product was available for all operating systems. With the release of Oracle Database 10g Release 2 (10.2), Cluster Ready Services was renamed to Oracle Clusterware. When using Oracle 10g or higher, Oracle Clusterware is the only clusterware that you need for most platforms on which Oracle RAC operates (except for Tru cluster, in which case you need vendor clusterware). You can still use clusterware from other vendors, if the clusterware is certified for Oracle RAC. DBA to install, configure and maintain Oracle RAC is a cluster database with a shared cache architecture that overcomes the limitations of traditional shared-nothing and shared-disk approaches to provide highly scalable and available database solutions for all your business applications. Oracle RAC is a key component of Oracle's private cloud architecture. Oracle RAC support is included in the Oracle Database Standard Edition for higher levels of system uptime. In RAC, the write-transaction must take ownership of the relevant area of the database: typically, this involves a request across the cluster interconnection (local IP network) to transfer the data-block ownership from another node to the one wishing to do the write. This takes a relatively long time (from a few to tens of milliseconds) compared to single database-node using in-memory operations. For many types of applications, the time spent coordinating block access across systems is low relative to the many operations on the system, and RAC will scale comparably to a single system. Moreover, high read-transactional databases (such as data-warehousing applications) work very well under RAC, as no need for ownership-transfer exists. (Oracle 11g has made many enhancements in this area and performs a lot better than earlier versions for read-only workloads. The overhead on the resource mastering (or ownership-transfer) is minimal for fewer than three nodes, as the request for any resource in the cluster can be obtained in a maximum of three hops (owner-master-requestor). This makes Oracle RAC horizontally scalable with many nodes. Application vendors (such as SAP) use Oracle RAC to demonstrate the scalability of their application. RAC may require careful application partitioning to enhance performance. An application that scales linearly on an SMP machine may scale linearly under RAC. However, if the application cannot scale linearly on SMP, it will not scale when ported to RAC. In short, the application scalability is based on how well the application scales in a single instance. Oracle Data Guard Configure and maintain Oracle Data Guard to ensure high availability, data protection, and disaster recovery for enterprise data. Data Guard provides a comprehensive set of services that create, maintain, manage, and monitor one or more standby databases to enable production Oracle databases to survive disasters and data corruptions. Data Guard maintains these standby databases as transactionally consistent copies of the production database. Then, if the production database becomes unavailable because of a planned or an unplanned outage, Data Guard can switch any standby database to the production role, minimizing the downtime associated with the outage. Data Guard can be used with traditional backup, restoration, and cluster techniques to provide a high level of data protection and data availability. With Data Guard, the DBA can optionally improve production database performance by offloading resource-intensive backup and reporting operations to standby systems. A Data Guard configuration consists of one production database and one or more standby databases. The databases in a Data Guard configuration are connected by Oracle Net and may be dispersed geographically. There are no restrictions on where the databases are located, provided they can communicate with each other. For example, you can have a standby database on the same system as the production database, along with two standby databases on other systems at remote locations. Standby Databases - A standby database is a transactionally consistent copy of the primary database. Using a backup copy of the primary database, you can create up to nine standby databases and incorporate them in a Data Guard configuration. Once created, Data Guard automatically maintains each standby database by transmitting redo data from the primary database and then applying the redo to the standby database. Similar to a primary database, a standby database can be either a single-instance Oracle database or an Oracle Real Application Clusters database. A standby database can be either a physical standby database or a logical standby database: Physical standby database Provides a physically identical copy of the primary database, with on disk database structures that are identical to the primary database on a block-for-block basis. The database schema, including indexes, are the same. A physical standby database is kept synchronized with the primary database, though Redo Apply, which recovers the redo data received from the primary database and applies the redo to the physical standby database. A physical standby database can be used for business purposes other than disaster recovery on a limited basis. Logical standby database Contains the same logical information as the production database, although the physical organization and structure of the data can be different. The logical standby database is kept synchronized with the primary database though SQL Apply, which transforms the data in the redo received from the primary database into SQL statements and then executing the SQL statements on the standby database. A logical standby database can be used for other business purposes in addition to disaster recovery requirements. This allows users to access a logical standby database for queries and reporting purposes at any time. Also, using a logical standby database, you can upgrade Oracle Database software and patch sets with almost no downtime. Thus, a logical standby database can be used concurrently for data protection, reporting, and database upgrades. Database design to your corporation needs First Management Group 2000 understands that each client has their own business roles and expects carefully database design and implementation. We also understand our client’s future needs may change and they need for scalable databases to capture data from the websites and back-end applications. One of the most important elements for our client’s databases is data integrity, availability and security. Our database team has broad and profound knowledge with Oracle MySql and SQL Server. Software installation and Database creation First Management Group keeps in mind your application to determinate what type of installation you need and what default schemas are needed when creation your database. We understand the Security Vulnerabilities and the risk of creating a database with all schemas. Oracle Migrations Our DBA team has the expertise to migrate your database from different Oracle platform and from other databases. Migrate your non-Oracle database and receive a trade-in credit of up to 100% for a maximum of US $1,000,000 from Oracle Corporation. We’ll Migrate IDB2, Informix, Microsoft SQL Server, or Sybase databases to Oracle 12c to take advantage or Oracle Corporation trade-in-credit. Backup and Recovery DBAs are responsible for developing, implementing, and periodically testing a backup and recovery plan for the databases they manage. Even in cases where the OS administrators are backing up the entire system or a separate system, the DBA has final responsibility for making sure that the backups are being done as scheduled and that they include all the files needed to make database recovery possible after a failure. When failures do occur, the DBA needs to know how to use the backups to return the database to operational status as quickly as possible, without losing any transactions that were committed. There are several ways the database can fail, and the DBA must have a strategy to recover from each. From a business standpoint, there is a cost to doing backups, and the DBA makes management aware of the cost/risk tradeoffs of various Oracle Recovery Manager (RMAN) • Plan effective backup and recovery procedures • Use Recovery Manager to create backups and perform recovery operations • Use Oracle Flashback technologies to recover from human error • Install Oracle Secure Backup • Perform an Oracle-suggested backup to tape • Use Oracle Secure Backup to perform a file system backup • Use Oracle Secure Backup to perform a file system restoration • Perform an encrypted database backup and restore • Manage the Oracle Secure Backup environment • Monitor and tune Recovery Manager • Perform tablespace point-in-time recovery • Create a duplicate database • Create and manage a recovery catalog database Oracle Security Because databases centralize the storage of data, they are attractive targets for hackers and even curious employees. The DBA must understand the particular security model that the database product uses, and how to use it effectively to control access to the data. The auditing task is particularly important currently, as regulatory laws like Sarbanes-Oxley and HIPPA have reporting requirements that must be met. The DBA must take additional precautions to protect the databases, such applying quarterly Critical Patch Updates and Security Alert (OCPU) from Oracle Corporation and making sure all databases complied DISA STIGS and DoD standards. The three basic security tasks are authentication: Critical Patch Updates Critical Patch Updates are collections of security fixes for Oracle products. They are available to customers with valid support contracts. They are released on the Tuesday closest to the 17th day of January, April, July and October. The next four dates are: • 16 July 2013 • 15 October 2013 • 14 January 2014 • 15 April 2014 • 17 July 2014 Starting with the October 2013 Critical Patch Update, security fixes for Java SE will be released under the normal Critical Patch Update schedule. Security Alerts Oracle will issue Security Alerts for vulnerability fixes deemed too critical to wait for distribution in the next Critical Patch Update. The Security Alerts released since 2005 are listed in the following table. Oracle training for Certifications in the following areas • Oracle Database 10g • Oracle Database 11g • Performance Tuning • Oracle Application server • PL/SQL • Forms Developer • Oracle Weblogic Server System Administration • SOA Architect Oracle Training Our instructors have the experience on both technical and teaching focusing on today’s technicality and customer needs to: • Oracle Database Administration • PL/SQL • Forms Developer • Data Modeling • Database Design Remote and on Site Database Administration Services • Dedicated primary DBA assigned to work with you as a remote DBA on an ongoing basis. • Daily Monitoring by you primary DBA and recommendations for database prevention maintenance. Proactive remote database administration • Weekly Database reports reviews and reports • 24/7 remote DBA availability • Onsite and offsite as deeded • Customized services for your special projects • Backups and Recovery strategies • Oracle Training onsite or offsite • Oracle database upgrade services- including Oracle 9i, 10g, 11g and 12c • Oracle database tuning • Oracle Security Patches Updates • Oracle Critical Patches Upgrade • Oracle migration services • Database re-org. Table de-fragmentation and partitioning. Indexes de-fragmentation • QA Test environment. • Database and applications tuning • Oracle Staffing onsite or offsite, full-time or part-time including evenings, weekends and holidays Oracle Security Patches SCP and critical Patches Updates (CPU) Critical Patch Updates Critical Patch Updates are collections of security fixes for Oracle products. They are available to customers with valid support contracts. They are released on the Tuesday closest to the 17th day of January, April, July and October. The next four dates are: • 16 July 2013 • 15 October 2013 • 14 January 2014 • 15 April 2014 • 17 July 2014 Starting with the October 2013 Critical Patch Update, security fixes for Java SE will be released under the normal Critical Patch Update schedule. Security Alerts Oracle will issue Security Alerts for vulnerability fixes deemed too critical to wait for distribution in the next Critical Patch Update. The Security Alerts released since 2005 are listed in the following table. Database Security Securing sensitive data against both external and internal threats requires continually monitoring your database activity. FMG200 provides auditing tools to identify security vulnerabilities in your environment. Oracle 11g databases enable most security controls by default, but any company must take additional steps to protect data from internal and external threats. FMG2000 supplies these procedural checks to safeguard against vulnerabilities on your database configuration, including your applications. Many database configuration options can be set in a way that compromises security. In some cases, by default, parameters are set insecurely. For example, Oracle will install schemas that you may not need and some companies do not lock or change the default password of these schemas. Or, as a further example, when the REMOTE_OS_AUTHENT parameter is set to “true,” anyone who can communicate with the database server is blindly allowed to connect to the database. Database security is an ongoing process. FMG2000 continually monitors systems to ensure security compliance. We continually update our procedures to keep up with the latest and changing threats. We encrypt back-up files. Not all data theft happens as a result of an outside attack. Sometimes, it’s the people we trust most that are the attackers. We keep the database server separate from the web server. Typically, when most web software is installed, the database is created for you. To make things easy, this database is created on the same server where the application itself is being installed, the web server. Unfortunately, this makes it all too easy for an attacker to access the data. If an attacker is able to crack the administrator account for the web server, then clearly, the data is readily available as well. We ensure that your databases have the current patches. Whereas many Oracle DBAs do not attend to this issue, FMG2000 DBAs use the same procedures and steps to find vulnerabilities in your databases as those used in the Department of Defense. Critical Patch Updates are collections of security fixes for Oracle products, available to customers with valid support contracts. Patches are released on the Tuesday closest to the 17th day of January, April, July and October. The next four dates are: • 15 October 2013 • 14 January 2014 • 15 April 2014 • 17 July 2014 Starting with the October 2013 Critical Patch Update, security fixes for Java SE will be released under the normal Critical Patch Update schedule. Security Alerts will be issued by Oracle for vulnerability fixes considered too critical to wait for distribution in the next Critical Patch Update. The Security Alerts released since 2005 are listed in the following table. |
||||||||
