When developing software applications, it's often considered best practice for application vendors to avoid writing code that is specific to a single type of database. Here's why:
1. **Portability**: One of the primary reasons is to ensure that the application remains database-agnostic. This means that the application can be easily ported to work with different database systems without requiring major code changes.
2. **Broader Market Appeal**: By keeping applications database-agnostic, vendors can cater to a wider range of customers. Different organizations might have different database preferences based on their existing infrastructure, licensing costs, expertise, and other factors. If an application only works with one type of database, it could limit its potential customer base.
3. **Future-Proofing**: Technologies and industry trends change. Today's leading database system might not be the leader in a few years. By keeping the code independent of a specific database, vendors ensure that their applications remain relevant and adaptable to future technological shifts.
4. **Maintenance**: Writing code for a specific database system can introduce complexities in the codebase. If a vendor supports multiple database-specific code paths, it can increase the maintenance overhead, as each database-specific implementation might need updates, bug fixes, or enhancements.
5. **Licensing and Cost Concerns**: Tying an application to a specific database can introduce licensing complexities and potential additional costs for the end-users. By remaining neutral, application vendors give customers the flexibility to choose a database that fits their budget and licensing preferences.
6. **Avoiding Vendor Lock-in**: Relying heavily on one database vendor's specific features can lead to a situation known as vendor lock-in. This is where an organization becomes overly dependent on a single supplier's products, leading to reduced flexibility and potentially higher costs in the long run.
7. **Use of ORM (Object-Relational Mapping) Libraries**: Modern applications often use ORM libraries, such as Hibernate in Java or Entity Framework in .NET, which provide an abstraction over the database. These libraries allow developers to work with databases in an object-oriented manner, often without needing to write SQL code directly. This not only makes the code more database-independent but also reduces the need for database-specific optimizations in many cases.
8. **Performance Considerations**: While there's a belief that database-specific code can be optimized better, it's often the case that generalized solutions, when done right, can offer performance that is more than adequate for most applications.
9. **Database Features**: Most relational databases support the SQL standard to some extent. While there are proprietary extensions and features in each database system, most common tasks can be achieved using standard SQL, negating the need for database-specific code.
10. **Complexity**: Introducing database-specific logic can increase the complexity of deployment, configuration, and testing. By keeping the codebase consistent across all supported databases, developers can ensure a smoother user experience.
In summary, while there are occasional valid reasons for writing database-specific code, for most application vendors, the benefits of maintaining a database-agnostic stance often outweigh the potential advantages of optimizing for a specific database system.
If you're working in an Oracle Real Application Clusters (RAC) environment and you have multiple instances for a single database, each instance has its own unique name. When you want to modify parameters specific to an instance in a shared SPFILE, you can use the `sid` qualifier in the parameter name.
Here's how you can modify the shared SPFILE for a specific instance:
1. **Backup the SPFILE**:
Always backup the SPFILE before making any changes.
```sql
CREATE PFILE='/path_to_backup/init.ora' FROM SPFILE;
```
2. **Connect to the database**:
Start SQL*Plus and connect to the database as a user with SYSDBA privileges.
```bash
sqlplus / as sysdba
```
3. **Modify the SPFILE for a specific instance**:
If you want to modify or add a parameter specific to an instance, use the `sid` qualifier. The format is `parameter_name.sid_instance_name`.
For example, let's assume you have an instance named "ORCL1" and you want to set the `pga_aggregate_target` parameter only for that instance to 200M in the shared SPFILE:
```sql
ALTER SYSTEM SET pga_aggregate_target.ORCL1=200M SCOPE=SPFILE;
```
4. **Restart the specific instance**:
To apply the changes to the specific instance, restart it. If you're connected to the instance you're changing:
```sql
SHUTDOWN IMMEDIATE;
STARTUP;
```
If you're in a RAC environment and connected to a different instance, you'll need to use Oracle's cluster management tools or scripts specific to your setup to restart the desired instance.
5. **Verify your changes**:
Connect to the instance for which you made the changes and verify by querying the `V$PARAMETER` view:
```sql
SELECT NAME, VALUE FROM V$PARAMETER WHERE NAME LIKE 'parameter_name%';
```
Always make sure to thoroughly test any changes in a development or test environment before applying to production. This ensures that you understand the impact of your changes and can avoid potential issues.
This is a GIT guide
sysresv
The sysresv command in Linux can be used to view the currently allocated IPC resources for shared memory. The sysresv utility has been provided by Oracle since version 8i.
MAA GoldenGate Performance
https://www.oracle.com/technetwork/database/availability/maa-gg-performance-1969630.pdf
Oracle19c has a new feature called AutoUpgrade
Mike Dietrich has a great post about this here