First Quarterly Update on Oracle Graph (2023)

Graph databases are a part of Oracle’s converged database offering that store and navigate relationships between entities. Oracle provides support for both property and RDF knowledge graphs and simplifies the process of modeling relational data as graph structures. Interactive graph queries can run directly on graph data in the database or in a high-performance in-memory graph server. Oracle Graph Server and Client enables developers, analysts, and data scientists to use graphs within Oracle Database, while Graph Studio in Oracle Autonomous Database removes barriers to entry by automating complicated setup and management, making data integration seamless, and by providing step-by-step examples for getting started.

Oracle Graph Server and Client 23.1 is available for download for use with databases in the Cloud (OCI Marketplace image is available) and for databases on-premises. The marquee feature of this release is the release of a graph visualization JavaScript library for Property Graphs. This library allows developers to leverage many of the benefits of graph visualization available in Graph Studio and the graph visualization tool, but in their own applications. Additionally, GraphML now supports a Supervised Edge Wise model, which allows us to run tasks on edges, with up to 13x faster performance than our competitors. This release also offers a new API, for Python and Java, that can be used to import local GraphSON v3.0 files into Oracle Database, to easily import data, and create a graph from it.

 

Graph Visualization Library for Property Graphs

In this release, we also now offer a JavaScript library, which can be used to embed visualizations into your application. This library is available as a release artifact, titled oracle-graph-visualization-library-<version>.zip. The API takes in a JSON object and uses that object as the basis for building a visualization. The application should build a JSON object from the results of a PGQL query, and then use the API to visualize it.

This library offers a customizable layout for the visualization, as well as for vertex and edge appearance. For example, the highlight and expand vertices functionalities that is available in the graph visualization tool, is also available using this library, but using an API, rather than a UI.

Enhancements on GraphWise in GraphML

The previous version of PGX.ML supported models for vertices and graphlets. As of this release, we now support a Supervised Edge Wise model, which allows us to run tasks on edges. Using this model, you can now run classification, regression, and embedding generation on edges. In our benchmark assessments, we have also shown up to 13x faster performance than our competitors. This feature will soon be available in Graph Studio.

New and Improved GraphSON File Importer

GraphSON is the JSON based format, used to describe graph data. In this release, we added a new API, for Python and Java, that can be used to import local GraphSON v3.0 files into Oracle Database. This API imports data in batches and generates a CREATE PROPERTY GRAPH statement and applies it. The GraphSON importer also allows you to specify the output graph model that you need, such as PG_VIEW.

Graph Visualization for RDF Graphs

Graph visualization in the RDF Server and Query UI now uses Cytoscape.js. Cytoscape is an open sourced, general platform for complex network analysis and visualization. Developers can use popular Cytoscape features to visualize RDF graph query results.

Other Notable Features

◉ The session info returned by ServerInstance.getServerState() API now contains info which user session belongs to:

◉ Graph Server rpm install no longer attempts to install the Python client automatically. That can be done as a separate step.

◉ RDF Server now bundles Monaco code editor. This is the same code editor used in Graph Studio, so it enables SPARQL syntax highlighting.

Source: oracle.com

Continue reading

Spatial Studio 22.3 Available Now

We’re pleased to announce the release of Oracle Spatial Studio 22.3. Oracle Spatial Studio is a no-code web tool for working with the Spatial features of Oracle Database. This blog post will explore some of the new functionality available in this release. For general information about Spatial Studio and to get started, please click here.

Streamlined Creation of Custom Regions

Groups of existing regions may be combined into customer regions. Spatial Studio now streamlines the process by automatically creating a new table and dataset for the custom regions.

Dataset from OGC Web Map Service (WMS)

Users can now create a dataset from a WMS and include it as a layer in a map. Previously, Spatial Studio only supported WMS as a basemap.

Saved Pins for Use in Analysis

