The document provides guidance on different backup and recovery scenarios for both user-managed and RMAN-managed recovery in Oracle databases. It lists 7 user-managed recovery scenarios including recovering a missing system tablespace, non-system tablespace, or datafile. It also covers control file recovery and incomplete recovery up to a point in time or log sequence. For RMAN recovery, it recommends configuring automatic backups and retention policies and describes using RMAN to backup datafiles, control files, and archive logs.
Step by Step Restore rman to different hostOsama Mustafa
1. Take a backup of the database and archived logs on the source system using RMAN.
2. Copy the backup files to the new target system using the same directory structure.
3. Restore the control file, SPFILE, and database files to the target system using RMAN, changing the data file locations and redo log file locations as needed.
4. Open the database with a resetlogs after restoring the database, control file, and archived redo logs from backup.
Francisco Munoz Alvarez will present on advanced RMAN backup and recovery techniques. Key topics include point-in-time recovery using RMAN, RMAN and Oracle Flashback technologies, performance tuning RMAN operations, and database duplication. The presentation will provide examples of using RMAN for incomplete database recovery at a specific point in time, system change number, or log sequence number.
The document describes migrating database files from the "+DATA01" disk group to the new "+DATA02" disk group. It involves creating the new disk group, identifying database file locations, copying files to the new disk group using RMAN backups, and switching the database to use the new disk group.
RMAN backup scripts should be improved in the following ways:
1. Log backups thoroughly and send failure alerts to ensure recoverability.
2. Avoid relying on a single backup and use redundancy to protect against data loss.
3. Back up control files last and do not delete archives until backups are complete.
4. Check backups regularly to ensure they meet recovery needs.
Using RMAN to Perform Recovery discusses using RMAN to recover databases through various methods including:
1) Recovering lost or corrupted data files using RESTORE and RECOVER commands.
2) Performing fast recovery by switching to image copies and recovering data files.
3) Restoring a database to a new host by restoring backups, control files, and server parameter files.
Yuri is called to audit RMAN backup scripts on regular basis for several years now as part of his Day to Day duties. He see the same errors in scripts that Oracle DBAs using to backup critical databases over and over again. Those errors may play a significant role in a recovery process when you working under stress. During that presentation you will be introduced to typical issues and hints how to address those.
Step by Step Restore rman to different hostOsama Mustafa
1. Take a backup of the database and archived logs on the source system using RMAN.
2. Copy the backup files to the new target system using the same directory structure.
3. Restore the control file, SPFILE, and database files to the target system using RMAN, changing the data file locations and redo log file locations as needed.
4. Open the database with a resetlogs after restoring the database, control file, and archived redo logs from backup.
Francisco Munoz Alvarez will present on advanced RMAN backup and recovery techniques. Key topics include point-in-time recovery using RMAN, RMAN and Oracle Flashback technologies, performance tuning RMAN operations, and database duplication. The presentation will provide examples of using RMAN for incomplete database recovery at a specific point in time, system change number, or log sequence number.
The document describes migrating database files from the "+DATA01" disk group to the new "+DATA02" disk group. It involves creating the new disk group, identifying database file locations, copying files to the new disk group using RMAN backups, and switching the database to use the new disk group.
RMAN backup scripts should be improved in the following ways:
1. Log backups thoroughly and send failure alerts to ensure recoverability.
2. Avoid relying on a single backup and use redundancy to protect against data loss.
3. Back up control files last and do not delete archives until backups are complete.
4. Check backups regularly to ensure they meet recovery needs.
Using RMAN to Perform Recovery discusses using RMAN to recover databases through various methods including:
1) Recovering lost or corrupted data files using RESTORE and RECOVER commands.
2) Performing fast recovery by switching to image copies and recovering data files.
3) Restoring a database to a new host by restoring backups, control files, and server parameter files.
Yuri is called to audit RMAN backup scripts on regular basis for several years now as part of his Day to Day duties. He see the same errors in scripts that Oracle DBAs using to backup critical databases over and over again. Those errors may play a significant role in a recovery process when you working under stress. During that presentation you will be introduced to typical issues and hints how to address those.
Tablespace point-in-time recovery (TSPITR) enables recovery of one or more tablespaces to an earlier time without affecting other tablespaces or objects. TSPITR restores and recovers data files for the recovery set and auxiliary set to the target time, then exports and imports metadata to apply the recovery. TSPITR is useful for data recovery after errors, logical corruption, or unwanted changes, but cannot recover dropped or renamed tablespaces. Preparation includes determining the target time and recovery set tablespaces. Automated RMAN TSPITR performs the restore, recovery, and metadata steps without manual instance management.
The document discusses setting up an Oracle 12c Active Data Guard physical standby database using RMAN DUPLICATE FROM ACTIVE. It involves 3 steps:
1) Configuring the primary and standby databases, including creating required directories, adding static entries to listener.ora, and editing tnsnames.ora.
2) Running RMAN DUPLICATE FROM ACTIVE on the primary to create the standby database instance while it is in NOMOUNT mode.
3) After duplicate completes, configuring redo transport on both primary and standby, adding standby redo logs, and opening the standby database to start managed recovery.
Tablespace point-in-time recovery (TSPITR) allows recovery of one or more tablespaces to an earlier point in time without affecting other tablespaces. It performs restore and recovery of data files for the recovery set and auxiliary set to the target time, then exports and imports metadata to make the recovered tablespaces available. TSPITR is useful for undoing DML changes or recovering from logical corruption in a subset of the database, and can be fully automated using RMAN or performed with a custom auxiliary instance.
This document discusses monitoring and tuning RMAN backups and restores. It covers monitoring the progress of RMAN jobs, configuring RMAN for asynchronous I/O and multiplexing to improve tape streaming efficiency. It also explains how parameters like MAXPIECESIZE, FILESPERSET, and MAXOPENFILES affect RMAN performance and how the BACKUP DURATION option can speed up or slow down backups. The goal is to evaluate the balance between backup speed and recovery speed and identify bottlenecks to optimize RMAN performance.
The document discusses using the RMAN recovery catalog to store metadata about backups and manage RMAN repositories. Key points:
- A recovery catalog stores more historical information than a control file and allows managing metadata for multiple target databases.
- Creating a recovery catalog involves configuring a database, creating an owner, and executing CREATE CATALOG. Target databases are then registered.
- Benefits include using RMAN stored scripts, customized reports, and the KEEP FOREVER clause.
- Virtual private catalogs allow multiple owners to manage separate metadata subsets within a shared base catalog.
This document discusses preparing the database environment by describing the tasks of a database administrator, required tools, installation requirements, and using Optimal Flexible Architecture (OFA) standards. It outlines installing Oracle software using Oracle Universal Installer (OUI), which allows for automated installation through response files in silent mode. Key steps include checking system requirements, setting environment variables, running OUI for configuration options, and executing configuration scripts.
The document provides information about finding the location of OCR and voting disks in an Oracle RAC environment. It states that the OCR location can be found in the /etc/oracle/ocr.loc file and the voting disk location can be found using the crsctl query css votedisk command. It also provides information on backing up the OCR and voting disks, such as using dd to backup voting disks and ocrconfig to backup and restore OCR.
This document discusses various methods for moving data in and out of Oracle databases, including:
1) Using SQL*Loader to load data from files into Oracle tables, external tables to access file data, and Oracle Data Pump for full database exports and imports.
2) Oracle Data Pump allows high-speed movement of data and metadata and can be called from the command line or Enterprise Manager. It supports features like parallel processing, encryption, and fine-grained object selection.
3) Methods like SQL*Loader and external tables read data from files while Data Pump uses the direct path API for fast loading and unloading of data directly to and from disk.
This document discusses user-managed database backup and recovery, including:
- The difference between user-managed and server-managed backup which uses OS commands versus RMAN.
- How to perform a complete database recovery by restoring files and archive logs and applying redo logs.
- How to perform incomplete recovery to recover to a past time or SCN by restoring files and applying redo logs until a specified point.
Rman cloning when both directory and db name are same.subhani shaik
1. The document describes steps to duplicate a database where the source and destination database have the same name. It involves taking a backup of the source database, copying files to the destination, and using RMAN to restore and recover the database.
2. Key steps include making the directory structures the same on source and destination, starting the destination database in nomount mode, restoring the control file and datafiles, recovering changes, and opening the database.
3. The destination database is verified by checking the locations of datafiles, control files and redo logs.
This document discusses using RMAN to duplicate a database. It describes how to duplicate a database using RMAN and a target database backup. The key steps are to create an initialization file and start the auxiliary instance, ensure backups and redo logs are available, allocate auxiliary channels in RMAN, and run the DUPLICATE command specifying the same database name. This duplicates the target database files and recovers them on the auxiliary instance using backups and redo logs.
Duplicating a database creates an identical copy of a database that can be used for testing or recovery purposes. There are multiple techniques for duplicating a database using RMAN, including duplicating from an active database, from RMAN backups, with or without connections to the target instance, recovery catalog, or using backups alone. The key steps are preparing the auxiliary instance, ensuring backups and redo logs are available, allocating auxiliary channels, and using the RMAN DUPLICATE command to restore files and recover the database.
This document discusses monitoring and tuning RMAN backup and restore performance. It describes how to configure RMAN for asynchronous I/O and multiplexing, monitor job progress, identify bottlenecks, and balance backup speed versus recovery speed. Specific parameters like MAXPIECESIZE, FILESPERSET, and MAXOPENFILES are examined for their effect on performance.
The document provides steps for cloning an Oracle EBS R12 environment from a source (PROD) system to a target (TEST) system. Key steps include:
1. Backing up files and databases from the source including applications files, database parameter files, and database backups.
2. Copying the backed up files to the target system and modifying configuration files to point to the target system.
3. Restoring and recovering the database on the target system using RMAN and modifying datafile names.
4. Running scripts to clone the application tier files and configure the applications.
5. Performing post-clone tasks like dropping and recreating temp tablespaces and cleaning up configuration.
This document provides guidance on different backup and recovery scenarios using both user managed and RMAN-managed approaches. It outlines the steps to recover from issues like a missing system or non-system tablespace, missing or corrupted datafiles or control files, and performing incomplete recovery up to a point in time or log sequence number. Both user-managed scripts and RMAN commands are demonstrated for each scenario.
Oracle database hot backup and recoveryArun Sharma
Oracle database hot backup and recovery process. Please note that this method is no longer used in real-time as RMAN does way better job at database backup & recovery.
This is just good to know activity but do not implement it in real time. Knowing how Oracle hot backup and recovery process works, it helps you understand Oracle RMAN better.
Here is the full link of article: https://www.support.dbagenesis.com/post/oracle-database-hot-backup-and-recovery
Mid term & final- preparation- student-review(Oracle)than sare
This document contains a multiple choice question test with 20 questions about Oracle database concepts like instances, parameters, memory management, backups, and recovery. It also includes fill-in-the-blank and problem solving questions testing knowledge of altering profiles, control files, undo retention, tablespace properties, RMAN commands, and recovery procedures. The test is assessing understanding of key Oracle administration and troubleshooting tasks.
Tablespace point-in-time recovery (TSPITR) enables recovery of one or more tablespaces to an earlier time without affecting other tablespaces or objects. TSPITR restores and recovers data files for the recovery set and auxiliary set to the target time, then exports and imports metadata to apply the recovery. TSPITR is useful for data recovery after errors, logical corruption, or unwanted changes, but cannot recover dropped or renamed tablespaces. Preparation includes determining the target time and recovery set tablespaces. Automated RMAN TSPITR performs the restore, recovery, and metadata steps without manual instance management.
The document discusses setting up an Oracle 12c Active Data Guard physical standby database using RMAN DUPLICATE FROM ACTIVE. It involves 3 steps:
1) Configuring the primary and standby databases, including creating required directories, adding static entries to listener.ora, and editing tnsnames.ora.
2) Running RMAN DUPLICATE FROM ACTIVE on the primary to create the standby database instance while it is in NOMOUNT mode.
3) After duplicate completes, configuring redo transport on both primary and standby, adding standby redo logs, and opening the standby database to start managed recovery.
Tablespace point-in-time recovery (TSPITR) allows recovery of one or more tablespaces to an earlier point in time without affecting other tablespaces. It performs restore and recovery of data files for the recovery set and auxiliary set to the target time, then exports and imports metadata to make the recovered tablespaces available. TSPITR is useful for undoing DML changes or recovering from logical corruption in a subset of the database, and can be fully automated using RMAN or performed with a custom auxiliary instance.
This document discusses monitoring and tuning RMAN backups and restores. It covers monitoring the progress of RMAN jobs, configuring RMAN for asynchronous I/O and multiplexing to improve tape streaming efficiency. It also explains how parameters like MAXPIECESIZE, FILESPERSET, and MAXOPENFILES affect RMAN performance and how the BACKUP DURATION option can speed up or slow down backups. The goal is to evaluate the balance between backup speed and recovery speed and identify bottlenecks to optimize RMAN performance.
The document discusses using the RMAN recovery catalog to store metadata about backups and manage RMAN repositories. Key points:
- A recovery catalog stores more historical information than a control file and allows managing metadata for multiple target databases.
- Creating a recovery catalog involves configuring a database, creating an owner, and executing CREATE CATALOG. Target databases are then registered.
- Benefits include using RMAN stored scripts, customized reports, and the KEEP FOREVER clause.
- Virtual private catalogs allow multiple owners to manage separate metadata subsets within a shared base catalog.
This document discusses preparing the database environment by describing the tasks of a database administrator, required tools, installation requirements, and using Optimal Flexible Architecture (OFA) standards. It outlines installing Oracle software using Oracle Universal Installer (OUI), which allows for automated installation through response files in silent mode. Key steps include checking system requirements, setting environment variables, running OUI for configuration options, and executing configuration scripts.
The document provides information about finding the location of OCR and voting disks in an Oracle RAC environment. It states that the OCR location can be found in the /etc/oracle/ocr.loc file and the voting disk location can be found using the crsctl query css votedisk command. It also provides information on backing up the OCR and voting disks, such as using dd to backup voting disks and ocrconfig to backup and restore OCR.
This document discusses various methods for moving data in and out of Oracle databases, including:
1) Using SQL*Loader to load data from files into Oracle tables, external tables to access file data, and Oracle Data Pump for full database exports and imports.
2) Oracle Data Pump allows high-speed movement of data and metadata and can be called from the command line or Enterprise Manager. It supports features like parallel processing, encryption, and fine-grained object selection.
3) Methods like SQL*Loader and external tables read data from files while Data Pump uses the direct path API for fast loading and unloading of data directly to and from disk.
This document discusses user-managed database backup and recovery, including:
- The difference between user-managed and server-managed backup which uses OS commands versus RMAN.
- How to perform a complete database recovery by restoring files and archive logs and applying redo logs.
- How to perform incomplete recovery to recover to a past time or SCN by restoring files and applying redo logs until a specified point.
Rman cloning when both directory and db name are same.subhani shaik
1. The document describes steps to duplicate a database where the source and destination database have the same name. It involves taking a backup of the source database, copying files to the destination, and using RMAN to restore and recover the database.
2. Key steps include making the directory structures the same on source and destination, starting the destination database in nomount mode, restoring the control file and datafiles, recovering changes, and opening the database.
3. The destination database is verified by checking the locations of datafiles, control files and redo logs.
This document discusses using RMAN to duplicate a database. It describes how to duplicate a database using RMAN and a target database backup. The key steps are to create an initialization file and start the auxiliary instance, ensure backups and redo logs are available, allocate auxiliary channels in RMAN, and run the DUPLICATE command specifying the same database name. This duplicates the target database files and recovers them on the auxiliary instance using backups and redo logs.
Duplicating a database creates an identical copy of a database that can be used for testing or recovery purposes. There are multiple techniques for duplicating a database using RMAN, including duplicating from an active database, from RMAN backups, with or without connections to the target instance, recovery catalog, or using backups alone. The key steps are preparing the auxiliary instance, ensuring backups and redo logs are available, allocating auxiliary channels, and using the RMAN DUPLICATE command to restore files and recover the database.
This document discusses monitoring and tuning RMAN backup and restore performance. It describes how to configure RMAN for asynchronous I/O and multiplexing, monitor job progress, identify bottlenecks, and balance backup speed versus recovery speed. Specific parameters like MAXPIECESIZE, FILESPERSET, and MAXOPENFILES are examined for their effect on performance.
The document provides steps for cloning an Oracle EBS R12 environment from a source (PROD) system to a target (TEST) system. Key steps include:
1. Backing up files and databases from the source including applications files, database parameter files, and database backups.
2. Copying the backed up files to the target system and modifying configuration files to point to the target system.
3. Restoring and recovering the database on the target system using RMAN and modifying datafile names.
4. Running scripts to clone the application tier files and configure the applications.
5. Performing post-clone tasks like dropping and recreating temp tablespaces and cleaning up configuration.
This document provides guidance on different backup and recovery scenarios using both user managed and RMAN-managed approaches. It outlines the steps to recover from issues like a missing system or non-system tablespace, missing or corrupted datafiles or control files, and performing incomplete recovery up to a point in time or log sequence number. Both user-managed scripts and RMAN commands are demonstrated for each scenario.
Oracle database hot backup and recoveryArun Sharma
Oracle database hot backup and recovery process. Please note that this method is no longer used in real-time as RMAN does way better job at database backup & recovery.
This is just good to know activity but do not implement it in real time. Knowing how Oracle hot backup and recovery process works, it helps you understand Oracle RMAN better.
Here is the full link of article: https://www.support.dbagenesis.com/post/oracle-database-hot-backup-and-recovery
Mid term & final- preparation- student-review(Oracle)than sare
This document contains a multiple choice question test with 20 questions about Oracle database concepts like instances, parameters, memory management, backups, and recovery. It also includes fill-in-the-blank and problem solving questions testing knowledge of altering profiles, control files, undo retention, tablespace properties, RMAN commands, and recovery procedures. The test is assessing understanding of key Oracle administration and troubleshooting tasks.
Checkpointing saves database status and changes to data files. It reduces recovery time after a fault. Regular checkpointing is performed automatically or manually. Reasons redo logs may not delete after checkpointing include active transactions or archiving in Archivelog mode. Media recovery restores missing or corrupted data files using backups, archive logs, and log anchor files in Archivelog mode.
This document discusses database backup and recovery concepts including:
1. Mean time between failures and mean time to recover should have high and low values respectively. Database failures can occur due to statements, processes, instances, and user errors.
2. Solutions for failures include adding filespaces, using PMON to recover from backups, restarting instances, and SQL commands like ALTER SYSTEM SWITCH LOGFILE.
3. Views like V$INSTANCE, V$FAST_START_SERVERS, V$BACKUP are queried to obtain database information for managing backups and different types of recovery including time-based, cancel-based, and change-based.
This document discusses using Oracle's Recovery Manager (RMAN) to perform various database recovery tasks, including recovering from the loss of data files, using incremental backups to reduce recovery time, switching to image copies for fast recovery, restoring a database to a new host, and performing disaster recovery. It provides examples of using RMAN commands like RESTORE, RECOVER, SWITCH, and SET NEWNAME to restore and recover database files from backups.
Creating a physical standby database 11g on windowsRoo Wall
This document describes the steps to create a physical standby database including:
1. Configuring the primary and standby databases with the same Oracle version and opening the primary in archive log mode.
2. Setting up Oracle Net components and testing connectivity between the databases.
3. Enabling archive logging and log shipping on the primary and duplicating or copying the primary database to the standby.
4. Recovering the standby database and opening it in read-only mode to synchronize the data.
This document discusses database restore and recovery tasks. It describes causes of file loss like user errors, application errors, and media failures. It also discusses different recovery operations like restoring from backups, recovering redo logs, and recovering the control file. Critical vs non-critical file losses are defined. Automatic recovery of temporary files is also covered.
RMAN is an Oracle tool that performs physical backups and recovery of Oracle databases. It can perform full backups as well as incremental backups. Incremental backups only back up changed blocks since the previous backup. RMAN also allows recovery of individual datafiles, tablespaces, or the entire database using backups. It facilitates various recovery scenarios including datafile recovery, tablespace recovery, and disaster recovery when all files are lost.
This document discusses backup and recovery strategies for databases using Oracle Recovery Manager (RMAN). It recommends maintaining redundancy through techniques like RAID and mirroring to prevent the need for recovery. It emphasizes the importance of keeping the redundancy set that is needed for recovery on separate disks from the primary database files. It also stresses the need for frequent, redundant backups of archived redo logs to enable recovery to any point in time.
Backup and recovery procedures protect databases from data loss by allowing reconstruction of data through media recovery operations if loss occurs. A backup is a copy of important database files and data that acts as a safeguard against unexpected data loss or errors, enabling reconstruction using the backup if the original data is lost. Backups can be physical, copying database files, or logical, extracting data for storage in binary files. Oracle provides two main methods for backup and recovery: Recovery Manager (RMAN) and user-managed backup and recovery.
The control file contains critical database configuration information including the database name, data and redo file locations and names, tablespace definitions, and log and backup information. It is required for an instance to start up and cannot be edited directly. When data or redo files are added, renamed, or dropped, the control file is automatically updated to reflect the changes in physical database structure. The control file location and contents can be viewed using V$ views, and a new control file can be added by creating a parameter file from the server parameter file and editing the control file path before restarting the database.
Rman cloning when both directory and db name are same.subhani shaik
1. The document describes steps to duplicate a database where the source and destination database have the same name. It involves taking a backup of the source database, copying files to the destination, and using RMAN to restore and recover the database.
2. Key steps include making the directory structure the same on source and destination, starting the destination database in nomount mode, restoring the control file and datafiles, recovering changes, and opening the database.
3. The destination database is verified by checking the locations of datafiles, control files and redo logs.
This document discusses Oracle database backup and recovery. It covers the need for backups, different types of backups including full, incremental, physical and logical. It describes user-managed backups and RMAN-managed backups. For recovery, it discusses restoring from backups and applying redo logs to recover the database to a point in time. Flashback recovery is also mentioned.
1) The document discusses different methods for backing up an Oracle database, including using RMAN from the command line or Enterprise Manager GUI, and configuring the backup environment.
2) It provides step-by-step instructions for backing up an Oracle database that is in ARCHIVELOG or NOARCHIVELOG mode using RMAN, either via the CLI or the EM GUI.
3) The document also covers using Oracle's Flashback feature to enable point-in-time recovery of the database if unwanted changes are made, and provides steps for enabling Flashback via SQL*Plus or the EM.
- List the steps to multiplex your control files in OracleSolutionCont.docxrtodd22
Control files ensure a database starts properly and can recover from a crashed state. To multiplex control files, one should connect to the database, list existing control files, shut down the database, create a copy of a control file on a separate disk, add the new file path to init.ora, restart the database, and verify the control files were multiplexed. Multiplexing protects against data loss if a disk fails by having a redundant copy on another disk.
Flashback Database allows rewinding a database to undo data corruptions or errors. It works by using redo logs and block images to restore the database to a previous state. Configuring Flashback Database requires enabling it, setting a retention target, and having the database in ARCHIVELOG mode. Operations include flashing back to a time, SCN, or restore point. Monitoring involves checking the flashback window and log sizes.
With any database system, backup is one of the most important tool. PostgreSQL, The most Advanced Open Source database facilitates various backup and recovery options:
* Logical Backup
* Physical Backup
* Archive Logging
* Point in Time Recovery
1. Oracle looks for parameter files in specific locations to start up an Oracle database instance.
2. There are several options for starting up an Oracle database including startup, startup mount, and startup nomount.
3. Similarly, there are options for shutting down an Oracle database including shutdown, shutdown transactional, shutdown immediate, and shutdown abort.
This document discusses various features and techniques for duplicating and transporting Oracle databases using RMAN, including:
1. RMAN can duplicate a database without backups by using network-enabled duplication and the duplicate database will have its own unique DBID. Files names and locations may differ between the source and duplicate databases.
2. When duplicating a database, RMAN generates a unique DBID, creates a new control file, restores backups, and opens the duplicate database with resetlogs.
3. A database can be duplicated to a remote host or to a point in time in the past. Specific tablespaces, backups, or platforms can be excluded. The entire database or individual tablespaces can be transported
Communications Mining Series - Zero to Hero - Session 1DianaGray10
This session provides introduction to UiPath Communication Mining, importance and platform overview. You will acquire a good understand of the phases in Communication Mining as we go over the platform with you. Topics covered:
• Communication Mining Overview
• Why is it important?
• How can it help today’s business and the benefits
• Phases in Communication Mining
• Demo on Platform overview
• Q/A
Unlocking Productivity: Leveraging the Potential of Copilot in Microsoft 365, a presentation by Christoforos Vlachos, Senior Solutions Manager – Modern Workplace, Uni Systems
Generative AI Deep Dive: Advancing from Proof of Concept to ProductionAggregage
Join Maher Hanafi, VP of Engineering at Betterworks, in this new session where he'll share a practical framework to transform Gen AI prototypes into impactful products! He'll delve into the complexities of data collection and management, model selection and optimization, and ensuring security, scalability, and responsible use.
Cosa hanno in comune un mattoncino Lego e la backdoor XZ?Speck&Tech
ABSTRACT: A prima vista, un mattoncino Lego e la backdoor XZ potrebbero avere in comune il fatto di essere entrambi blocchi di costruzione, o dipendenze di progetti creativi e software. La realtà è che un mattoncino Lego e il caso della backdoor XZ hanno molto di più di tutto ciò in comune.
Partecipate alla presentazione per immergervi in una storia di interoperabilità, standard e formati aperti, per poi discutere del ruolo importante che i contributori hanno in una comunità open source sostenibile.
BIO: Sostenitrice del software libero e dei formati standard e aperti. È stata un membro attivo dei progetti Fedora e openSUSE e ha co-fondato l'Associazione LibreItalia dove è stata coinvolta in diversi eventi, migrazioni e formazione relativi a LibreOffice. In precedenza ha lavorato a migrazioni e corsi di formazione su LibreOffice per diverse amministrazioni pubbliche e privati. Da gennaio 2020 lavora in SUSE come Software Release Engineer per Uyuni e SUSE Manager e quando non segue la sua passione per i computer e per Geeko coltiva la sua curiosità per l'astronomia (da cui deriva il suo nickname deneb_alpha).
Sudheer Mechineni, Head of Application Frameworks, Standard Chartered Bank
Discover how Standard Chartered Bank harnessed the power of Neo4j to transform complex data access challenges into a dynamic, scalable graph database solution. This keynote will cover their journey from initial adoption to deploying a fully automated, enterprise-grade causal cluster, highlighting key strategies for modelling organisational changes and ensuring robust disaster recovery. Learn how these innovations have not only enhanced Standard Chartered Bank’s data infrastructure but also positioned them as pioneers in the banking sector’s adoption of graph technology.
Building RAG with self-deployed Milvus vector database and Snowpark Container...Zilliz
This talk will give hands-on advice on building RAG applications with an open-source Milvus database deployed as a docker container. We will also introduce the integration of Milvus with Snowpark Container Services.
Maruthi Prithivirajan, Head of ASEAN & IN Solution Architecture, Neo4j
Get an inside look at the latest Neo4j innovations that enable relationship-driven intelligence at scale. Learn more about the newest cloud integrations and product enhancements that make Neo4j an essential choice for developers building apps with interconnected data and generative AI.
For the full video of this presentation, please visit: https://www.edge-ai-vision.com/2024/06/building-and-scaling-ai-applications-with-the-nx-ai-manager-a-presentation-from-network-optix/
Robin van Emden, Senior Director of Data Science at Network Optix, presents the “Building and Scaling AI Applications with the Nx AI Manager,” tutorial at the May 2024 Embedded Vision Summit.
In this presentation, van Emden covers the basics of scaling edge AI solutions using the Nx tool kit. He emphasizes the process of developing AI models and deploying them globally. He also showcases the conversion of AI models and the creation of effective edge AI pipelines, with a focus on pre-processing, model conversion, selecting the appropriate inference engine for the target hardware and post-processing.
van Emden shows how Nx can simplify the developer’s life and facilitate a rapid transition from concept to production-ready applications.He provides valuable insights into developing scalable and efficient edge AI solutions, with a strong focus on practical implementation.
TrustArc Webinar - 2024 Global Privacy SurveyTrustArc
How does your privacy program stack up against your peers? What challenges are privacy teams tackling and prioritizing in 2024?
In the fifth annual Global Privacy Benchmarks Survey, we asked over 1,800 global privacy professionals and business executives to share their perspectives on the current state of privacy inside and outside of their organizations. This year’s report focused on emerging areas of importance for privacy and compliance professionals, including considerations and implications of Artificial Intelligence (AI) technologies, building brand trust, and different approaches for achieving higher privacy competence scores.
See how organizational priorities and strategic approaches to data security and privacy are evolving around the globe.
This webinar will review:
- The top 10 privacy insights from the fifth annual Global Privacy Benchmarks Survey
- The top challenges for privacy leaders, practitioners, and organizations in 2024
- Key themes to consider in developing and maintaining your privacy program
Introducing Milvus Lite: Easy-to-Install, Easy-to-Use vector database for you...Zilliz
Join us to introduce Milvus Lite, a vector database that can run on notebooks and laptops, share the same API with Milvus, and integrate with every popular GenAI framework. This webinar is perfect for developers seeking easy-to-use, well-integrated vector databases for their GenAI apps.
A tale of scale & speed: How the US Navy is enabling software delivery from l...sonjaschweigert1
Rapid and secure feature delivery is a goal across every application team and every branch of the DoD. The Navy’s DevSecOps platform, Party Barge, has achieved:
- Reduction in onboarding time from 5 weeks to 1 day
- Improved developer experience and productivity through actionable findings and reduction of false positives
- Maintenance of superior security standards and inherent policy enforcement with Authorization to Operate (ATO)
Development teams can ship efficiently and ensure applications are cyber ready for Navy Authorizing Officials (AOs). In this webinar, Sigma Defense and Anchore will give attendees a look behind the scenes and demo secure pipeline automation and security artifacts that speed up application ATO and time to production.
We will cover:
- How to remove silos in DevSecOps
- How to build efficient development pipeline roles and component templates
- How to deliver security artifacts that matter for ATO’s (SBOMs, vulnerability reports, and policy evidence)
- How to streamline operations with automated policy checks on container images
20 Comprehensive Checklist of Designing and Developing a WebsitePixlogix Infotech
Dive into the world of Website Designing and Developing with Pixlogix! Looking to create a stunning online presence? Look no further! Our comprehensive checklist covers everything you need to know to craft a website that stands out. From user-friendly design to seamless functionality, we've got you covered. Don't miss out on this invaluable resource! Check out our checklist now at Pixlogix and start your journey towards a captivating online presence today.
Observability Concepts EVERY Developer Should Know -- DeveloperWeek Europe.pdfPaige Cruz
Monitoring and observability aren’t traditionally found in software curriculums and many of us cobble this knowledge together from whatever vendor or ecosystem we were first introduced to and whatever is a part of your current company’s observability stack.
While the dev and ops silo continues to crumble….many organizations still relegate monitoring & observability as the purview of ops, infra and SRE teams. This is a mistake - achieving a highly observable system requires collaboration up and down the stack.
I, a former op, would like to extend an invitation to all application developers to join the observability party will share these foundational concepts to build on:
Let's Integrate MuleSoft RPA, COMPOSER, APM with AWS IDP along with Slackshyamraj55
Discover the seamless integration of RPA (Robotic Process Automation), COMPOSER, and APM with AWS IDP enhanced with Slack notifications. Explore how these technologies converge to streamline workflows, optimize performance, and ensure secure access, all while leveraging the power of AWS IDP and real-time communication via Slack notifications.
Let's Integrate MuleSoft RPA, COMPOSER, APM with AWS IDP along with Slack
Backup andrecoverychecklist
1. Backup & Recovery Check List
Alejandro Vargas
Oracle Support Israel.
User Managed Recovery Scenarios And Configuration
1. Complete Closed Database Recovery. System tablespace is missing
2. Complete Open Database Recovery. Non system tablespace is missing
3. Complete Open Database Recovery (when the database is initially closed). Non
system tablespace is missing
4. Recovery of a Missing Datafile that has no backups.
5. Restore and Recovery of a Datafile to a different location.
6. Control File Recovery
7. Incomplete Recovery, Until Time/Sequence/Cancel
Rman Recovery Scenarios And Configuration
1. Complete Closed Database Recovery. System tablespace is missing
2. Complete Open Database Recovery. Non system tablespace is missing
3. Complete Open Database Recovery (when the database is initially closed). Non
system tablespace is missing
4. Recovery of a Datafile that has no backups.
5. Restore and Recovery of a Datafile to a different location.
6. Control File Recovery
7. Incomplete Recovery, Until Time/Sequence/Cancel
User Managed Recovery Scenarios
User managed recovery scenarios do require that the database is in archive log
mode, and that backups of all datafiles and control files are
made with the tablespaces set to begin backup, if the database is open while the
copy is made. At the end of the copy of each tablespace
it is necessaire to take it out of backup mode. Alternatively complete backups can
be made with the database shutdown. Online redologs can
be optionally backed up.
Files to be copied:
select name from v$datafile;
2. select member from v$logfile; # optional
select name from v$controlfile;
go up
Complete Closed Database Recovery. System tablespace is missing
If the system tablespace is missing or corrupted the database cannot be started up
so a complete closed database recovery must be performed.
Pre requisites: A closed or open database backup and archived logs.
1. Use OS commands to restore the missing or corrupted system datafile to its
original location, ie:
cp -p /user/backup/uman/system01.dbf
/user/oradata/u01/dbtst/system01.dbf
2. startup mount;
3. recover datafile 1;
4. alter database open;
go up
Complete Open Database Recovery. Non system tablespace is missing
If a non system tablespace is missing or corrupted while the database is open,
recovery can be performed while the database remain open.
Pre requisites: A closed or open database backup and archived logs.
1. Use OS commands to restore the missing or corrupted datafile to its original
location, ie:
cp -p /user/backup/uman/user01.dbf /user/oradata/u01/dbtst/user01.dbf
2. alter tablespace <tablespace_name> offline immediate;
3. recover tablespace <tablespace_name>;
4. alter tablespace <tablespace_name> online;
go up
3. Complete Open Database Recovery (when the database is initially closed).
Non system tablespace is missing
If a non system tablespace is missing or corrupted and the database crashed,
recovery can be performed after the database is open.
Pre requisites: A closed or open database backup and archived logs.
1. startup; (you will get ora-1157 ora-1110 and the name of the missing datafile, the
database will remain mounted)
2. Use OS commands to restore the missing or corrupted datafile to its original
location, ie:
cp -p /user/backup/uman/user01.dbf /user/oradata/u01/dbtst/user01.dbf
3. alter database datafile3 offline; (tablespace cannot be used because the database
is not open)
4. alter database open;
5. recover datafile 3;
6. alter tablespace <tablespace_name> online;
go up
Recovery of a Missing Datafile that has no backups (database is open).
If a non system datafile that was not backed up since the last backup is missing,
recovery can be performed if all archived logs since the creation
of the missing datafile exist.
Pre requisites: All relevant archived logs.
1. alter tablespace <tablespace_name> offline immediate;
2. alter database create datafile '/user/oradata/u01/dbtst/newdata01.dbf';
3. recover tablespace <tablespace_name>;
4. alter tablespace <tablespace_name> online;
If the create datafile command needs to be executed to place the datafile on a
location different than the original use:
alter database create datafile '/user/oradata/u01/dbtst/newdata01.dbf' as
'/user/oradata/u02/dbtst/newdata01.dbf'
4. go up
Restore and Recovery of a Datafile to a different location.
If a non system datafile is missing and its original location not available, restore
can be made to a different location and recovery performed.
Pre requisites: All relevant archived logs.
1. Use OS commands to restore the missing or corrupted datafile to the new
location, ie:
cp -p /user/backup/uman/user01.dbf /user/oradata/u02/dbtst/user01.dbf
2. alter tablespace <tablespace_name> offline immediate;
3. alter tablespace <tablespace_name> rename datafile
'/user/oradata/u01/dbtst/user01.dbf' to '/user/oradata/u02/dbtst/user01.dbf';
4. recover tablespace <tablespace_name>;
5. alter tablespace <tablespace_name> online;
go up
Control File Recovery
Always multiplex your controlfiles. Controlfiles are missing, database crash.
Pre requisites: A backup of your controlfile and all relevant archived logs.
1. startup; (you get ora-205, missing controlfile, instance start but database is not
mounted)
2. Use OS commands to restore the missing controlfile to its original location:
cp -p /user/backup/uman/control01.dbf /user/oradata/u01/dbtst/control01.dbf
cp -p /user/backup/uman/control02.dbf /user/oradata/u01/dbtst/control02.dbf
3. alter database mount;
4. recover automatic database using backup controlfile;
5. alter database open resetlogs;
6. make a new complete backup, as the database is open in a new incarnation and
previous archived log are not relevant.
go up
5. Incomplete Recovery, Until Time/Sequence/Cancel
Incomplete recovery may be necessaire when an archived log is missing, so
recovery can only be made until the previous sequence,
or when an important object was dropped, and recovery needs to be made until
before the object was dropped.
Pre requisites: A closed or open database backup and archived logs, the time or
sequence that the 'until' recovery needs to be performed.
1. If the database is open, shutdown abort
2. Use OS commands to restore all datafiles to its original locations:
cp -p /user/backup/uman/u01/*.dbf /user/oradata/u01/dbtst/
cp -p /user/backup/uman/u02/*.dbf /user/oradata/u01/dbtst/
cp -p /user/backup/uman/u03/*.dbf /user/oradata/u01/dbtst/
cp -p /user/backup/uman/u04/*.dbf /user/oradata/u01/dbtst/
etc...
3. startup mount;
4. recover automatic database until time '2004-03-31:14:40:45';
5. alter database open resetlogs;
6. make a new complete backup, as the database is open in a new incarnation and
previous archived log are not relevant.
Alternatively you may use instead of until time, until sequence or until cancel:
recover automatic database until sequence 120 thread 1; OR
recover database until cancel;
go up
Rman Recovery Scenarios
Rman recovery scenarios require that the database is in archive log mode, and that
backups of datafiles, control files and archived
redolog files are made using Rman. Incremental Rman backups may be used also.
Rman can be used with the repository installed on the archivelog, or with a
recovery catalog that may be installed in the same or
other database.
Configuration and operation recommendations:
6. Set the parameter controlfile autobackup to ON to have with each backup a
controlfile backup also:
configure controlfile autobackup on;
Set the parameter retention policy to the recovery window you want to have,
ie redundancy 2 will keep the last two backups
available, after executing delete obsolete commands:
configure retention policy to redundancy 2;
Execute your full backups with the option 'plus archivelogs' to include your
archivelogs with every backup:
backup database plus archivelog;
Perform daily maintenance routines to maintain on your backup directory
the number of backups you need only:
crosscheck backup;
crosscheck archivelog all;
delete noprompt obsolete backup;
To work with Rman and a database based catalog follow these steps:
1. sqlplus /
2. create tablespace repcat;
3. create user rcuser identified by rcuser default tablespace repcat temporary
tablespace temp;
4. grant connect, resource, recovery_catalog_owner to rcuser
5. exit
6. rman catalog rcuser/rcuser # connect to rman catalog as the rcuser
7. create catalog # create the catalog
8. connect target / #
go up
Complete Closed Database Recovery. System tablespace is missing
In this case complete recovery is performed, only the system tablespace is missing,
so the database can be opened without reseting
the redologs.
1. rman target /
2. startup mount;
3. restore database;
4. recover database;
5. alter database open;
go up
7. Complete Open Database Recovery. Non system tablespace is missing,
database is up
1. rman target /
2. sql 'alter tablespace <tablespace_name> offline immediate';
3. restore datafile 3;
4. recover datafile 3;
5. sql 'alter tablespace <tablespace_name> online';
go up
Complete Open Database Recovery (when the database is initially closed).
Non system tablespace is missing
A user datafile is reported missing when tryin to startup the database. The datafile
can be turned offline and the database started up. Restore and
recovery are performed using Rman. After recovery is performed the datafile can
be turned online again.
1. sqlplus /nolog
2. connect / as sysdba
3. startup mount
4. alter database datafile '<datafile_name>' offline;
5. alter database open;
6. exit;
7. rman target /
8. restore datafile '<datafile_name>';
9. recover datafile '<datafile_name>';
10. sql 'alter tablespace <tablespace_name> online';
go up
Recovery of a Datafile that has no backups (database is up).
If a non system datafile that was not backed up since the last backup is missing,
recovery can be performed if all archived logs since the creation
of the missing datafile exist. Since the database is up you can check the tablespace
8. name and put it offline. The option offline immediate is used
to avoid that the update of the datafile header.
Pre requisites: All relevant archived logs.
1. sqlplus '/ as sysdba'
2. alter tablespace <tablespace_name> offline immediate;
3. alter database create datafile '/user/oradata/u01/dbtst/newdata01.dbf;
4. exit
5. rman target /
6. recover tablespace <tablespace_name>;
7. sql 'alter tablespace <tablespace_name> online';
If the create datafile command needs to be executed to place the datafile on a
location different than the original use:
alter database create datafile '/user/oradata/u01/dbtst/newdata01.dbf' as
'/user/oradata/u02/dbtst/newdata01.dbf'
go up
Restore and Recovery of a Datafile to a different location. Database is up.
If a non system datafile is missing and its original location not available, restore
can be made to a different location and recovery performed.
Pre requisites: All relevant archived logs, complete cold or hot backup.
1. Use OS commands to restore the missing or corrupted datafile to the new
location, ie:
cp -p /user/backup/uman/user01.dbf /user/oradata/u02/dbtst/user01.dbf
2. alter tablespace <tablespace_name> offline immediate;
3. alter tablespace <tablespace_name> rename datafile
'/user/oradata/u01/dbtst/user01.dbf' to '/user/oradata/u02/dbtst/user01.dbf';
4. rman target /
5. recover tablespace <tablespace_name>;
6. sql 'alter tablespace <tablespace_name> online';
go up
Control File Recovery
9. Always multiplex your controlfiles. If you loose only one controlfile you can
replace it with the one you have in place, and startup the
Database. If both controlfiles are missing, the database will crash.
Pre requisites: A backup of your controlfile and all relevant archived logs. When
using Rman alway set configuration parameter
autobackup of controlfile to ON. You will need the dbid to restore the controlfile,
get it from the name of the backed up controlfile.
It is the number following the 'c-' at the start of the name.
1. rman target /
2. set dbid <dbid#>
3. startup nomount;
4. restore controlfile from autobackup;
5. alter database mount;
6. recover database;
7. alter database open resetlogs;
8. make a new complete backup, as the database is open in a new incarnation and
previous archived log are not relevant.
go up
Incomplete Recovery, Until Time/Sequence/Cancel
Incomplete recovery may be necessaire when the database crash and needs to be
recovered, and in the recovery process you find that
an archived log is missing. In this case recovery can only be made until the
sequence before the one that is missing.
Another scenario for incomplete recovery occurs when an important object was
dropped or incorrect data was committed on it.
In this case recovery needs to be performed until before the object was dropped.
Pre requisites: A full closed or open database backup and archived logs, the time or
sequence that the 'until' recovery needs to be performed.
1. If the database is open, shutdown it to perform full restore.
2. rman target
3. startup mount;
4. restore database;
5. recover database until sequence 8 thread 1; # you must pass the thread, if a
single instance will always be 1.
10. 6. alter database open resetlogs;
7. make a new complete backup, as the database is open in a new incarnation and
previous archived log are not relevant.
Alternatively you may use instead of until sequence, until time, ie: '2004-12-
28:01:01:10'.
go up