The Migration Strategy Board helps organizations develop a data center or cloud migration plan. Designed like an interactive game board, it visualizes the five major phases of a data center and cloud migration project.

It includes objectives, deliverables, tools, and additional tips for migrating assets, infrastructure, and services. A methodology specific to migrations helps ensure operational stability, business continuity, and savings.

White Paper

The Cloud and Data Center Migration Methodology

Discover the cloud and data center migration methodology behind the Migration Strategy Board. It is a proven process that migrates physical assets and apps with zero operational disruption. Get insight for your hybrid IT transformation and reduce IT costs. 

BY: FRANK

As the practice of DevOps evolves, so do the supporting tasks; hopefully in such a way that they introduce increased efficiency and automation to accelerate development and deployment pipelines. However, one specific process still remains a speed bump on the road to DevOps acceleration: the process—or, more specifically, the chore—of testing.

Naturally, testing is an undeniably important component of quality assurance. However, introducing efficiency into a process that dictates quality assurance can accelerate development and improve outcomes, especially when it comes to application testing.

“Application testing should never be done in a vacuum, or, worse, a silo,” said Sara Faatz director, developer relations at Progress Software. “The DevOps process can benefit from accelerating the testing process, introducing automation and embracing teamwork.”

Faatz makes some valid points; historically, application testing was treated as either a standalone or separate process, and often was performed by non-programmers following some type of script. “We discovered early on that creating synergy between testers and developers was an important concept for accelerating development, while fostering teamwork,” said Ramiro Millan, director, product development, Test Studio. “Addressing the trifecta of acceleration, automation and teamwork challenges actually requires adopting a different mindset when it comes to testing, especially when it comes to automation and communication.”

However, solving those problems requires adopting different procedures, as well as deploying tools to streamline processes and introduce automation. That said, there are ancillary challenges that also have to be addressed. For example, there is often a disconnect between the cultures of QA teams and development teams. Here, QA teams need to overhaul their processes and introduce more agile practices. In other words, the time is now to identify new practices and methods that allow QA teams to be creative and innovative while helping to test the software created by DevOps.

“Automation is becoming hyper-critical for testing. However, it is not just automation alone, but also the ability to run tests in the background and not hijack control of the console or the machine,” Millan said. “Automation should also bring with it the ability to concurrently run multiple tests in the background, which, in turn, accelerates the testing processes.”

That makes a great deal of sense. In many DevOps shops, QA has become a speed bump in the CI/CD pipeline, meaning that developers often have to wait for testing processes to complete before they can deploy anything. What’s more, developers are often disconnected from the status of testing.

“Communication between developers and testers is taking on renewed importance. Using tools that can hand off statuses between teams, while also enabling different members to participate in the processes, proves to accelerate execution times,” Faatz said. “The ultimate goal here is to bring forth faster delivery, less maintenance and more stability. I think stability is a big part of the equation. If we can automate those day-to-day, repetitive tasks, we garner that additional stability.”

Although testing is a broad subject, many of the lessons offered can have a beneficial impact on the overall process. Currently, many vendors are focused on subsets of the testing process, such as headless browser testing, PDF validation, UI/UX testing, backend integration and so on. This can be an indicator of just how complex the QA process can become if unified tools and automation are not introduced into the process.

“The trick, here, is to pick a tool that does not replace peoples’ processes, but transforms manual QA processes into something that can leverage automation,” Millan said. “Automation brings about consistency, and consistency brings forth improved results.”

The lessons learned indicate that testing must evolve to keep up with the DevOps model, and also suggest that DevOps is pushing QA teams to adopt new methods of testing and interaction. The only remaining question is how quickly QA can better integrate into DevOps, and eliminate the deployment speed bumps.

An incident management process is a set of procedures and actions taken to respond to and resolve critical incidents: how incidents are detected and communicated, who is responsible, what tools are used, and what steps are taken to resolve the incident.

Incident management processes are used across many industries, and incidents can include anything from IT system failure, to events requiring the attention of healthcare professionals, to critical maintenance of physical infrastructure.

In this article, you will learn:

• Why Is Incident Management Important?
• What Is an Incident Management Process?
• The Five Steps of Incident Resolution

1. Incident Identification, Logging, and Categorization
2. Incident Notification & Escalation
3. Investigation and Diagnosis
4. Resolution and Recovery
5. Incident Closure

• Tips for Improving Your Incident Management Process
• Train and Support Employees
• Set Alerts That Matter
• Prepare Your Team for On-Call
• Establishing Communication Guidelines
• Streamline Change Processes
• Improve Systems with Lessons Learned
• How to Use Alerting to Improve Your Incident Management Process
• Define Your Monitoring and Alerting Strategy
• Go Beyond Ticketing Systems
• Create a Minimal Runbook

Why Is Incident Management Important?

Incident management refers to a set of practices, processes, and solutions that enable teams to detect, investigate, and respond to incidents. It is a critical element for businesses of all sizes and a requirement for meeting most data compliance standards.

Incident management processes ensure that IT teams can quickly address vulnerabilities and issues. Faster responses help reduce the overall impact of incidents, mitigate damages, and ensure that systems and services continue to operate as planned.

Without incident management, you may lose valuable data, experience reduced productivity and revenues due to downtime, or be held liable for breach of service level agreements (SLAs). Even when incidents are minor with no lasting harm, IT teams must devote valuable time to investigating and correcting issues.

A few of the most important benefits of implementing an incident management strategy include:

• Prevention of incidents
• Improved mean time to resolution (MTTR)
• Reduction or elimination of downtime
• Increased data fidelity
• Improved customer experience

Another benefit of incident management practices is an overall reduction in costs. According to a study by Gartner, system or service downtime can cost organizations $300k per hour. Additionally, regulatory fines and loss of customer trust can have significant financial impacts. With incident management, organizations may have to invest more upfront but they can avoid significant costs later on.

What Is an Incident Management Process?

Incident management processes are the procedures and actions taken to respond to and resolve incidents. This includes who is responsible for response, how incidents are detected and communicated to IT teams, and what tools are used.

When designed well, incident management processes ensure that all incidents are addressed quickly and that a certain quality standard is maintained. Processes can also help teams improve their current operations to prevent future incidents.

The Five Steps of Incident Resolution

There are five standard steps to any incident resolution process. These steps ensure that no aspect of an incident is overlooked and help teams respond to incidents effectively.

1. Incident Identification, Logging, and Categorization

Incidents are identified through user reports, solution analyses, or manual identification. Once identified, the incident is logged and investigation and categorization can begin. Categorization is important to determining how incidents should be handled and for prioritizing response resources.

2. Incident Notification & Escalation

Incident alerting takes place in this step although the timing may vary according to how incidents are identified or categorized. Additionally, if incidents are minor, details may be logged or notifications sent without an official alert. Escalation is based on the categorization assigned to an incident and who is responsible for response procedures. If incidents can be automatically managed, escalation can occur transparently.

3. Investigation and Diagnosis

Once incident tasks are assigned, staff can begin investigating the type, cause, and possible solutions for an incident. After an incident is diagnosed, you can determine the appropriate remediation steps. This includes notifying any relevant staff, customers, or authorities about the incident and any expected disruption of services.

4. Resolution and Recovery

Resolution and recovery involve eliminating threats or root causes of issues and restoring systems to full functioning. Depending on incident type or severity, this may require multiple stages to ensure that incidents don’t reoccur.