You can now drop multiple pins on a map and save them as a dataset. These saved pins can then be used like any other dataset for visualization and analysis.

Compound Non-Spatial Filter Criteria

Spatial Studio 22.3 adds the ability to define multiple criteria for a non-spatial filter analysis.

Source: oracle.com

Continue reading

Snapshot standby databases on Autonomous Database on Dedicated Exadata Infrastructure and Exadata Cloud@Customer

I am excited to announce the support for snapshot standby databases on Autonomous Database on Dedicated Exadata Infrastructure and Exadata Cloud@Customer. A snapshot standby database is a fully updateable standby database created by converting a standby Autonomous Container Database (ACD) to a snapshot standby ACD. A snapshot standby database receives and archives redo data from the primary database but does not apply it.

Snapshot standby feature temporarily converts your standby database to read/write mode giving you full access to the primary database data. An updatable standby database expands the application of Autonomous Databases by supporting many use cases. Following are some of them.

◉ Standby application instance can connect to the snapshot standby database in read/write mode to perform initial configurations or application testing

◉ Ability to patch snapshot standby database first and test with your standby application instance to confirm patch stability

◉ Offload analytics from the primary database to snapshot standby with the ability to change data on snapshot standby

You can convert a snapshot standby database to a physical standby database at any time. Doing so will discard all the local updates to your snapshot standby database and apply the data received from the primary database. A standby database cannot be in the snapshot standby mode for more than seven days. Afterward, the snapshot standby database will automatically convert back to the physical standby database. There are no limits on the number of times you can convert a standby database to a snapshot standby database. Snapshot standby databases are best used in scenarios where the benefit of having a temporary, updatable snapshot of your database justifies additional administrative complexity and increased time to recover from primary database failures.

While converting to a snapshot standby, you can either activate new database services that are active only in snapshot mode or use the same set of services used in the primary database. However, starting primary database services on the snapshot standby database may result in snapshot standby connection requests forwarded to the primary database or vice-versa if you use incorrect database connection strings. Extreme caution must be taken with the connection strings while using the same database services on primary and snapshot standby databases.

OCI Console Experience

Convert to snapshot standby database

To convert a physical standby ACD to a snapshot standby ACD, navigate to the details page of the standby ACD and select "Convert to snapshot standby"

In the next screen, you can create new database services or use the same services as on the primary database to connect to the database. The new database services option will create five and three new services for ATP and ADW workload types, respectively. Snapshot standby services are named with "_ss" identifier. Select any one of these options and hit Convert.

After the standby ACD converts to snapshot standby ACD, all the Autonomous Databases in the ACD will have changed to snapshot standby mode. The standby pill at the top of the details page will now reflect "snapshot standby" mode. The snapshot standby ACD will also have a banner message indicating the date and time when the snapshot standby will automatically convert to physical standby ACD.

Convert to physical standby database

To convert a snapshot standby ACD to a physical standby ACD, navigate to the details page of the standby ACD, select "Convert to physical standby" and hit Convert.

After the conversion, all the Autonomous Databases in the standby ACD will convert to physical standby databases, and the pill will change to "standby" mode.

Considerations

◉ Automatic Failover must be disabled on the primary ACD to convert your standby ACD to snapshot standby ACD

◉ Switchover operation is not supported when the standby ACD is in snapshot standby mode

◉ Failover operation will convert the snapshot standby ACD to physical standby ACD before performing a failover

◉ When the standby ACD is in snapshot standby mode, you cannot create, terminate, restore or scale Autonomous Databases in the primary ACD

◉ Automatic backups are disabled on the snapshot standby ACD

◉ The time required to convert a snapshot standby ACD to a physical standby ACD will depend on the amount of data changes on the primary ACD

Source: oracle.com

Continue reading

Simplify Your Cloud Operations: Enhanced Maintenance Controls for Exadata Database Service on Dedicated Infrastructure

