Skip to main content

Posts

Showing posts from August, 2012

Database Authentication

Authentication is the process of verifying the identity of a user, device, or other entity in a computer system, often as a prerequisite to granting access to resources in a system. Oracle provides several means for users to be authenticated before they are allowed to create a database session. Database Authentication Identified and authenticated by the database, which is called database authentication. If you choose database authentication for a user, then administration of the user account including authentication of that user is performed entirely by Oracle Database. External Authentication Authenticated by the operating system or network service, which is called external authentication. When you choose external authentication for a user, the user account is maintained by Oracle Database, but password administration and user authentication is performed by an external service. This external service can be the operating system or a network service, such as Oracle Net. G

Areas to look upon for Oracle Database Security

We need to understand the potential security impacts of different configuration options that are available / provided by the Product vendors. In today's world when we are talking about putting our databases on Clouds, it's important to give as much security as you can. Negotiate with cloud vendors on security aspect first.  Each Database Architect must collaborate with Network Architect on point of Network Security. Scenarios are different based on requirement basis. This is just a general guide. There are four major things we need to address as part of DB Security. Authentication Access controls   Secure configuration   Auditing

Oracle Database Security Best Practice

1. Protecting the database environment 2. Install only what is required 3. Lock and expire default user accounts 4. Changing default user passwords 5. Change passwords for administrative accounts 6. Change default passwords for all users 7. Enforce password management 8. Secure batch jobs 9. Manage access to SYSDBA and SYSOPER roles 10. Enable Oracle data dictionary protection 11. Follow the principle of least privilege 12. Public privileges 13. Restrict permissions on run-time facilities 14. Authenticate clients 15. Restrict operating system access 16. Secure the Oracle listener 17. Secure external procedures 18. Prevent run time changes to listener 19. Checking network IP addresses 20. Harden the operating system 21. Encrypt network traffic 22. Apply all security patches

FAQ on using Transportable Tablespace

Q1: Can I move/migrate to both a different RDBMS version and OS platform at the same time? Yes; must be 10g or higher to move across OS platforms; charactersets must be the same regardless of version. See "Limitations on Transportable Use" in Document 371556.1 How to move tablespaces across platforms using Transportable Tablespaces with RMAN Q2: Do I have to convert the datafiles? Yes, if the endianness is different.  If the endianness is not different and no undo is in any of the tablespaces being transported, then the convert step is not needed.  Document 243304.1 10g : Transportable Tablespaces Across Different Platforms confirms the answer. Q3: Can I use TTS with ASM? Yes, with RMAN, ASM files can be moved. See "Transportable tablespace EXP/IMP of ASM files" in Document 371556.1 How to move tablespaces across platforms using Transportable Tablespaces with RMAN Q4: Can I move raw files? Yes, with RMAN. See "Transportable tablespace EXP/IMP of ASM file

Limitations of using Transportable Tablespace

Movement between different character sets   Movement between different OS (depending on RDBMS version)   Some objects are not transferred via TTS. Objects with underlying objects (such as materialized views) or contained objects (such as partitioned tables) are not transportable unless all of the underlying or contained objects are in the tablespace set.   Oracle Server -- Standard Edition vs. Enterprise Edition; Standard Edition can only import TTS (no export)  System, undo, sysaux and temporary tablespaces cannot be transported. Transporting tablespaces with XMLTypes has the following limitations: The destination database must have XML DB installed. Schemas referenced by XMLType tables cannot be the XML DB standard schemas. Schemas referenced by XMLType tables cannot have cyclic dependencies. XMLType tables with row level security are not supported, because they cannot be exported or imported. If the schema for a transported XMLType table is not presen

Best Practice for using Transportable Tablespace

Check restrictions/limitations in question above. If you are migrating a database, (a) make sure there are no invalid objects in the source database before making the export.   Take a full norows export to recreate objects that won't be transported with TTS.   Keep the source database viable until you have determined all objects are in the target database and there are no issues (i.e. the target database has been thoroughly checked out and exercised).   Do a dry run to work out any unexpected issues and determine timings.
DRS - Distributed Resources Service     1. No Reboot is required.     2. This process will recommend moving a VM for performance reasons.  This can be set to automatically  move the VM.  HA - High Availability     1. Reboot is required     2. If a host crashes, this service will start the VM's that were on it, to another host automatically.  The VM's will have powered down unexpectedly though.  FT - Fault Tolerance     This feature is introduced in ESX4 and keeps a running copy on another host.  If the primary host fails, the other takes over with no down time.  This is currently limited to VM's with one vCPU though.