For example, if the incident involves a malware infection, you often cannot simply delete the malicious files and continue operations. Instead, you need to create a clean copy of your infected systems, isolate the infected components, and fully replace systems to ensure that the infection doesn’t spread.

5. Incident Closure

Closing incidents typically involves finalizing documentation and evaluating the steps taken during response. This evaluation helps teams identify areas of improvement and proactive measures that can help prevent future incidents.

Incident closure may also involve providing a report or retrospective to administrative teams, board members, or customers. This information can help rebuild any trust that may have been lost and creates transparency regarding your operations.

Tips for Improving Your Incident Management Process

When defining your incident management processes, the following tips can help you ensure that your processes are effective. These tips can also help ensure that your team is able to adopt processes reliably.

Train and Support Employees 

Properly training employees at all levels of your organization can significantly benefit incident management processes. When non-IT staff are aware of how to identify and report incidents, your IT teams can respond faster and need to spend less time interpreting reports. When IT staff are properly trained, they are more effective at working together and can use tools more efficiently.

Set Alerts That Matter

Avoiding alert overload is one of the most important aspects of incident management. If your teams are drowning in alerts, incidents are likely to be overlooked and response times are longer. To avoid this, you should carefully plan how events are categorized and what those categories mean for alerts.

When defining incident alerts you may find it helpful to start by defining your service level indicators. You can use these indicators to determine a hierarchy of functioning that prioritizes root causes over surface-level symptoms. An alert informing teams that a server went down is more useful and effective than 30 alerts, one for each service on that server.

Prepare Your Team for On-Call

With alert priorities determined, you also need to account for who is responding to those alerts. Defining an on-call schedule helps you ensure that a responder with the appropriate skills and permissions is always available. On-call procedures can also help you ensure that alerts are properly escalated.

After each shift, consider adjusting on-call duties according to the amount of effort that individual staff made. This can ensure your team members aren’t getting overwhelmed. For example, if one team member responds to multiple high-priority incidents in a shift, they should get more time off-call than someone who didn’t have to respond.

Establishing Communication Guidelines

Establishing effective communication is critical to team collaboration and effectiveness. One way to protect and ensure communication is to create guidelines. These guidelines can specify what channels staff should use, what content is expected in those channels, and how communications should be documented.

Clear guidelines can help diffuse tension and blame during stressful response periods by presenting a standard for how employees are expected to interact. Additionally, when communications are documented, teams can refer back to verify content and more easily pass on information without losing detail. This can reduce frustration overall, including the chance of misdirected stress.

Streamline Change Processes

Depending on the systems you are using and your responders’ expertise, you may need to verify or confirm changes required for response. You want to prevent responders from enacting harmful changes or from getting stuck waiting for unnecessary approval.

One option is to clearly identify what levels or types of changes individual staff can make and who they can go to for approval when needed.

If your system requires all changes to be approved by a change advisory board (CAB) you need to ensure that the board is readily available. If board members cannot give the same availability as your responders, you need to put emergency override procedures in place to prevent excess damage.

Improve Systems With Lessons Learned

Reviews should evaluate the reason for the incident and work to identify if any preventative measures can be taken against future incidents. If so, teams need to define and assign tasks to take those measures immediately. Additionally, reviews can help ensure that any remaining incident documentation is completed. This is necessary for liability and compliance auditing.

How to Use Alerting to Improve Your Incident Management Process

The quality of your incident management processes rely heavily on how you generate and manage alerts. If you do not have strong alerting practices or systems in place, your incident management is bound to be disorganized and slow. To avoid poor management and ensure high quality processes, keep the following tips in mind.

Define Your Monitoring and Alerting Strategy

Monitoring and alerting strategies define which system components you are monitoring, the importance of those components, and how issues with those components are conveyed. Your monitoring goal should be to create centralized, continuous visibility of your systems. Your alert goals should be to reduce false positives or negatives, and to ensure that alerts are meaningful.

When creating your strategies, it helps to start small and with the most critical components of your systems. Eventually you should be monitoring environments in their entirety but you need to ensure system stability before you can do this. If you focus on the most important components first, you ensure that systems remain operational and grant yourself time for optimizations.

Go Beyond Ticketing Systems

Ticketing systems can be useful for tracking issues and providing customer support but are often not the best tool for incident management. These systems typically require information to be manually filed before tasks can be addressed and can significantly slow response times.

This manual requirement is especially problematic for customer-facing systems, where users may simply abandon your service rather than reporting an issue. If you integrate your monitoring and response tools you can work to avoid this abandonment.

If you need to use a ticketing system, you should automate as much of the ticket creation process as possible to reduce delays. Otherwise, consider adopting tools that enable your teams to communicate about, investigate, and respond to alerts from a single platform. Even if tools can’t perform these capabilities inherently, there are options for integrations that automate the transfer of information or are able to trigger actions across tooling.

Create a Minimal Runbook

Runbooks are essentially collections of scripts or procedures that you can use to automate or outline processes. With runbooks you can standardize processes and create a shared knowledge base of actions for your team. Once runbooks are defined, you can assign books directly to alert details or specific events.

Alternatively, you can provide a library of runbooks to your responders with guidelines for when they should use specific books. This enables you to distribute skills and expertise across your response tiers, ensuring that even lower-level staff can perform required response actions with ease.

One caveat of runbooks is that the information contained can be time consuming to maintain. Detailed books need to be verified and updated with every system change to prevent books from becoming outdated or harmful. Creating minimal runbooks is one way to avoid this maintenance. With these guides, you can still share basic information across your team with minimal maintenance.

Presplay: Agile, Rock-Solid Incident Alert Management 

Presplay Cloud is a SaaS-based incident alert management system that can be easily integrated into incident management tools and hosted in secure, SSAE-16 compliant hosting facilities across the U.S. It provides instant visibility and feedback on incident status, tracks alert delivery and ticket status, and offers solid reliability, ensuring critical incidents are captured and addressed by the relevant teams.

Presplay’s incident management features include:

• Automation of alerts—users can set their own escalation policy and alert the next person on the on-call list if the first person does not respond in a timely manner
• Real-time reporting—captures real-time stats on individual and group workloads based on each responders’ alert volume and escalation order
• Alerting across platforms—enables notifications via email, SMS, mobile push and phone calls
• Mobile incident management—gives incident responders full visibility into the incident and have quick, easy ways to respond so they can take quick action
• Priority alerting—allows the user to send messages in two different formats: High- priority and low-priority, with a unique ringtone and persistent alerts to ensure critical messages are not ignored
• Open API and out-of-the-box integrations—provides a publicly-available API, offering programmatic access to the software so organizations can integrate it with their existing solutions
• Secure, real-time collaboration—built-in two-way messaging which supports attachments and predefined responses, and complies with relevant standards
• Digital scheduler—automated management of on-call schedules, recurring on-call rotations and shifts, automating alerts according to staff schedules and rotations

Raymond Kurzweil, a futurist and author of The Singularity is Near, the growth of progress is exponential. I.e. we’ll see 20,000 years of progress in the 21st century rather than 100 years of progress. Kurzweil also suggests that by the year 2020, the growth of integrated circuits will slow, and “another paradigm” will replace that and carry the exponential growth.

