---
title: Relying on Guaranteed Restore Points? Be careful! | Official Pythian® Blog
description: Matheus Boesing provides a warning and some tips if you're relying on guaranteed restore points as part of your migration or upgrade strategy.
---

[Blog | Pythian ](https://www.pythian.com/blog)

# [Relying on Guaranteed Restore Points? Be careful! | Official Pythian® Blog](https://www.pythian.com/blog/relying-on-guaranteed-restore-points-be-careful)

 Written by [Matheus Boesing](https://www.pythian.com/blog/author/matheus-boesing) | Apr 1, 2021 4:00:00 AM

## Context

Are you relying on guaranteed restore points (GRP) as a fallback plan for your migration or upgrade strategy? If you’re using RAC, especially before 12.2, be careful!

When performing a non-prod upgrade with the AutoUpgrade tool, after completing the upgrade, I wanted to roll it back and go through the process again. This is what happened:

```
SQL> startup
ORA-29702: error occurred in Cluster Group Service operation
```

When looking for more information, I found this blog post from Mike which I missed last year: [https://mikedietrichde.com/2020/11/13/ora-29702-and-your-instance-does-not-startup-in-the-cluster-anymore/](https://mikedietrichde.com/2020/11/13/ora-29702-and-your-instance-does-not-startup-in-the-cluster-anymore/).

This means my database isn’t starting anymore! Wow, I’m glad we’re in the testing phase!

## The problem

It is caused by Bug 31561819 – “Incompatible maxmembers at CRSD level causing database instance not able to start.”

As per Mike’s post, “*you don’t need to even restore or flashback a database to hit this error. A simple instance in NOMOUNT state leads to the same error. Without even any datafile*.”

The bug is fixed on:

- 19.9.0.0.201020 (Oct 2020) OCW RU
- 18.12.0.0.201020 (Oct 2020) OCW RU
- 12.2.0.1.201020 (Oct 2020) OCW RU

## The takeaway

You should include this patch *BEFORE* starting any move. Do it right away if you are on these versions!

In my case, the usage is for a 12.1->19c upgrade. So, the fix isn’t available (there’s no extended support in place). Since this is the case, I had to consider alternate fallback plans, like a physical standby. But this is a topic for another post.

Also, be aware of the latest change regarding restore point propagation on 19c, as per MOS *Automatic Propagate Restore Points from Primary to Standby site in 19C (Doc ID 2463082.1).*

## You should take the following steps:

- Apply this patch if you can!
- If not, be very careful with your fallback plans and as usual: test, test and test!

See you next post!

If you still have any questions, or you have thoughts about this post, please leave them in the comments.

## Oracle Database Consulting Services

Ready to optimize your Oracle Database for the future?

 

[View full post](https://www.pythian.com/blog/relying-on-guaranteed-restore-points-be-careful)

```json
{
  "@context" : "http://schema.org",
  "@type" : "BlogPosting",
  "author" : {
    "@type" : "Person",
    "name" : "Matheus Boesing"
  },
  "dateModified" : "2026-04-15T16:01:32.122Z",
  "datePublished" : "2021-04-01T04:00:00Z",
  "headline" : "Relying on Guaranteed Restore Points? Be careful!",
  "image" : {
    "@type" : "ImageObject",
    "height" : 60,
    "url" : "/hs/hsstatic/content_shared_assets/static-1.4092/img/default-amp-logo.png",
    "width" : 60
  },
  "mainEntityOfPage" : "https://www.pythian.com/blog/relying-on-guaranteed-restore-points-be-careful",
  "publisher" : {
    "@type" : "Organization",
    "logo" : {
      "@type" : "ImageObject",
      "height" : 60,
      "url" : "/hs/hsstatic/content_shared_assets/static-1.4092/img/default-amp-logo.png",
      "width" : 60
    },
    "name" : "Pythian Blog"
  }
}
```