Quarterly maintenance on the Exadata Database Service on Dedicated Infrastructure is an Oracle-managed, automated process. The quarterly process applies software updates to the database server hosts, storage servers, and fabric switches. It is important to apply the maintenance updates to ensure the stability, security, and performance of your Oracle Cloud Infrastructure (OCI) by fixing security vulnerabilities and bugs, introducing new features and enhancements, and meeting industry and regulatory standards.

The OCI control plane provides the ability to schedule when and how the maintenance is performed. The Exadata software updates are applied in a rolling manner, node by node, and for the database servers, this includes a graceful shutdown and restart of each VM. Continuous availability for applications using databases hosted on the VMs can be achieved by following the MAA best practices for RAC rolling updates.

In this blog, we will explore and provide a comprehensive understanding of the enhanced infrastructure maintenance controls for Exadata Database Service on Dedicated Infrastructure that provide greater visibility of maintenance actions, timings, and the ability to perform additional actions before the updates on the nodes.

Enhanced Features

1. Non-rolling maintenance: Reduce the maintenance window by performing the updates when all database resources are shutdown. With the non-rolling method, all of the storage servers and database servers are updated at the same time.

2. Custom action: Perform additional tasks, such as run a script to place the application in a specific state or verify database instances or listeners are up and running before maintenance begins on the next database server. You can specify up to 2 hours for a custom action which adds additional time to the maintenance window but provides the flexibility to execute a specific task for your application or database.

3. View maintenance plan: The console provides for greater visibility of the maintenance plan by displaying total estimated maintenance time, database and storage server estimated maintenance time, and the order in which resources are updated.

OCI Console Experience

Let’s look at how you can view and update your maintenance preferences from the OCI Console and manage a running maintenance task.

1. Edit Maintenance Preferences

From the Exadata Cloud Infrastructure details page, click the Edit Maintenance Preferences button.

This will display the Edit Maintenance Preferences panel.

You can choose the maintenance method to be Rolling or Non-rolling. Rolling maintenance updates the servers one by one while continuing to maintain the availability of the underlying RAC databases. Non-rolling maintenance shuts down and updates the servers in parallel. This method minimizes maintenance time but incurs full system and database downtime.

Optionally you can enable a custom action time to allow you to run custom scripts or actions before performing maintenance on the database servers. After clicking the checkbox, enter the time in minutes for the custom action time. The custom action option will wait for that amount of time before starting maintenance on each database server. For maintenance configured with the non-rolling method, the maintenance run will wait up to the configured custom action time before starting maintenance across all database servers.

The Edit Maintenance Preferences panel also provides the ability to configure the preferred maintenance schedule.

2. Edit a scheduled maintenance plan

Once a quarterly infrastructure maintenance plan is scheduled, the date and time will appear next to Next Quarterly Maintenance under the Maintenance heading on the Infrastructure Details page. Click on the View link, next to the date, to view and edit the maintenance.

The Maintenance Details page displays the configured maintenance method, custom action time, total estimated maintenance time, and the target database server and storage server versions, which will be applied by the scheduled maintenance.

If the configured maintenance method is rolling, click the View link next to the Total Estimated Maintenance Time. The Estimated Maintenance Time Details panel shows the order and total estimated maintenance time broken down at a component level of the database and storage servers, and the network switches. Click on Show Details under Number of VMs Impacted to open a panel listing each VM on the database server.

If you need to update the maintenance method, change the custom action time, or reschedule the start time of the maintenance, click the Edit Maintenance Run button.

3. Edit an in-progress maintenance operation

When a quarterly infrastructure maintenance run has started, the Exadata Infrastructure resource and the Next Maintenance will show as "Maintenance in Progress" on the infrastructure details page. Click on the View link next to the Next Quarterly Maintenance field to view and edit the in-progress maintenance.

The Maintenance Details page will display the resource that is currently being updated and the status.