Until the Singularity actually happens and data moves itself across systems, we’re stuck migrating data any time we want to move to a new server or software platform. Businesses in every industry amass vast amounts of data about their customers, employees, products, digital properties, and finances. Eventually, as systems become outdated, we need to move the usable and business-critical information from one system to another. Continually changing data storage means we need to start building concrete plans for validating, moving, and testing data.

Before You Migrate: Plan

Understand both the source and the target, meaning where the data comes from and where it’s going. For example: you’re porting ledgers and financial data from a desktop accounting system into QuickBooks Online. Once you understand the source and the target, you can start to map out your process. Understanding the IT environment where the migration will take place can help you make decisions about the speed and scope of work, as well as minimize inconvenience.

Plan the migration project according to your business objectives. It’s exciting to pick out new software and start learning a new system, but if the software doesn’t support business objectives and the migration doesn’t move forward with a minimal process disruption, the results can be disastrous. Try to include a stakeholder from every relevant team during the planning stage. Even straightforward internal migrations can fail due to business restrictions, security policies, or other problems that might not be immediately visible to insular employees.

Try to include a stakeholder from every relevant team during the planning stage.

You should also watch out for known risks during the migration process. Often the data profiles and form structures in the old and new systems don’t perfectly match, which means data is liable to duplication or distortion during the transformation process. If your testing process fails to accurately translate real data, you may need to make some adjustments to your API configuration, or call the vendor for support.

As with any project, you’ll want to consider migration costs as part of the investment you’ll make in a new software tool. Oracle suggests that you factor the costs of any data migration into your investment calculations, rather than tacking it onto your overall costs as an afterthought. Depending on the complexity of the move, the cost and labor of the migration itself could make a new piece of technology prohibitively expensive, and ignoring the migration costs can set your team up for failure.

Plan Again—in Detail This Time

Most migrations take place through five major stages:

• Extraction: remove data from the current system to begin working on it.
• Transformation: match data to its new forms, ensure that metadata reflects the data in each field.
• Cleansing: de-duplicate, run tests, and address any corrupted data.
• Validation: test and re-test that moving the data to the target location provides the expected response.
• Loading: transfer data into the new system, and review for errors again.

During this time you’ll want to actually build your plan in a project management or task management software. Your plan should include burndown charts, task assignments, and dependency charts so all involved know their responsibilities and when each task is scheduled to take place. Take the time to do test runs and involve the entire team again to address as many unknowns as possible before the actual migration takes place.

Move the Data

Time to put your plan into action. Some teams migrate data on weekends or bank holidays to reduce disruption to business objectives, but this “big bang” migration has many problems of its own and can leave your IT team scrambling to clean up a botched attempt before everyone gets back to work. Others decide to run the old and new system concurrently and transfer data piecemeal. A parallel migration can extend the process, but also gives teams a chance to react to unforeseen difficulties.

Build a Repeatable Process

As new platforms continue to hit the market and businesses move faster every day, data migration will become a near-constant process in IT. Once you complete your first data migration, your team can run a full audit of the process to better understand strengths, weaknesses, and mistakes. Document everything in your project management software, and set up a clear, repeatable plan for the future.

If you’re approaching a data migration but still shopping for the next software platform, you can use our Product Selection Tool to compare options and get a custom recommendation based on your needs.

When Is Tuning Most Effective?

For best results its recommended you tune during the design phase, rather than waiting to tune after implementing your system. This is illustrated in the following sections:

• Proactive Tuning While Designing and Developing Systems
• Reactive Tuning to Improve Production Systems

Proactive Tuning While Designing and Developing Systems

By far, the most effective approach to tuning is the proactive approach. Begin by following the steps described in this chapter under “Prioritized Tuning Steps”.
Business executives should work with application designers to establish performance goals and set realistic performance expectations. During design and development, the application designers can then determine which combination of system resources and Oracle features best meet these needs.

By designing a system to perform well, you can minimize its implementation and on-going administration cost.Figure 1-1 illustrates the relative cost of tuning during the life of an application.

Figure 1-1 Cost of Tuning During the Life of an Application

To complement this view, Figure 2-2 shows that the relative benefit of tuning an application over the course of its life is inversely proportional to the cost expended.

Figure 2-2 Benefit of Tuning During the Life of an Application

The most effective time to tune is during the design phase: you get the maximum benefit for the lowest cost.

Reactive Tuning to Improve Production Systems

The tuning process does not begin when users complain about poor response time. When response time is this poor, it is usually too late to implement some of the most effective tuning strategies. At that point, if you are unwilling to completely redesign the application, then you may only improve performance marginally by reallocating memory and tuning I/O.

For example: There is a bank that employs one teller and one manager. It has a business rule that the manager must approve withdrawals over $20. You find a long line of customers, and you decide that you need more tellers. You add 10 more tellers, but then you find that the bottleneck moves to the manager’s function. However, the bank determines that it is too expensive to hire additional managers. In this example, regardless of how carefully you tune the system using the existing business rule, getting better performance will be very expensive.

Alternatively, a change to the business rule may be necessary to make the system more scalable. If you change the rule so that the manager only needs to approve withdrawals exceeding $150, then you have created a scalable solution. In this situation, effective tuning could only be done at the highest design level, rather than at the end of the process.

It is possible to re-actively tune an existing production system. To take this approach, start at the bottom of the method and work your way up, finding and fixing any bottlenecks. A common goal is to make Oracle run faster on the given platform. You may find, however, that both the Oracle server and the operating system are working well. To get additional performance gains, you may need to tune the application or add resources. Only then can you take full advantage of the many features Oracle provides that can greatly improve performance when properly used in a well-designed system.

Even the performance of well-designed systems can degrade with use. Ongoing tuning is, therefore, an important part of proper system maintenance.

Prioritized Tuning Steps

The following steps provide a recommended method for tuning an Oracle database. These steps are prioritized in order of diminishing returns: steps with the greatest effect on performance appear first. For optimal results, therefore, resolve tuning issues in the order listed, from the design and development phases through instance tuning.

Step 1: Tune the Business Rules

Step 2: Tune the Data Design

Step 3: Tune the Application Design

Step 4: Tune the Logical Structure of the Database

Step 5: Tune Database Operations

Step 6: Tune the Access Paths

Step 7: Tune Memory Allocation

Step 8: Tune I/O and Physical Structure

Step 9: Tune Resource Contention

Step 10: Tune the Underlying Platform(s)

After completing these steps, reassess your database performance, and decide whether further tuning is necessary.

Tuning is an iterative process. Performance gains made in later steps may pave the way for further improvements in earlier steps, so additional passes through the tuning process may be useful.

Figure 2-3 illustrates the tuning method:

Figure 2-3 The Tuning Method

Decisions you make in one step may influence subsequent steps. For example, in step 5 you may rewrite some of your SQL statements. These SQL statements may have significant bearing on parsing and caching issues addressed in step 7. Also, disk I/O, which is tuned in step 8, depends on the size of the buffer cache, which is tuned in step 7. Although the figure shows a loop back to step 1, you may need to return from any step to any previous step.

Step 1: Tune the Business Rules

For optimal performance, you may need to adapt business rules. These concern the high-level analysis and design of an entire system. Configuration issues are considered at this level, such as whether to use a multi-threaded server system-wide. In this way, the planners ensure that the performance requirements of the system correspond directly to concrete business needs.

