Blue growth note-chasing DBA (5): Not talking about technology, business, annoying application systems, not talking about dba

Blue growth note-chasing DBA (5): Not talking about technology, business, annoying application systems, not talking about dba

************************************ Statement ***************************************

Personal Growth records on the oracle Road, expressed in blue, share the growing emotions, vision and technological changes and growth. Sensitive information is replaced by English and will not disclose any confidential information of the company. It is only used for technology sharing.

The creative inspiration comes from self-reflection and recording. I'm glad to have some help or resonance with the database friends who just started out.

Please leave a message or email (hyldba@163.com) indicating that the technical details are incorrect. Thank you very much.

**************************************** **************************************** ***

To jump high, you must first learn to kneel down.

-- Deep Blue

************************************* Preface ***************************************

This is an accumulation of personal records. As we enter the blue ocean of oracle, we can't go all the way and continue to test. Share the growth history of blue with database friends.

I don't know when I began to become obsessed with blue. I was obsessed with its wide range, its depth, and its close proximity.

But it cannot be clear from when, watching the oracle red dazzling, illuminating a light in front of the eyes, unknown and confused under their own feet began to reveal some of the enrichment of life and the feedback of youth.

Step by step on the path to pursue DBA's dream.

**************************************** **************************************** ***

2014 Beijing

Two days later, I moved my problem to R & D. I had to leave it empty. The links and systems still need to be built and improved. The business layer, the site layer, and the Implementation Layer have different handling situations, different on-site problems have emerged. The appearance of this problem seems very simple, but it takes a long time for the implementation staff to spend. The painstaking pain makes people physically and mentally exhausted. After half a day, I was confused. Next, I will recall the implementation and deployment that is closely related to the business layer.

Scenario reproduction: to complete the deployment and migration project, migrate the original application system and database to the new server and deploy the client. The environment is a 64-bit win7 System (description, in the production environment, application servers and database servers are separated. This deployment is a scientific research project, and the content cannot be described in detail. In this case, you can understand that all applications are on one server ). A application java Development, B/S architecture. Application clients such as B and C are also B/S architectures, but developed based on 32-bit systems. This is a simple technical detail that begins to cause continuous business problems.

After the re-deployment of application A of the primary system, everything seemed to be normal. After some twists and turns, I changed the password and finally logged on to the system as A super administrator. However, when the task is completed, a problem occurs in front of the technical staff, and a maintenance page cannot be accessed normally, resulting in a permission problem. Click test continuously, and a new problem occurs at the business layer. A processing program cannot be used. Surprisingly, this deployment has no objection. Where did the problem occur. Troubleshoot the problem step by step as prompted. Because there is no complete deployment manual at hand, you can find the problem according to the prompt: a jdk causes unhandled. Search, download, install, continue troubleshooting, and find that some functions are missing. At this time, Contact R & D personnel and send an email to the business script to solve problems related to O & M. At this time, I am confused about whether there is a clear line between the business process and technical implementation. You can imagine that if you encounter such a problem through technical troubleshooting, it would be a bit difficult. I am afraid there will be no correct solution except to develop a brand new one, this is because it is a business requirement. This is a problem at the business layer. If you develop a business script, you can run it to create some menus, associate function items, and grant permissions to them. For example, the problem can be solved. To put it simply, thinking in case of errors is the key. Coordination and feedback sometimes exceed the technology itself.

This is just A problem of application system A leakage. We haven't talked about annoying Application Systems B, C, and D. This time it's annoying. Client Program, access problems. Another thought is for developers to keep in touch. Then we can see the effect. Yes. Email again, replace the file, and reset it. Okay? This sad reminder, the business layer does not know what's wrong, the program seems to be wrong. This is a serious problem because there is a key "backbone" system in this series of business systems (technical details cannot be disclosed ), it can be understood as a management platform for uploading and releasing data. It maintains the consistency of all system information based on the main business system (does it feel a bit like the undo segment in oracle and maintains read consistency. Haha, here is just a joke ). Because the application deployment is not working properly, this series of migration seems to have been completed, but it has returned to the starting point. This time, contact the developer again. The field staff collapsed, and the R & D staff also collapsed. Email Exchange several times in succession. The configuration is fruitless and cannot be continued. Copying all tomcat logs requires R & D personnel to visit the site this time (here, I can't help but remember that it was also because of a previous business problem of the company, project owners, implementers, maintenance personnel, developers, Party A leaders, and Party A engineers gathered to go to the site for a spectacular scenario. Haha, let's talk about it again ~~). Of course, this situation is still under control. There is still one day to adjust the final business deployment. According to common sense experience, this client problem will be solved after the R & D team is present and the corresponding packages and configuration files are adjusted according to the actual environment. After a while, let's end the paragraph here.

Looking back, many of the problems have not been solved technically. Think about the technology-related aspects, such as the configuration of tns, listening, middleware deployment, optimization, and data migration when the client connects to the database, which are not the cause of this problem. Problems are exposed to business applications, changes to the on-site system environment, and adjustments and updates of different business files.

This is what we call "business needs". Oracle technology also needs to be implemented. Sometimes, the solution to the problem may be higher than the technology. The exploration of the technology requires the support of the business.

 

************************************** Unfinished to be continued ***************************************

Welcome to: Deep Blue Blog: http://blog.csdn.net/huangyanlong

**************************************** **************************************** *********