During the database server maintenance, click on the Edit Maintenance Run button to modify the custom action configuration. Any changes will be effective prior to database servers that have not yet been updated.

If the maintenance update is waiting for a custom action time to complete, an Info Block appears providing a button to Resume Maintenance Now, which immediately starts the maintenance on the next database server. If you need to extend the custom action time, click on Extend Custom Action Timeout, which allows extending the current custom action time in 30-minute blocks up to the maximum of 120 minutes.

If the configured maintenance method is rolling, click the View link next to the Total Estimated Maintenance Time. This will display the progress of the maintenance at a component level to reflect the updated estimated maintenance time and the database server status of Scheduled, Maintenance in Progress, or Complete.

You can view the Log Messages to track the progression of the maintenance run. The OCI events service is also available to track the maintenance progress at an individual component level to provide messages for the start and end of each custom action time, each database server, and other components.

Once the maintenance completes, the Exadata Infrastructure returns to an Active state, the version is updated on the Infrastructure Details page, and a record of the maintenance is displayed on the Maintenance History page, accessible from Maintenance details.

Source: oracle.com

Continue reading

How to Restrict Root Access to VMs with Exadata Database Service

Oracle has recently made some slight changes to the permissions required to manage resources with Exadata Database Service. These changes will now allow you to provide more fine-grained access control to various resources in the service. Let’s take a look at what has changed.

There are plenty of blogs and documents that explain how permissions are granted via policies in Oracle Cloud, so we won’t cover that topic in detail here. To sum it up, you assign users to groups, and using policies you assign permissions to those groups enabling users in the group to access resources.

A policy statement takes the form:

Allow <subject> to <verb> <resource type> in <location> where <conditions>

The graphic below provides more details on the policy statement:

While easier to use aggregate resource types, the key to providing fine-grained access to resources is to use individual resource types as opposed to aggregate resource types. You also may want to limit access to a certain group to specific compartments (location) and can restrict the permission even more using the where conditions.

Exadata Database Service has a multi-level parent-child resource hierarchy. At the top level, we have infrastructures, with VM Clusters as children. Databases (CDBs) are children of VM Clusters, and PDBs are children of CDBs. These relationships are important as they help you understand the implications of changes to parent resources on child resources. To MANAGE (ability to perform create/update/delete operations) child resources, we required you have the ability to USE (ability to perform read/update operations) the parent resource. This type of relationship is common for many types of resources both inside and outside Oracle Cloud. For example, you cannot create or delete a file in a file system unless you can read and update the file system. So, as a convenience to users, when you grant MANAGE to a child resource, we automatically grant USE to the parent resource.

While this makes perfect sense for some customers, other who are trying to implement stricter separation of duties find it too generous. For example, they would like to have a group of DBAs have the ability to MANAGE the databases, including creating, patching, and deleting databases, but don’t want those users to have USE access to all the resources of the cluster. Specifically, they do not want those users to have root access to the VMs in the cluster. Granting the DBA group the MANAGE permission on databases also grants the USE permission on VM Clusters, and with those permissions, a customer can inject a key for the opc user and sudo to root.

The solution to granting the necessary permissions to DBAs without giving them root permissions is to qualify the policy statement granting permission with a where clause and narrow the permission context. Review this policy for instance.

Allow group DBAdmins to MANAGE databases in compartment <xyz>

It will implicitly grant USE permissions on VM Clusters, which includes the permissions to INSPECT the VM Cluster (VM_CLUSTER_INSPECT) and to USE the VM Cluster (VM_CLUSTER_UPDATE). VM_CLUSTER_UPDATE enables users to provision new SSH keys for the opc user. Using the where clause, you can choose to give the DBA group only specific permissions omitting VM_CLUSTER_UPDATE, or you can block VM_CLUSTER_UPDATE. The examples below show both alternatives.