Performance problems encountered by DBAs may actually be caused by problems in design and implementation, or by inappropriate business rules. Designers sometimes provide far greater detail than is needed when they write business functions for an application. They document an implementation, rather than simply the function that must be performed. If business executives effectively distill business functions or requirements from the implementation, then designers have more freedom when selecting an appropriate implementation.

Consider the business function of printing checks. The actual requirement is to pay money to people, not necessarily to print pieces of paper. Whereas it would be very difficult to print a million checks per day, it would be relatively easy to record that many direct deposit payments on a tape that could be sent to the bank for processing.

Business rules should be consistent with realistic expectations for the number of concurrent users, the transaction response time, and the number of records stored online that the system can support. For example, it does not make sense to run a highly interactive application over slow, wide area network lines.

Similarly, a company soliciting users for an Internet service might advertise 10 free hours per month for all new subscribers. If 50,000 users per day signed up for this service, then the demand far exceeds the capacity for a client/server configuration. The company should instead consider using a multi-tier configuration. In addition, the signup process must be simple: it should require only one connection from the user to the database, or connection to multiple databases without dedicated connections, using a multi-threaded server or transaction monitor approach.

Step 2: Tune the Data Design

In the data design phase, you must determine what data is needed by your applications. You must consider what relations are important, and what their attributes are. Finally, you need to structure the information to best meet performance goals.

The database design process generally undergoes a normalization stage when data is analyzed to eliminate data redundancy. With the exception of primary keys, any one data element should be stored only once in your database. After the data is normalized, however, you may need to denormalize it for performance reasons. You might decide that the database should retain frequently used summary values. For example, rather than forcing an application to recalculate the total price of all the lines in a given order each time it is accessed, you might decide to always maintain a number representing the total value for each order in the database. You could set up primary key and foreign key indexes to access this information quickly.

Another data design consideration is avoiding data contention. Consider a database 1 terabyte in size on which one thousand users access only 0.5% of the data. This “hot spot” in the data could cause performance problems.

In a multiple-instance setup, try to localize access to the data down to the partition level, process, and instance levels. That is, localize access to data, such that any process requiring data within a particular set of values is confined to a particular instance. Contention begins when several remote processes simultaneously attempt to access one particular set of data.

In Oracle Parallel Server, look for synchronization points–any point in time, or part of an application that must run sequentially, one process at a time. The requirement of having sequential order numbers, for example, is a synchronization point that results from poor design.

Also consider implementing two Oracle8i features that can help avoid contention:

• Consider partitioning your data.
• Consider using local or global indexes.

Step 3: Tune the Application Design

Business executives and application designers should translate business goals into an effective system design. Business processes concern a particular application within a system, or a particular part of an application.

An example of intelligent process design is strategically caching data. For example, in a retail application, you can select the tax rate once at the beginning of each day, and cache it within the application. In this way, you avoid retrieving the same information over and over during the day.

At this level, you can also consider the configuration of individual processes. For example, some PC users may access the central system using mobile agents, where other users may be directly connected. Although they are running on the same system, the architecture for each type of user is different. They may also require different mail servers and different versions of the application.

Step 4: Tune the Logical Structure of the Database

After the application and the system have been designed, you can plan the logical structure of the database. This primarily concerns fine-tuning the index design to ensure that the data is neither over- nor under-indexed. In the data design stage (Step 2), you determine the primary and foreign key indexes. In the logical structure design stage, you may create additional indexes to support the application.

Performance problems due to contention often involve inserts into the same block or incorrect use of sequence numbers. Use particular care in the design, use, and location of indexes, as well as in using the sequence generator and clusters.

Step 5: Tune Database Operations

Before tuning the Oracle server, be certain that your application is taking full advantage of the SQL language and the Oracle features designed to enhance application processing. Use features and techniques such as the following, based on the needs of your application:

• Array processing
• The Oracle optimizer
• The row-level lock manager
• PL/SQL

Understanding Oracle’s query processing mechanisms is also important for writing effective SQL statements.

Whether you are writing new SQL statements or tuning problematic statements in an existing application, your methodology for tuning database operations essentially concerns CPU and disk I/O resources.

• Step 1: Find the Statements that Consume the Most Resources
• Step 2: Tune These Statements To Use Fewer Resources

Step 1: Find the Statements that Consume the Most Resources

Focus your tuning efforts on statements where the benefit of tuning demonstrably exceeds the cost of tuning. Use tools such as TKPROF, the SQL trace facility, SQL Analyze, Oracle Trace, and the Enterprise Manager Tuning Pack to find the problem statements and stored procedures. Alternatively, you can query the V$SORT_USAGE view to see the session and SQL statement associated with a temporary segment.

The statements with the most potential to improve performance, if tuned, include:

• Those consuming greatest resource overall.
• Those consuming greatest resource per row.
• Those executed most frequently.

In the V$SQLAREA view, you can find those statements still in the cache that have done a great deal of disk I/O and buffer gets. (Buffer gets show approximately the amount of CPU resource used.)

Step 2: Tune These Statements To Use Fewer Resources

Remember that application design is fundamental to performance. No amount of SQL statement tuning can make up for inefficient application design. If you encounter SQL statement tuning problems, then perhaps you need to change the application design.

You can use two strategies to reduce the resources consumed by a particular statement:

• Get the statement to use fewer resources.
• Use the statement less frequently.

Statements may use more resources because they do the most work, or because they perform their work inefficiently–or they may do both. However, the lower the resource used per unit of work (per row processed), the more likely it is that you can significantly reduce resources used only by changing the application itself. That is, rather than changing the SQL, it may be more effective to have the application process fewer rows, or process the same rows less frequently.

These two approaches are not mutually exclusive. The former is clearly less expensive, because you should be able to accomplish it either without program change (by changing index structures) or by changing only the SQL statement itself rather than the surrounding logic.

Step 6: Tune the Access Paths

Ensure that there is efficient data access. Consider the use of clusters, hash clusters, B*-tree indexes, bitmap indexes, and optimizer hints. Also consider analyzing tables and using histograms to analyze columns in order to help the optimizer determine the best query plan.

Ensuring efficient access may mean adding indexes or adding indexes for a particular application and then dropping them again. It may also mean re-analyzing your design after you have built the database. You may want to further normalize your data or create alternative indexes. Upon testing the application, you may find that you are still not obtaining the required response time. If this happens, then look for more ways to improve the design.

Step 7: Tune Memory Allocation

Appropriate allocation of memory resources to Oracle memory structures can have a positive effect on performance.

Oracle8i shared memory is allocated dynamically to the following structures, which are all part of the shared pool. Although you explicitly set the total amount of memory available in the shared pool, the system dynamically sets the size of each of the following structures contained within it:

• The data dictionary cache
• The library cache
• Context areas (if running a multi-threaded server)

You can explicitly set memory allocation for the following structures:

• Buffer cache
• Log buffer
• Sequence caches

Proper allocation of memory resources improves cache performance, reduces parsing of SQL statements, and reduces paging and swapping.

Process local areas include:

• Context areas (for systems not running a multi-threaded server)
• Sort areas
• Hash areas

Be careful not to allocate to the system global area (SGA) such a large percentage of the machine’s physical memory that it causes paging or swapping.

Step 8: Tune I/O and Physical Structure

Disk I/O tends to reduce the performance of many software applications. The Oracle server, however, is designed so that its performance is not unduly limited by I/O. Tuning I/O and physical structure involves these procedures:

