APIPythonOpen-Source Solutions

 View Only
  • 1.  delphixpy - Error while executing dx_provision_vdb.py

    Posted 07-13-2021 08:46:00 AM
    When I try to execute the dx_provision_vdb.py I am getting the following error:

    delphixpy.v1_8_0.exceptions.RequestError: APIError(action='Check your input parameters and try again.', command_output=None, details={'source': {'redoLogSizeInMB': {'details': 'Invalid value 0. Value must be greater than or equal to 4.', 'action': None, 'id': 'exception.validation.number.toosmall.inclusive', 'commandOutput': None, 'diagnoses': None}}}, diagnoses=[], id='exception.validation.bad.input', type='APIError')

    This API Error does not give me the specific error details to callout, what is the input the API is expecting. Can anyone help here?

    Vijaylingam Jeyasingh
    Delphix Community Members

  • 2.  RE: delphixpy - Error while executing dx_provision_vdb.py

    Posted 07-13-2021 10:05:00 AM
    ok now I got the parameter causing the error. It is redoLogSizeInMB under OracleVirtualSource.py. But Still I did not get what it means and why this parameters is needed? If so, can someone guide me to override this parameter value in API or as an input to dx_provision_dbb.py

    Vijaylingam Jeyasingh
    Delphix Community Members

  • 3.  RE: delphixpy - Error while executing dx_provision_vdb.py

    Posted 07-13-2021 10:44:00 AM
    ok finally. Fixed myself by inserting this line "vdb_params.source.redo_log_size_in_mb = 4"

    Vijaylingam Jeyasingh
    Delphix Community Members

  • 4.  RE: delphixpy - Error while executing dx_provision_vdb.py
    Best Answer

    Posted 07-24-2021 12:02:00 PM
    Edited by Michael Torok 07-26-2021 09:55:43 AM
    Hello Vijaylingam-

    Sorry that you ran into this unexpected error, and for the delay in response!  From a purely API perspective, the redo log size is not a required parameter in recent versions; the API allows this to be unset, and will normally be unset by default in other API operations, in which case the Engine will set a default value of 100MB.


    After a bit of review, I see that API versions < 1.9.0 appear to explicitly default this value to 0, rather than leaving it unset.  I've done a quick test myself and reproduced this behavior to further understand the possible issue.

    In the product documentation discussing CLI translation to Python:

    We see further discussion about the API version, and the specification of API version in Python.  Using the default examples that ship with delphixpy, you'll notice that all examples are built importing the 1.8.0 API version, so if these were left as-is (as indicated by the message delphixpy.v1_8_0.exceptions.RequestError), this is ultimately why the behavior was as you observed, as it aligns with the 1.8.0 API behavior.
    from delphixpy.v1_8_0.delphix_engine import DelphixEngine
    from delphixpy.v1_8_0.exceptions import HttpError
    from delphixpy.v1_8_0.exceptions import JobError
    from delphixpy.v1_8_0.exceptions import RequestError
    from delphixpy.v1_8_0.web import database
    from delphixpy.v1_8_0.web import environment
    from delphixpy.v1_8_0.web import group
    from delphixpy.v1_8_0.web import job
    from delphixpy.v1_8_0.web import repository
    from delphixpy.v1_8_0.web import snapshot
    from delphixpy.v1_8_0.web import source
    from delphixpy.v1_8_0.web.database import template

    Although these delphixpy examples give you a starting point, they do need to be updated according to your configuration (they are examples, after all :) ).  You may choose to set the specific API version by altering the instances of v1_8_0 to match the API version for your current Engine, or you can remove this specific callout altogether to use the latest API version. Please note, this isn't the latest API version for your Engine, but the latest public API version. So, if you remove the version-specific import detail, at this time it would default to 1.11.9, which will only work with your Engine if it's on (as per the API version reference provided above).

    Because of this behavior, and generally from a development perspective, it's recommended to specify a static API version in scripted operations, so the behavior of your automation doesn't change unexpectedly when new versions are released. If you have multiple Delphix Engines in your estate running distinct versions, set the API version to the highest common API version (the highest supported version for the lowest managed Engine version) to ensure consistent operation with each instance.

    You'll also need to make the same API version changes for those files under lib/ which support delphixpy operation, including GetReferences.py and GetSession.py (used to define the object references and establish API session, respectively).

    In my lab, I'm testing against a Engine which operates with API version 1.11.8 by default, so I'll align with this.  If we replace the 1_8_0 references with 1_11_8 accordingly in the provision script as well as the GetReferences and GetSession scripts, we'll see this job submission now succeeds without specifying a redo log file size (indicated by redo_log_size_in_mb=undef in the output below).

    % ./dx_provision_vdb.py --source_grp Untitled --source "DBOMSR7A9789" --instname pytest --uniqname pytest --db pytest --target pytest --target_grp Untitled --environment seanora122vltsrc --type oracle --envinst "/u01/app/oracle/product/"
    INFO: Welcome to dx_provision_vdb.py version v.0.2.305
    INFO: Executing against the default Delphix Engine in the dxtools.conf: sean6081
    OracleProvisionParameters(container=OracleDatabaseContainer(content_type=undef, creation_time=undef, current_timeflow=undef, description=undef, diagnose_no_logging_faults=undef, group=u'GROUP-1', live_source=undef, masked=undef, name='pytest', namespace=undef, os=undef, performance_mode=undef, physical_standby=undef, pre_provisioning_enabled=undef, previous_timeflow=undef, processor=undef, provision_container=undef, rac_max_instance_lag=undef, reference=undef, runtime=undef, sourcing_policy=undef, transformation=undef, type=u'OracleDatabaseContainer'), credential=undef, masked=undef, masking_job=undef, new_dbid=undef, open_resetlogs=True, physical_standby=undef, source=OracleVirtualSource(allow_auto_vdb_restart_on_host_reboot=False, archivelog_mode=undef, config=undef, config_params=undef, config_template=undef, container=undef, custom_env_vars=undef, description=undef, file_mapping_rules=undef, hosts=undef, linked=undef, log_collection_enabled=undef, mount_base='/mnt/provision', name=undef, namespace=undef, node_listeners=undef, operations=VirtualSourceOperations(configure_clone=undef, post_refresh=undef, post_rollback=undef, post_snapshot=undef, post_start=undef, post_stop=undef, pre_refresh=undef, pre_rollback=undef, pre_snapshot=undef, pre_start=undef, pre_stop=undef, type=u'VirtualSourceOperations'), redo_log_groups=undef, redo_log_size_in_mb=undef, reference=undef, runtime=undef, runtime_mount_information=undef, staging=undef, status=undef, type=u'OracleVirtualSource', virtual=undef), source_config=OracleSIConfig(cdb_type=undef, credentials=undef, database_name='pytest', discovered=undef, environment_user=undef, instance=OracleInstance(instance_name='pytest', instance_number=1, type=u'OracleInstance'), linking_enabled=undef, name=undef, namespace=undef, non_sys_credentials=undef, non_sys_user=undef, reference=undef, repository=u'ORACLE_INSTALL-1', services=undef, tde_keystore_password=undef, type=u'OracleSIConfig', unique_name='pytest', user=undef), timeflow_point_parameters=TimeflowPointSemantic(container=u'ORACLE_DB_CONTAINER-6', location='LATEST_SNAPSHOT', type=u'TimeflowPointSemantic'), type=u'OracleProvisionParameters', username=undef)

    I don't generally work with delphixpy so I hope this helps to clarify the operation in general, how it relates to the Engine version, and the customization required in most installations.

    Please let us know if we can offer any other assistance!

    Sean Nothdurft
    Senior Principal Technical Support Engineer