Now what has recently changed? As mentioned earlier, the control plane has previously checked for USE permission on the parent when you perform an operation that requires MANAGE on the child. This meant that it checked for VM_CLUSTER_UPDATE when a DBA attempted to manage the database. In other words, you couldn’t exclude the VM_CLUSTER_UPDATE permission and still manage the databases. What’s changed is we have relaxed that check and now only require the user have INSPECT permission on the cluster, and that permission does not enable the user to provision new SSH keys. So, now you are free to write a policy statement for DBAs that will allow them to manage the databases, but not have root access to the VM Cluster.

Source: oracle.com

Continue reading

Autonomous VM Cluster Node Subsetting on Autonomous Database on Exadata Cloud@Customer

I am excited to announce the general availability of Autonomous Exadata VM Cluster (AVMC) Node Subsetting on Autonomous Database on Exadata Cloud@Customer. Node Subsetting compliments the recently released Multiple VM Autonomous Database, bringing even more efficiency for database consolidation while maintaining performance and security isolation for all workloads. With the support for node subsetting, you can select the subset of database server hosts on your Exadata Infrastructure to run each workload. Efficiently sizing your AVMCs gives you the advantage of enabling the creation of more AVMCs on a given Exadata Infrastructure, so more application teams can securely leverage a single dedicated resource without compromising on predictable performance. This makes it even more efficient to setup a consolidated database environment that adheres to typical data governance requirements.

OCI Console Experience

To create an AVMC, navigate to the AVMC home page and click “Create Autonomous Exadata VM Cluster”.

Create AVMC page largely remains the same except for the “Configure Autonomous VM Cluster Resources” section. You will now see a new section that shows your default DB Server selection and allows you to edit the default selection. By default, all the DB Servers with the minimum resources needed to create an AVMC will be selected. Click the “Edit DB Server Selection” button to change the default selection.

On the DB server selection page, deselect the DB Servers on which you do not want to deploy the AVMC and click save. You must select at least two DB Servers as Autonomous Database uses highly available RAC configuration.

Autonomous VM Cluster’s resource configuration section will reflect the change in DB Server selection. VM Count changes based on the number of DB Servers selected. Finally, configure the ACD count, CPU, Memory and Storage resources as needed and hit create.

Once the AVMC is created, you will see a new resource called Autonomous Virtual Machines in the resources section on the AVMC details page. Select the AVM resource to view the list of AVMs, and resources allocated per AVM and identify the DB Servers on which the AVMs are deployed.

Other Considerations

◉ At the time of GA release, you cannot add or remove VMs from the AVMC after the AVMC is created.

◉ All the VMs in the AVMC will be of the same size.

Source: oracle.com

Continue reading

Making Try-Confirm/Cancel Easy with MicroTx

In my last post on MicroTx transaction protocols, I explained how the Oracle Transaction Manager for Microservices (MicroTx) can help applications adopt distributed transactions using Sagas with an eventual consistency protocol defined by the Eclipse MicroProfile Long Running  Actions.  In this post I’ll focus on how microservice based applications can use the Try-Confirm/Cancel (TCC) protocol to also implement Sagas.

The Try-Confirm/Cancel protocol is a simple protocol that has an initiator ask other microservices to reserve resources or place them in escrow.  Once the initiator and all participants have acquired the required reservations, the initiator then asks a transaction coordinator to confirm all those reservations.  Should the initiator decide it doesn’t want or can’t use the reservations made, it asks a transaction coordinator to cancel all the reservations.  What constitutes a reservation is completely up to the application, however the application is expected to do certain things.

Reservations are made using an HTTP POST request that is expected to return a URI representing the reservation.  The MicroTx client libraries ensure this URI is propagated up the call stack by placing the information in MicroTx specific headers.  The URIs are expected to respond to HTTP PUT requests to confirm the reservation, and HTTP DELETE requests to cancel the reservation.

The basic flow is as follows:

1. Transaction initiator starts the TCC transaction by making a MicroTx client library call