• Distributing data so that I/O is distributed to avoid disk contention.
• Storing data in data blocks for best access: setting an adequate number of free lists and using proper values for PCTFREE and PCTUSED.
• Creating extents large enough for your data, to avoid dynamic extension of tables. This adversely affects the performance of high-volume OLTP applications.
• Evaluating the use of raw devices.

Step 9: Tune Resource Contention

Concurrent processing by multiple Oracle users may create contention for Oracle resources. Contention may cause processes to wait until resources are available. Take care to reduce the following types of contention:

• Block contention
• Shared pool contention
• Lock contention
• Pinging (in a parallel server environment)
• Latch contention

Step 10: Tune the Underlying Platform(s)

See your platform-specific Oracle documentation for ways to tune the underlying system. For example, on UNIX-based systems you might want to tune the following:

• Size of the UNIX buffer cache
• Logical volume managers
• Memory and size for each process

Applying the Tuning Method

This section explains how to apply the tuning method:

• Set Clear Goals for Tuning
• Create Minimum Repeatable Tests
• Test Hypotheses
• Keep Records and Automate Testing
• Avoid Common Errors
• Stop Tuning When Objectives Are Met
• Demonstrate Meeting the Objectives

Set Clear Goals for Tuning

Never begin tuning without having first established clear objectives: you cannot succeed without a definition of “success.”

“Just make it go as fast as you can” may sound like an objective, but it is very difficult to determine whether this has been achieved. It is even more difficult to tell whether your results have met the underlying business requirements. A more useful objective is: “We need to have as many as 20 operators, each entering 20 orders per hour, and the packing lists must be produced within 30 minutes of the end of the shift.”

Keep your goals in mind as you consider each tuning measure. Consider its performance benefits in light of your goals.

Also remember that your goals may conflict. For example, to achieve best performance for a specific SQL statement, you may need to sacrifice the performance of other SQL statements running concurrently on your database.

Create Minimum Repeatable Tests

Create a series of minimum repeatable tests. For example, if you identify a single SQL statement that is causing performance problems, then run both the original and the revised version of that statement in SQL*Plus (with the SQL Trace Facility or Oracle Trace enabled), so that you can see statistically the difference in performance. In many cases, a tuning effort can succeed simply by identifying one SQL statement that was causing the performance problem.

For example, assume that you need to reduce a 4-hour run to 2 hours. To do this, perform your trial runs using a test environment similar to the production environment. For example, you could impose additional restrictive conditions, such as processing one department instead of all 500 departments. The ideal test case should run for more than 1 minute but probably not longer than 5, so you can intuitively detect improvements. You should also measure the test run using timing features.

Test Hypotheses

With a minimum repeatable test established, and with a script both to conduct the test and to summarize and report the results, you can test various hypotheses to see the effect.

Remember that with Oracle’s caching algorithms, the first time data is cached there is more overhead than when the same date is later accessed from memory. Thus, if you perform two tests, one after the other, then the second test should run faster then the first. This is because data that the test run would otherwise have had to read from disk may instead be more quickly retrieved from the cache.

Keep Records and Automate Testing

Keep records of the effect of each change by incorporating record keeping into the test script. You also should automate testing. Automation provides a number of advantages:

• It permits cost effectiveness in terms of the tuner’s ability to conduct tests quickly.
• It helps ensure that tests are conducted in the same systematic way, using the same instrumentation for each hypothesis you are testing.

You should also carefully check test results derived from observations of system performance against the objective data before accepting them.

Avoid Common Errors

A common error made by inexperienced tuners is to adhere to preconceived notions about what may be causing the problem. The next most common error is to attempt various solutions at random.

Scrutinize your resolution process by developing a written description of your theory of what you think the problem is. This often helps you detect mistakes, simply from articulating your ideas. For best results, consult a team of people to help resolve performance problems. While a performance tuner can tune SQL statements without knowing the application in detail, the team should include someone who understands the application and who can validate the solutions the SQL tuner may devise.

Avoid Poorly Thought Out Solutions

Beware of changing something in the system by guessing. Or, once you have a hypothesis that you have not completely thought through, you may be tempted to implement it globally. Doing this in haste can seriously degrade system performance to the point where you may have to rebuild part of your environment from backups.

Avoid Preconceptions

Try to avoid preconceptions when you address a tuning problem. Ask users to describe performance problems. However, do not expect users to know why the problem exists.

One user, for example, had serious system memory problems over a long period of time. During the morning, the system ran well, but performance rapidly degraded in the afternoon. A consultant tuning the system was told that a PL/SQL memory leak was the cause. As it turned out, this was not at all the problem.

Instead, the user had set SORT_AREA_SIZE to 10MB on a machine with 64 MB of memory serving 20 users. When users logged on to the system, the first time they executed a sort, their sessions were assigned to a sort area. Each session held the sort area for the duration of the session. So, the system was burdened with 200MB of virtual memory, hopelessly swapping and paging.

Stop Tuning When Objectives Are Met

One of the great advantages of having targets for tuning is that it becomes possible to define success. Past a certain point, it is no longer cost effective to continue tuning a system.

Demonstrate Meeting the Objectives

As the tuner, you may be confident that performance targets have been met. Nonetheless, you must demonstrate this to two communities:

• The users affected by the problem.
• Those responsible for the application’s success.

All data in the HRWEST schema is for east coast employees, and all data for the HRSOUTH schema is for the west coast employees.  The HRWEST schema is updated on the hrwestrh7 VM and the data is replicated using GoldenGate (one way) to hrsouthrh7.  Similarly, the data from the HRSOUTH schema is replicated (one way) to the hrwestrh7 VM.

In this first article, will cover the implementation of a GoldenGate hub in the environment described above.  In the second part, we will discuss how to enable the schemas for bi-directional replication.

Among the uses of a GoldenGate hub is the movement of Oracle data to Amazon Web Services (AWS).   There are several steps unique to that process that we are not covering here, but we will cover in a future post.

Step one is to install the Oracle client on the database hub server.  The name of that server in this environment is presplaycld.

The first step is to install the most recent Oracle client on the GoldenGate hub server, choosing the administrator installation. In a hub configuration, GoldenGate is installed only on the hub server, it is not installed on the database servers.  The Oracle client is installed on the hub server.  We will be using the thick client.

This blog forgoes covering the steps for the remainder of the client installation.  Select the defaults after choosing administrator.

Next, install the GoldenGate software.  Follow the instructions for the most recent version of GoldenGate, and install it in the directory listed below (for ease of installation and to follow along with this blog):

/u01/app/oracle/product/12.1.0/gghome

Also for ease of use, define the GoldenGate home directory as GGHOME in a Linux system variable at system start, or use an Oracle user login.  Put the line ‘export GGHOME=/u01/app/oracle/product/12.1.0/gghome_1’ in the .bash_profile to set it at user login, or in the file /etc/profile (to set system wide).

Next, put the client home directory in /etc/oratab:

client:/u01/app/oracle/product/12.1.0/client:N

Next, our tnsnames entries:

HRWESTDB =
 (DESCRIPTION =
 (ADDRESS = (PROTOCOL = TCP)(HOST = hrwestrh7)(PORT = 1521))
 (CONNECT_DATA =
 (SERVICE_NAME = WEST)
 )
 )

HRSOUTHDB =
 (DESCRIPTION =
 (ADDRESS = (PROTOCOL = TCP)(HOST = hrsouthrh7)(PORT = 1521))
 (CONNECT_DATA =
 (SERVICE_NAME = SOUTH)
 )
 )

The above entries go in this file on the hub server:

/u01/app/oracle/product/12.1.0/client/network/admin/tnsnames.ora

Define the TNS_ADMIN directory to point to the directory containing the tnsnames.ora file at either the system or the user login level as described above.

export TNS_ADMIN= /u01/app/oracle/product/12.1.0/client/network/admin

Now lets begin.

1) Set the environment.

. oraenv

ORACLE_SID= [oracle] client

The Oracle base remains unchanged at /u01/app/oracle

Note that setting the environment is required because GoldenGate needs various files binaries from the client installation in order to access remote Oracle databases.

2) Go the GoldenGate installation directory and start the set up process.

[oracle@presplaycld ]$ cd $GGHOME

[oracle@presplaycld gghome]$ ./ggsci

Oracle GoldenGate Command Interpreter for Oracle
 Version 12.3.0.1.0 OGGCORE_12.3.0.1.0_PLATFORMS_170721.0154_FBO
 Linux, x64, 64bit (optimized), Oracle 12c on Jul 21 2017 23:31:13
 Operating system character set identified as UTF-8.

Copyright (C) 1995, 2017, Oracle and/or its affiliates. All rights reserved.

GGSCI (presplaycld) > create subdirs

Creating subdirectories under current directory /u01/app/oracle/product/12.3/gghome

Parameter file                 /u01/app/oracle/product/12.3/gghome/dirprm: created.
 Report file                    /u01/app/oracle/product/12.3/gghome/dirrpt: created.
 Checkpoint file                /u01/app/oracle/product/12.3/gghome/dirchk: created.
 Process status files           /u01/app/oracle/product/12.3/gghome/dirpcs: created.
 SQL script files               /u01/app/oracle/product/12.3/gghome/dirsql: created.
 Database definitions files     /u01/app/oracle/product/12.3/gghome/dirdef: created.
 Extract data files             /u01/app/oracle/product/12.3/gghome/dirdat: created.
 Temporary files                /u01/app/oracle/product/12.3/gghome/dirtmp: created.
 Credential store files         /u01/app/oracle/product/12.3/gghome/dircrd: created.
 Masterkey wallet files         /u01/app/oracle/product/12.3/gghome/dirwlt: created.
 Dump files                     /u01/app/oracle/product/12.3/gghome/dirdmp: created.

GGSCI (presplaycld) > edit param mgr

PORT 7865

GGSCI (presplaycld) > start mgr
 Manager started.

Next, we set up the credentialstore.

GGSCI (presplaycld) > add credentialstore

Credential store created in /u01/app/oracle/product/12.3/gghome/dircrd/.

GGSCI (presplaycld) > alter credentialstore add user ggadmin@hrsouthdb password ggadmin alias ggadmine

Credential store in /u01/app/oracle/product/12.3/gghome/dircrd/ altered.

GSCI (presplaycld) > alter credentialstore add user ggadmin@hrsouthdb password ggadmin alias ggadminw

Credential store in /u01/app/oracle/product/12.3/gghome/dircrd/ altered.

3) Configure the databases for GoldenGate.

On each database do the following.

Create the ggadmin user, grant privileges, and configure the database as shown below (in SQLPLUS):

alter database add supplemental log data
 alter system set enable_goldengate_replication=true scope=both;
 create tablespace ggs_data datafile '/u01/app/oracle/oradata/ggdemo/ggs_data01.dbf'
 size 1024m autoextend on;
 create user ggadmin identified by ggadmin default tablespace ggs_data
 temporary tablespace temp;
 grant connect,resource,create session, alter session to
 ggadmin;
 grant select any dictionary, select any table,create table to
 ggadmin;
 grant alter any table to ggadmin;
 grant execute on utl_file to ggadmin;
 grant flashback any table to ggadmin;
 grant execute on dbms_flashback to ggadmin;
 @marker_setup.sql
 @ddl_setup.sql
 @role_setup.sql
 @ddl_enable.sql
 @sequence.sql
 EXEC DBMS_GOLDENGATE_AUTH.GRANT_ADMIN_PRIVILEGE(‘GGADMIN’);
 grant ggs_ggsuser_role to ggadmin;
 @ddl_enable
 shutdown immediate;
 startup mount;
 alter database archivelog;
 alter database flashback on;
 alter database open;
 alter database add supplemental log data;
 alter database force logging;
 grant EXECUTE on dbms_logmnr_d to GGADMIN;
 grant SELECT on sys.logmnr_buildlog to GGADMIN;
 GRANT EXECUTE ON UTL_FILE TO  GGADMIN;
 grant EXEMPT ACCESS POLICY to GGADMIN;

4) Go back to ggsci to set up the replication.

ggsci > dblogin useridalias ggadmine

ggsci as ggadmin@hrwestdb > add schematrandata hrwest ALLCOLS

ggsci as ggadmin@hrwestdb > add schematrandata hrsouth ALLCOLS

ggsci as ggadmin@hrwestdb > edit params extehre

extract extehre
 exttrail ./dirdat/ee
 tranlogoptions IntegratedParams (max_sga_size 256)
 discardfile ./dirrpt/silext01.dsc, append megabytes 50
 logallsupcols
 updaterecordformat compact
 reportcount every 2 hours, rate
 useridalias ggadmine
 tabe HRWEST.*;

ggsci as ggadmin@hrwestdb > register extract extehre database

2017-11-29 17:11:40  INFO    OGG-02003  Extract extehre successfully registered with database at SCN 1980353.<= Record this for future use.

GGSCI (presplaycld as ggadmin@hrwestdb) 8> add extract extehre, integrated tranlog, begin now
 EXTRACT (Integrated) added.

GGSCI (presplaycld as ggadmin@hrwestdb) 26> ADD EXTTRAIL ./dirdat/ee, EXTRACT extehre
 EXTTRAIL added.

GGSCI (presplaycld as ggadmin@hrwestdb) 27> start extract extehre

Sending START request to MANAGER ...
 EXTRACT extehre starting

At this point, the data from the HRWEST schema is being replicated from the HRWEST database, but is not as yet being applied to the HRSOUTH database.  The next step is to import the initial data into the HRSOUTH database.  We need to import all data prior to the start of replication.  Datapump is one method for building this initial load as described below:

1 – In the HRSOUTH database, create a database link that points to HRWEST.

SQL> Create database link hrwest connect to system identified by system using ‘hrwest’;

2 – Create a SQLPLUS directory for datapump to use.  In this case, I used HOMEDIR: SQL> Create directory homedir as ‘/home/oracle’;

3 – Use the datapump network link option to load the data:

impdp directory=homedir schemas=hrwest table_exists_action=replace network_link=hrwest flashback_scn=1980352 (one less than the SCN recorded from above)

4 – The data will be imported into the HRSOUTHDB.

Now we are ready to configure the replicat.  This applies the changes being captured using the extract.

Connect to the hrsouth database as ggadmin from ggsci:

ggsci> dblogin useridalias ggadminw

GGSCI (presplaycld as ggadmin@hrsouthdb) > add schematrandata hrwest ALLCOLS