2. Transaction initiator then calls participant 1

3. Participant 1 makes the required reservation and returns the URI representing its reservation

4. Transaction initiator then calls participant 2

5. Participant 2 makes the required reservation and returns the URI representing its reservation

6. Initiator calls the transaction coordinator with the list of reservations to Confirm or Cancel the reservations

7. The transaction coordinator then calls PUT to confirm or DELETE to cancel on all the URIs (reservations) to complete the transaction

Try Phase

During the try phase, all accepted reservations are collected in headers by the MicroTx library.  This includes reservations made indirectly by microservices called by the initiator.  By the time the initiator (in the case above, Microservice A) has completed making reservations with Microservice B and Microservice C above, the MicroTx library has collected all the reservations in headers.  At this point the initiator can decide to Confirm the reservations, Cancel the reservations, or ignore the reservations letting timeouts eventually cancel the reservations.

Confirm/Cancel Phase

The initiator then decides to either Confirm all the reservations or Cancel all the reservations.  How a reservation is represented is completely up to the application.  Let’s look a simple microservice that allows reserving and purchasing a seat for a performance.  Seats would have a state which could either be AVAILABLE, RESERVED, or SOLD.  The try phase would have changed the state of the seat to RESERVED from AVAILABLE.  The Confirm phase would change the state from RESERVED to SOLD, assuming payment was successfully made.  The Cancel phase would change the state from RESERVED to AVAILABLE.  To prevent failure of the Confirm step due to inability to complete a payment, during the Try phase, the microservice should obtain payment authorization to ensure the payment can be made.

Another example might be to reserve a certain quantity of something such as items in inventory, or funds from an account.  In this case during the Try phase the application might deduct the reserved quantity from the available quantity and add a record of the reservation to the database.  During the Confirm phase, the reservation record would simply be deleted.  During the Cancel phase, the amount in the reservation record would be added back into the total inventory and the reservation record deleted.

Similarity to Eclipse MicroProfile Long Running Actions (LRA)

In many ways TCC is very similar to LRA although far simpler.  The Try phase is much like the initial LRA methods that enlist themselves in the LRA.  The Confirm phase is essentially the Complete phase in LRA, while the Cancel phase is much like the Compensate phase.  The semantics of Try, Confirm, and Cancel are completely up to the application. LRA is much more general in that the initial LRA methods are basically free to do anything and return anything and aren’t necessarily limited to using a reservation model.  As well LRA participants can start a nested LRA and get notified of the outcome of the transaction, things not possible with TCC.

Why Use TCC

TCC fits very well for microservices that need to place something in reserve using a very simple model.  All that’s required of a microservice using TCC is to:

1. add a call to the MicroTx client library to indicate the URI representing the reserved resource

2. optionally, although strongly recommended, specify a timeout for the reservation

3. respond to PUT requests on the URI to confirm the reservation and DELETE requests on the URI to cancel the reservation.

Avoiding Dirty Reads

One of the major advantages of TCC over LRA is that LRAs give up isolation allowing potentially dirty reads, while TCC doesn’t suffer from potential dirty reads.  In effect, with TCC the state of the microservices involved is always consistent.

Avoiding Lock Contention

Another reason to use TCC is to avoid locks that are held for the entire duration of an XA distributed transaction.  Lock contention can limit the throughput and increase the latency of applications using XA if attention isn’t paid to avoiding hotspots in the involved XA resources.  TCC potentially allows more concurrency than XA may be able to provide as TCC only uses local transactions for the duration of the microservice.

Reasons to Avoid Using TCC Protocol

As with virtually all distributed transaction protocols, there is the possibility of heuristic outcomes.  These are outcomes where only some of the updates performed during the transaction get committed, leading to inconsistencies.  How costly these inconsistencies are to an application is very application dependent.  If the cost is high, you’ll want to choose a protocol and application logic that minimizes the likelihood of a heuristic outcome.