GGSCI (presplaycld as ggadmin@hrsouthdb) > add schematrandata hrsouth ALLCOLS

GGSCI (presplaycld as ggadmin@hrsouthdb) > add replicat wesrepe integrated exttrail ./dirdat/ee  <= remember, this is the same as the exttrail declared for the extract.
 REPLICAT (Integrated) added.

edit params wesrepe

replicat wesrepe
 ASSUMETARGETDEFS
 DISCARDFILE ./dirrpt/weserep01.dsc
 DDL INCLUDE ALL
 USERIDALIAS ggadminw
 REPORTCOUNT EVERY 1 HOURS, RATE
 MAP HRWEST.*, TARGET HRWEST.*;

GGSCI (presplaycld as ggadmin@hrsouthdb) > start replicat wesrepe

At this point, replication should be working from HRWESTDB to HRSOUTHDB.  Be sure to run updates in HRWESTDB to verify that everything is working correctly.

Now, follow the same process to replicate the HRSOUTH schema from HRSOUTHDB to HRWESTDB.

We are already connected to HRSOUTHDB, so we can define the extract here:

ggsci as ggadmin@hrwestdb > register extract extwhre database

2017-11-29 17:11:40  INFO    OGG-02003  Extract extwhrw successfully registered with database at SCN 1980353.<= Record this for future use.

GGSCI (presplaycld as ggadmin@hrsouthdb) > add extract extwhrw, integrated tranlog, begin now
 EXTRACT (Integrated) added.

GGSCI (presplaycld as ggadmin@hrsouthdb) > ADD EXTTRAIL ./dirdat/we, EXTRACT extwhrw
 EXTTRAIL added.

GGSCI (presplaycld as ggadmin@hrsouthdb) > edit params extwhrw

extract extwhrw
 exttrail ./dirdat/ww
 tranlogoptions IntegratedParams (max_sga_size 256)
 discardfile ./dirrpt/orcext01.dsc, append megabytes 50
 logallsupcols
 updaterecordformat compact
 reportcount every 2 hours, rate
 useridalias ggadmino
 table HRSOUTH.*;

GGSCI (presplaycld as ggadmin@hrsouthdb) > start extract extwhrw

Now set up the replicat:

1. In the HRWEST database, create a database link that points to HRSOUTH.

SQL> Create database link HRSOUTH connect to system identified by system using ‘hrsouth’;

2. Create a SQLPLUS directory for datapump to use.  In this case, I used HOMEDIR: SQL> Create directory homedir as ‘/home/oracle’;
3. Use the datapump network link option to load the data:

impdp directory=homedir schemas=hrsouth table_exists_action=replace network_link=hrsouth flashback_scn=1980352 (one less than the SCN recorded from above)

4. The data will be imported into the HRWESTDB.

Now we are ready to configure the replicat:

GGSCI (presplaycld as ggadmin@hrwestdb) >dblogin useridalias ggadmine

GGSCI (presplaycld as ggadmin@hrwestdb) > add schematrandata hrsouth ALLCOLS

GGSCI (presplaycld as ggadmin@hrwestdb) > add replicat easrepw integrated exttrail ./dirdat/we  <= remember this is the same as the exttrail declared for the extract.
 REPLICAT (Integrated) added.

edit params easrepw

replicat easrepw
 ASSUMETARGETDEFS
 DISCARDFILE ./dirrpt/easrepw01.dsc
 DDL INCLUDE ALL
 USERIDALIAS ggadmine
 REPORTCOUNT EVERY 1 HOURS, RATE
 MAP HRSOUTH.*, TARGET HRSOUTH.*;

GGSCI (presplaycld as ggadmin@hrsouthdb) > start replicat easrepw

At this point, we have replication running from HRSOUTHDB, schema HRSOUTH, to HRWESTDB. Schema HRWEST is replicating from HRWESTDB to HRSOUTHDB.  We are using a GoldenGate hub server, on a third system, to manage the replication process.

Please note that you will need to run updates in each schema in order to verify that everything is working properly.

In part two, we will make the necessary changes to allow for multi-master replication, in case we need to be able to run it in both databases.

Please note: this blog contains code examples provided for your reference. All sample code is provided for illustrative purposes only. Use of information appearing in this blog is solely at your own risk. Please read our full disclaimer for details.

Share with your network

Cybersecurity protection for work at home employees

Overnight, all over the world, users are staying at home – and working from home. This requires new devices and new software licenses – but what about support?

In most organizations work-from-home has many positive consequences. The employees are working hard, and they continue evenings and week-ends to get the job done. Even after the Corona-virus we now expect that work-from-home will continue on a much higher level than before the crisis. The hardware and software is in place, but the users still need support from the central IT service help desk.

Expect to see higher load, and tasks you can’t support today. Expect to see more load at unusual times like nights and weekends. If the support isn’t available, then the employees can’t do their job, and our companies will lose productivity.

It has also been reported that the cyber-criminals exploit the situation. It is more difficult for the central support team to verify if someone calling in is a real employee, or a criminal impersonating a real employee.

New tools are needed to get the support done without increasing the costs and risks for the organizations.

More calls

Many users will have new experiences and surprises. How do I print, how do I scan, where is this service, etc.? With more calls comes increased stress for the service desk; queue time for users will increase and general productivity will deteriorate for the users and the IT-team.

We hear of increases of the magnitude of 15% more calls. Look for tools to help the service desk, those that provide fast solutions through self-service, to see the total number of calls go down. On average in the industry 20% of all calls are password related. With an efficient user-friendly password self-service tool, then you can cut the number of calls back to the normal level.

The key to self-service success is that at least 80-90% of all users will and can use the self-service.

Password reset

One trivial incident will not change – users forget passwords and call for password recovery and resets. A simple question: “Can your service desk reset a password at a remote company PC?” Even when you use VPN for security, the service desk can’t access a “dead PC”.

Today for most companies the only solution is for someone to transport the PC back to company premises, so that the PC-cache password can be synchronized with the AD-password, and the user can get the PC back. This is very expensive.

What the users want is a solution where they, in a simple way, can verify their identity to a self-service, and then the PC works again. This will help the user carry on even when it happens in week-end or night time. There are out of the box solutions that solve this important technical issue.

Identity verification

When a criminal calls someone over the phone and impersonates another person to achieve something it is called vishing (Voice based phishing). When working from home this risk increases many folds.

New security issues: In “the old days,” people called the service desk from local company phones, meaning that we could verify who they were, but working from home doesn’t give us much with which to verify the user’s identity. If they ask for a password reset, how can we verify that the person is the user they claim to be?

We need a process, but even that is not enough. Social engineers, hackers, know how to use emotions to get the service desk supporters to help them. The emotions might be fear, greed or just the desire to be an empathetic person. This is what “Help desks” are for! To win this battle with the criminals we must introduce an IT-workflow that controls the entire verification process. This will take emotions out of the verification.

Controlling the ID verification should include a verbal identity “test” by the service desk. Using knowledge about what computers the real employees’ use, the location they work from, and a lot of confidential information, the test questions will be impossible for a hacker to answer. For important employees, the test can even include approval from managers in the process. It takes more time to include new persons in the process, but the cost of failure is much higher.

Just the above 3 changes to your support team will mean dissatisfied management and concerns from IT security management. It’s time to reduce the burden on the service desk and let users give themselves a better service than the service desk can. And don’t forget IT security – the hackers don’t take a break – they’re increasing their efforts right now.