Avoiding Heuristic Outcomes

In XA, the purpose of the prepare phase is to avoid heuristic outcomes.  When a resource manager in an XA transaction indicates it has successfully prepared, it is indicating it will be able to commit the transaction barring some catastrophic failure.  TCC and LRA don’t have this rigid requirement, so it is up to the microservice to ensure it can successfully Confirm/Complete or Cancel/Compensate its participation when asked.

Timeouts are another source of heuristic outcomes.  In TCC, typically each reservation has a time limit associated with it.  When that time limit is reached, the microservice can unilaterally cancel its reservation.  If that happen during the Confirm phase of a TCC transaction, that microservice will be unable to Confirm the transaction while other microservices in the transaction successfully Confirm, yielding a heuristic outcome.

Source: oracle.com

Continue reading

Navigating the Oracle 1Z0-062 Exam: Common Questions and Tips for Success

The Oracle Database 12c - Administration exam, also known as the 1Z0-062 exam, is a challenging test that requires a thorough understanding of database administration concepts and practices. This article will answer some common questions about the exam and provide tips for success.

What is the Oracle 1Z0-062 Exam?

The Oracle 1Z0-062 exam is an Oracle certification exam that tests your knowledge of database administration for Oracle Database 12c. Passing the 1Z0-062 exam is a significant achievement and is recognized by many companies as evidence of a candidate's expertise in database administration.

The exam consists of 67 multiple-choice questions and has a time limit of 120 minutes. The passing score for the exam is 64%, and the exam fee varies by location.

What are some Tips for Success on the Oracle 1Z0-062 Exam?

To pass the Oracle 1Z0-062 exam, you must understand database administration concepts and practices. Here are some tips to help you prepare for the exam:

Study the Exam Content

The exam content for the 1Z0-062 exam is available on the Oracle website. Study the content carefully and ensure that you have a thorough understanding of the topics covered.

The exam covers a wide range of topics, including:

Use Study Materials

Use study materials such as textbooks, online courses, and practice exams to reinforce your understanding of the exam content. Choose materials that are up-to-date and relevant to the exam.

There are many study materials available for the 1Z0-062 Oracle Database 12c - Administration exam. These materials can help you build a solid foundation of knowledge and develop the skills you need to pass the exam.

Practice exams are also an excellent resource for preparing for the exam. They allow you to familiarize yourself with the exam format and identify areas where you need to focus your studies.

Practice with Oracle Database

Practical experience with Oracle Database is essential to passing the exam. Set up a database on your computer and practice performing administrative tasks such as creating users, backing up data, and managing performance.

Hands-on experience with the database will help you understand how the concepts you've learned apply in a real-world setting. It will also help you develop the problem-solving skills you need to succeed on the exam.

Take Practice Exams

Practice exams can help you get a feel for the exam format and identify areas where you need to focus your studies. It's essential to practice taking the exam under timed conditions. Set a timer for 120 minutes (the exam's duration) and take the practice test under similar conditions.

By taking the practice test under timed conditions, you will also get used to the pressure of working within the time constraints, which can help reduce anxiety during the actual exam. Ensure that the practice exams you choose are up-to-date and relevant to the 1Z0-062 exam.

Join Study Groups

Joining study groups can provide a collaborative and supportive learning environment where you can exchange knowledge and ideas with other exam takers. You can join study groups online or in person.

Study groups can help you stay motivated and accountable and provide valuable insights and strategies for passing the exam.

What are the Benefits of Passing the Oracle 1Z0-062 Exam?

Passing the 1Z0-062 exam demonstrates your knowledge and skills in database administration for Oracle Database 12c and can open up new career opportunities. Here are some benefits of passing the exam:

Enhanced Career Opportunities

Oracle certification is highly valued in the IT industry, and passing the Oracle 1Z0-062 exam can open up new career opportunities. It demonstrates to potential employers that you have the knowledge and skills to manage and administer Oracle Database 12c, which can lead to higher-paying jobs and career advancement.

Increased Knowledge and Skills

Preparing for the 1Z0-062 exam requires significant study and hands-on experience with Oracle Database 12c. By passing the exam, you'll have a deeper understanding of database administration concepts and practices, which can help you become a more valuable asset to your organization.

Improved Credibility

Oracle certification is recognized and respected throughout the IT industry, and passing the 1Z0-062 exam can improve your credibility as a database administrator. It demonstrates to your peers and colleagues that you have the skills and knowledge to manage and administer Oracle Database 12c.

Frequently Asked Questions about the 1Z0-062 Exam

Q1: How long is the 1Z0-062 exam?

The 1Z0-062 exam is 120 minutes long.

Q2: How many questions are on the exam?

The exam consists of 67 multiple-choice questions.

Q3: What is the passing score for the exam?

The passing score for the 1Z0-062 exam is 64%.

Q4: How much does the exam cost?

The exam fee varies by location. Check the Oracle website for pricing information in your area.

Q5: How often can I retake the exam if I don't pass?

Read the policy on exam retakes on the official site.

Conclusion

The 1Z0-062 exam is a challenging test that requires a thorough understanding of database administration concepts and practices. By studying the exam content, using study materials, practicing with Oracle Database, taking practice exams, and joining study groups, you can prepare yourself for success on the exam.

Passing the 1Z0-062 exam can open up new career opportunities, enhance your knowledge and skills, and improve your credibility as a database administrator. So, start preparing for the exam today and take your career to the next level.

Continue reading

Announcing third-party Python packages for use for Graph Studio on Autonomous Database

Announcing third-party Python packages for use for Graph Studio on Autonomous Database

We are pleased to announce the ability to use custom third-party packages on Graph Studio. Users of Oracle Graph Studio can now use custom-installed third-party packages through Conda environments. Oracle Graph Studio is an environment built into Autonomous Database that allows you easily model, query and modify a graphical representation of your data. Conda is an open-source package management system and environment management system that was originally created for Python programs but can package and distribute software for any language. Oracle Graph Studio now has a Conda interpreter that allow to easily create and distribute Conda environments. As a part of this interpreter, you can now install python libraries that are available through Conda.

Creating and Using Conda Environments

Graph Studio Notebooks introduces a conda interpreter that enables a user with administrator privileges to install third-party Python packages in a conda environment for use within Graph Studio sessions. Once an environment is created and packages are installed, the admin user can upload the conda environment to Object Storage, so that it can easily be accessed by non-administrator users.

Conda is an open-source package and environment management system that enables the use of virtual environments containing third-party Python packages. With conda environments, you can install and update packages and their dependencies, as well as switch between environments.

 

Getting Started

Create and upload Conda Environments

Check out the “Graph Studio-Conda – Admin” example notebook, which walks you through a typical workflow for third-party environment creation, package installation, and environment upload. Learn about common commands used when creating conda environments, and how to install packages and upload conda environments to an Object Storage bucket associated with the Autonomous Database instance.

Download and Activate Conda Environment within a Notebook

Check out the “Graph Studio-Conda – Graph User” example notebook, in which, the user downloads and activates the environment and then can use the installed packages in their notebook session.  In these notebooks, we demonstrate a simple workflow for third-party environment usage in Graph Studio Notebooks using Python and PGQL.

Use Third Party Functionality in Notebook

With the conda environment activated, users can invoke package functionality in the notebook paragraphs. In the first example, we use the Python pandas package's describe function to show statistics of a PGQL query that has been converted to a pandas data frame. In the second example, we use the matplot package to create a bar chart of PageRank values by account ID. These examples leverage Oracle Graph to apply the PageRank algorithm to the dataset, and run a query from the graph, and then use the third-party packages to gain deeper insights.

: 

Source: oracle.com

Continue reading