A solution

With work-from-home we see how companies struggle with costs and security issues. The solution (cloud or on-premise) – can immediately help companies reduce the load on the service desk, make employees more productive, and prevent criminals from using the service desk to get access to important applications.

The basic objectives of the solution should be to reduce calls to the service desk; reset passwords for remote PC’s through a company VPN and provide rock-solid, unbreakable, user identification.

To address the challenges for police in preventing and investigating cybercrime globally, the 7th Europol-INTERPOL Cybercrime Conference brought together cyber experts from law enforcement, private industry, international organizations and academia for in-depth discussions on the latest cyber threats, trends and strategies.

Under the theme of ‘Law enforcement in a connected future’, the three-day (9 – 11 October) conference focused on new developments in technology which could be exploited by criminals but also used to the benefit of police.

Key themes included the benefits and challenges of Artificial Intelligence for police; the potential impacts of 5G technology; cross-border access to electronic evidence; obstacles to international cooperation on cybercrime investigations; the importance of cyber capacity building; cryptocurrency trends and challenges; the use of open-source intelligence and privacy considerations.

With cybercriminals constantly evolving and transforming their tactics, INTERPOL’s Director of Cybercrime Craig Jones said the traditional model of policing is ‘being challenged like never before’.

“The cybercriminal world is agile and adapting, connecting and cooperating in ways we never imagined even just a few years ago,” said Mr Jones.

“Law enforcement must adapt to this ever-changing criminal environment in order to effectively protect our communities in the cyber domain,” he concluded.

During the opening ceremony, Mr Jones launched INTERPOL’s ‘#BECareful’ global public awareness campaign on business email compromise (BEC) fraud. The campaign, which will run for one month, will inform the public about this growing type of fraud and provide prevention tips for how to stay safe.

INTERPOL also presented the findings of its first cybercrime threat assessment during the conference. The report provides an analysis of the latest cybercrime trends identified in different regions using information provided by member countries, private partners and open source intelligence.

One trend identified is a shift from malware targeting computers to attacks targeting mobile devices, due to the fact that mobile devices are being used more and more frequently as payment platforms.

In response to a rise in cases of cryptojacking – where criminals remotely accesses victims’ system using malware to hijack their computing power to create cryptocurrency – INTERPOL has disseminated more than 170 Cyber Activity Reports providing recommendation for prevention and mitigation.

Steven Wilson, Head of Europol’s European Cybercrime Centre (EC3) said: “Three days of conference with partners from law enforcement, industry and academia have shown what we can achieve when we work closely together to tackle the global issue of cybercrime.”

“We must make progress in prevention, legislation, enforcement and prosecution.“Steven Wilson, Head of Europol’s European Cybercrime Centre (EC3)

“All of these elements are necessary in order to disrupt organized crime activity and reduce the online threat to businesses, governments and, above all, EU citizens. I look forward to  building on our trusted relationships to deliver an improved international response to this ever increasing challenge,” added Mr Wilson.

The conference, which gathered some 400 delegates from 70 countries, also provides an opportunity for Europol and INTERPOL to reconfirm their strong commitment to continue their collaboration in the fight against cybercrime.

The Europol-INTERPOL Cybercrime Conference is a joint initiative launched in 2013. Held annually, it is hosted in alternate years by Europol and INTERPOL.

You may have realized that there are a few techniques missing describing how to do a Database Migration from non-CDB to PDB – Migration with Data Pump is one of them. I will explain the most simple approach of going to Single- or Multitenant. It isn’t the coolest – and it isn’t very fast as soon as your database has a significant size. But it is not complex. And it allows you to move even from very old versions directly into an Oracle 19c PDB – regardless of patch levels or source and destination platform.

High Level Overview

Database Migration from non-CDB to PDB – Migration with Data Pump

Well, I think I don’t need to explain Oracle Data Pump to anybody. At the end of this blog post you will find a long list of links pointing to the documentation and various workarounds. The big advantages of using Data Pump to migrate from a non-CDB into a PDB are:

• Works with every version since Oracle 10.1.0.2
• Works regardless of patch level
• Does not require any upgrade
• Works across all platforms
• Works regardless of encryption
• Allows multiple transformations

But the disadvantages of Data Pump are obvious as well as the duration depends mostly on:

• Amount of data
• Complexity of meta information
• Special data types such as LONG and LOB

I’d call Data Pump the most flexible approach but of course potentially also the slowest of all options.

Process Overview

Using Data Pump either allows you to export into a dump file, and import from this dump file afterwards.

Or you setup a database link from destination to source, and run the import from the destination of the database link using the NETWORK_LINK parameter.

The advantage of using a database link is not-writing a dump file which does not need to be copied over. But not all actions can run in parallel. Plus, not every data type is supported (LONG for instance until 12.2). And your limiting factor is always the source side as Data Pump implicitly calls expdp on the source side. To my experience this can be faster but especially when you work on the same storage or SAN, and you don’t have to move the dump file around, the first approach often works better.

Some Best Practices

There are some recommendations for both approaches:

• Always use a par file
• For a consistent export, use either FLASHBACK_TIME=SYSTIMESTAMP or CONSISTENT=Y (since 11.2)
• Always EXCLUDE=STATISTICS – regather stats in destination is faster, or transport with a STATS table from DBMS_STATS
• Set METRICS=Y and since 12.1, LOGTIME=ALL
• Use PARALLEL=<2x number of cpu cores>
  • Since Oracle 12.2, meta data gets exported in parallel – but not with NETWORK_LINK
• Preallocate STREAMS_POOL_SIZE=128M (or in the range of 64M-256M)
• BasicFile LOB (old 8i LOBs) are always slow
  • Use LOB_STORAGE=SECUREFILE to convert to SecureFile LOBs as part of the migration

Fallback

When you used Data Pump as a migration approach to move from non-CDB to PDB, then I don’t expect you to force a fast fallback scenario in case of failure. The important task is to use the VERSION parameter correctly when you export from the destination PDB. You need to set it to the source’s release in order to export in the format and with the contents, the (old) source will understand when you reimport. Make sure, there’s an empty database waiting in case fallback is important. And don’t cleanup your old source home too early.

Be aware of one major pitfall: The time zone version. As typically your source database has a lower time zone version than the destination, you can migrate “forward” (same or higher version) but not “backwards” (lower version). Hence, in case of fallback you most likely need to apply a DST Time Zone patch to the older home in order to allow Data Pump to import. And make sure you follow the supported configurations setup from MOS Note:553337.1 carefully.

Unfortunately, the fallback strategy over a NETWORK_LINK does not work. Even though the below scenario looks promising, you’ll receive an error when you call imdp from the lower version over the DB Link. I’d assume that the VERSION parameter does not get propagated in a way to convince the expdp side to export in 11.2.0.4 format.

This will be the error you’ll receive:

$ impdp system/oracle@ftex network_link=sourcedb version=11.2.0.4 tables=tab1 metrics=y exclude=statistics directory=mydir logfile=pdb2.log

Import: Release 11.2.0.4.0 - Production on Wed Aug 14 20:27:52 2019

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
ORA-39001: invalid argument value
ORA-39169: Local version of 11.2.0.4.0 cannot work with remote version of 19.0.0.0.0.